観察日記 2010-01-29 - なるせにっき

CRubyコーディング規約

「空気を読め」というのが規約
ext は歴史的経緯によるカオス
一応misc/ruby-style.elがあるが……

うちの.vimrcでは set ts=8 sw=4 cinoptions=:2=2t0 noexpandtabと設定されているようです。

投げてみようか

なんかあったので http://d.hatena.ne.jp/snaka72/20100128/1264695170
{hermit_} iconvを使ったRuby スクリプトをExerbでexe化し実行すると、"`require': No such file to load -- iconv"と言われた - 今日もスミマセン。 [text/html; charset=euc-jp]
{shyouhei} > MLに投げてみようか？
ためらう理由が分からない。

みんなruby-listにはもっと気楽に投げていいと思うんですよ。

メモリリーク

[ruby-core:27949] これどうなん？
{znz_m} http://mla.n-z.jp/?ruby-core=27949
こんなレベルのバグが残ってたとかすごい
というか、なんで最初いきなりrejectされてるの?
コメントなしひでええ (注: ruby-core:23258)
http://redmine.ruby-lang.org/issues/show/1392 をみるとML連携出来てない?
{hermit_} Ruby 1.9 - Bug #1392: Object#extend leaks memory on Ruby 1.9.1 - Ruby Issue Tracking System [text/html; charset=utf-8]

結構ML連携に失敗している事はあります。

kosakiさんのgit教室

format-patch で作ったパッチって git am であてるんだよね
git apply
git am はメールにたいして使う
コミットログとかいらないときはpatch -p1 -iであててるなあ。
(znz) (-iは) 入力ファイル指定

gitで作ったpatchを当てる時は-p1が必要ってのは重要ですな

18:58 signed-off-by って手で書くもの？
18:59 g>"signed-off-by"
18:59{ko1_ndk} google web bot: 完全なるパッチ - 日本の Linux 情報 - http://www.linux.or.jp/JF/JFdocs/tpp.txt (and 4,940 hits)
19:06 git format-patch --signoff すればつけてくれるよ>signed-off-by
19:07 author とコミットした人の名前では不足なのかなという
19:29 Authorはパッチつくった人で
19:30 Signed-off-byは関係者全員
19:30 具体的に言うと、コミットしたメンテナのサインを付加する
19:30 共著パッチの場合はその人も付加する
19:31 これによって、バグが起きたらsigned-off-byがついてる全員にｃｃすればよいという体制に
19:31 たぶんrubyではここまで必要ないかもしれない
19:32 ＬＫＭＬは全員が口をそろえて、あんなん全メール読んでられっか。という場所なので
19:32 ｃｃがうまくいく仕組みが必要だった

結局、そのパッチにバグがあった時に責任を持つ人がSigned-offらしい

(kosaki_) ローカルコミットがあるなら git pull --rebaseが事実上必須で、これがデフォルトではないのは
(kosaki_) Linusが下々のツリーからpullすることを意図しているから
(kosaki_) で、みんなブランチきって
(kosaki_) linus-treeをおっかける（ローカルコミットがない）ブランチをgit pullでアップデートして
(kosaki_) 自分のブランチを、git rebaseでそっちにリベースしてる
(kosaki_) git pull --rebaseするより、明示的に二手順に分けておいた方が、コンフリクトした時に便利
(kosaki_) 何回でもやり直しできる安心感があるので

下々のものはgitじゃなくて、pull --rebaseがデフォルトの上位ラッパーを使うべきな気がするのです。

(shyouhei) git bisectしなされ
(mame) bisect がばしっとキマったことが数えるほどしかない
(mame) Makefile の依存性とかが欠けてるのか知らないけど、ちゃんと make できないとか
(nurse) なんかビルドできない事多いよね……
(mame) 後で直しても bisect 的には手遅れですしねえ
(shyouhei) それはgitのせいではない予感が...
(mame) まあ、bisect に仕掛けるスクリプトを書くのは慣れとノウハウが必要だと思う
(nurse) 慣れとノウハウを得た人がラッパー作ってくれるのを待つとかいう
(kosaki_) そうか。Rubyだとbisectがスクリプトで出来るのか。目から鱗
(kosaki_) カーネルだとtest fail イコールブートしないので、スクリプトもクソも・・・
(mame) 仮想マシン使って自動化するものだと思ってた
(nurse) kvmとかと連携して、ばばばきゅいーんってやってるものだと
(unak) まあ、git bisectにわざわざその機能があるんだから、できるときはやるんだろうと想像
(mame) ばばばきゅいーん
(kosaki_) もしかしたら、そういうテクもあるのかもしれんが、僕には出来ない・・・
(kosaki_) まあブートできない時はたいていハードが絡んでるので仮想マシンと相性悪いという罠

誰かtest.rbを叩くgit bisect用スクリプトをtool/あたりに入れておいて欲しいな。

RubySpec対応の進捗

コミット権を得たmameさんが大暴れした結果、trunkでのtest失敗が560→485→263→188→112などと激減。がんばつてくだしあ

(nurse) 特定のspecだけ実行するのってどうするの
(mame) make test-rubyspec MSPECOPT=spec/rubyspec/library/net/

1.9の互換性つれづれ

この項目は(この項目に限らないのだが、これは特に)編集・コメントに成瀬の主観が混じっているため、そこを差し引いて読んでください。

(yugui) yehudaから1.9-shimが必要という話を聞いている。
(yugui) ActiveSupportが吸収層を持たなきゃ行けないのはおかしいとな。それは正しい。
(yugui) 1.8.8には1.9-shim入れませんか?

yehudaとはYehuda Katzのこと、Rails 3で元MerbのEzra Zygmuntowiczと共に主導的役割を果たしている人。yuguiさんと他のチャンネルで話しているのであろう。
shimとはRuby 1.6向けにknuさんが中心になって提供した互換レイヤ・追加モジュール。ruby-dev:16790 shim方式は機能追加が主だった1.6→1.8では機能した。

(nurse) ていうか、1.8.8ってshim-releaseだという話をかねてから
(yugui) syntaxをparseできるだけじゃなくて?
(yugui) require '1.9-shim'とかしたら1.9.2用のrubyspecにpassしてほしい
(mame) また壮大な話が……
―― いかに壮大か、rubyspecや正規表現エンジンの例が出る ――
(nurse) 正直、1.8.8に1.9bundleした方が早い
(yugui) まるっと1.9じゃそれも困る。
(nurse) shimというか1.9再実装になる事が想定される

昨日まで、RubySpecはtrunkで500個以上の失敗があった。それは1.8と1.9の非互換変更の個数を示しているわけで、この目標を達成するには1.8の実装をそれだけ変えないといけない事を意味する。

(yugui) 新しいリリースで既存コードが動かないのは深刻な問題、とyehudaに言われている。
(yugui) ごもっとも。
(nurse) Perl5.10でも使っとけ
(yugui) 1.9.2で書いたコードはずっと動くようにしたい。
(shyouhei) いや下位互換重要っすよ
(nurse) 重要である事は疑いようもない

yehudaは「既存コード」とここでは言っているが、彼の趣旨は「Rails 3をRuby 1.9/1.8で両対応にするための負荷軽減」であろう。で、こちらでは非互換変更に対して不満を述べている。まぁ、それはもっともだし、Perl 5.10やMicrosoftは互換性維持のために多大なコストを払っている。それがMicrosoftの力の源泉だし。

(yugui) Rubyにはuseも__future__もないのが下位互換を難しくする。
(shyouhei) __future__はよいものだが、下位互換という意味ではどうなのかな上位互換にはとてもよい
(yugui) 下位互換というか、移行期間を作るのに便利じゃん? < __future__

useも__future__も今回の下位互換の話とは全く関係ないと思う。Ruby的にはいちいち指定しなくても使えるようにぶち込んでしまう。ソースの前処理レイヤのようなものを公開する気が皆無なのも影響しているのだと思うが。

(yugui) selector namespaceが互換性問題を救うと思うんだ。
(yugui) 別の名前空間に古い挙動入れておけば良いじゃん?　みたいな。
(ko1_ndk) Riteでなんでも解決的なにおいが

過去のバージョンの挙動を自在に取り出せるーとかなると確かに超技術だけど、維持できる気がしないのと、C実装部分がねぇ。

(mame) begin; eval("1.foo"); rescue NoMethodError; :ok; end
(mame) 1.9.3 では Fixnum#foo というメソッドが導入されました
(mame) というのは互換性の問題があると言えないこともないと思う

ActiveSupport::Multibyte::Chars#chars が踏みましたね。しかし、組み込みクラスにメソッド追加ってのはリスクのある行為なのですよね。

(nurse) で、libだったらrequire "foo.rb", "1.9.3"とかでいいんじゃないかね
(shyouhei) たとえばJavaとかでそのへんをどう解決しているかというと、jarで固める?
(nurse) ていうか、gemってバージョン指定requireできなかったっけ
(shyouhei) でも必要なライブラリがjarで固まってるのは移行とは言わんか。
(yugui) 必要な互換性バージョンをマジコメるしくみはダメかな。

requireの話はgemに加えてIronRubyのrequire拡張を念頭に置いている。Javaでjarに固めるのはRailsで関連ライブラリをvendor下に置くのと同じですかね。マジックコメントはありえないと思います。

(shyouhei) 予算か時間が無限にあればクオリティは無限に上昇するが、
(shyouhei) それは完成度100%に漸近するだけの話で、ようするに停滞しているってことなわけです。
(shyouhei) あ、これは設計図がちゃんとある場合ね。
(shyouhei) 作りながら考えてる時は手戻りはある。

その後発散してQCの話に。まぁ、影響範囲の大きい話をする時は、最初から着地点を想定して話さないと容易に発散してしまうのです。
思うにYehudaが本当に困っているのは1.9.1→1.9.2でも連発されている非互換変更で、彼が要求するべきだったのは作れもしない1.9-shumではなく、非互換変更をcoreの外にいる人間がより知りやすくする方法だったんじゃないかなぁ。
そうそう、Rubyのユーザは「Rubyに理不尽な仕様があった場合、その挙動は容赦なく変更される」ってのは知っておくべき事だと思います。