観察日記 2010-12-07
今日のはちょっと前の話題、まとめてあったのに貼り忘れてたんですよ。
RubySpecとは何か
いつも思うんだがrubyspecってどうなの?
まぁ、ぼちぼち
test-allとは違う視点で書かれたテストとしてしか見てない
重箱の隅をつついてくれているという理解。
delete_fieldは未定義動作だと思う
RubySpecは未定義動作やバグまで勝手に仕様と決め付けてるからイヤなんだよ
基本的にRubySpecってあまり未定義って通じないので
RubySpecはMRIが仕様ですから
「IEが仕様」みたいな
うん。で、未定義動作について違う挙動をする処理系が出現したらそう書けばいいじゃん、と言っていた。うーん
で、わたしが知りたいのは、今回の「仕様変更」が1.9.3以降なのか1.9.2とかにも及ぶのか、なのです
いったい何やりたいのかが理解できてないのでいまいち意味不明な行動としか思えず。
RubiniusがMRIと同じ挙動を示すかのテスト群でしょ
これは「違う挙動をする処理系が出現した」に該当するはずなんだからそう書けよと。
そうかこうと思ってるんだけどbackportするの？って聞いてる
しないなら1.9.3から仕様が変わりましたと書く
rubyspecとか脇に置いといてこの件に関していうと、
まあどっちでもいいけど気持ちとしてはバックポートしたほうがすっきりしそうかなあ。
今回のは「仕様定義」
でもしないならそれはそれで。正直困ってないし。
未定義だったので「変更」ではない
ええと、「仕様変更」ってカギカッコつけたのはRubySpec視点での話で、
仕様がどうとかとりあえず忘れよう。そこはrubyspecが勝手に悩めばいい。
彼らの言う「仕様」っていうのは実装によって定義されるので云々
ぼくらの言う仕様とはちょっと違う
バックポートに関しては俺はニュートラルです。どっちでも可。
もしかして「ソースが仕様、バグも含めて(ry」をクソ真面目に実践してんのか彼らは
え、いまさら
だからIE互換と同じ話なんですって
ユーザが同じ動きを求めてるからそれを保証するしくみ作ってる
ぼくらの意図とかはあまり関係ない
バグを仕様と言い張られるのがユーザよりも開発者のほうがむかつくとは気付かなかった
MSとかは「仕様」になってしまった過去との互換性の戦いの日々じゃないすか
同情するな
「それはバグだ」とか「未定義だったので定義します」で押しきれるだけぼくらはしあわせです
187くらいになるともはやrubyspecは普段気にもとめてないしな
とりあえずtrunkでFにならなければそれでいいという観点で直しておくか
187に対してrubyspecが通らないとしたらそれはrubyspecのほうが悪い。定義から言って。
というか全体的に基本的にRubySpecの方が悪い
RubySpecが通るような形でRuby側が「仕様変更」されることもたまにあるけど
それはSEGVしてたとか
妥当性があれば別に受け入れてもいいんじゃね
是々非々としか言いようがない
そりゃもちろん
まぁ、実質的には
形式的にはバグってたRubySpecがたまたまRubyの仕様変更によって通るようになった的な
でも妥当性を検討せずに実情を入れちゃうのがRubySpec
で、バックポートした場合としない場合、それぞれRubySpecでの対応はどういう形になんの
した場合はまるっと変える
しない場合はruby_version_isでバージョンごとに分岐
rubyspec の人に「バグっぽいのは rubyspec に書かずに報告してよ」って言ったことがあるけど
こんなん
自分たちにはバグっぽいかどうか判断できないし
昔はそれなりに報告してたつもりだけど返事がないことが多すぎるので諦めた
とか言ってた
しない場合は前半いらないんじゃね
実装互換性がほしいのでやはり必要じゃないかな
未定義だった動作のspecっておかしいよ
まあ、どうでもいいや。
未定義かどうかがわからない
した場合、「1.9.2-p0ではそこは未定義だったので失敗する」ということになる?
だからRuby的な「未定義」とか関係ないんだって
なかださんはspecという言葉に過剰反応している
"spec"って言葉に引きづられているんだったら、Ruby的なspecとは別次元の話
IEという喩えが通じないんだと何がいいんだろう
前から「あれはspecじゃない」とはいってる
rubyspec は言語仕様ではなく MRI の実装仕様書
まあ実装仕様書だとしても未定義なことは出てくるが
実装観察書
RubySpecはRubiniusがどうあるべきかなので「仕様」といってもまぁまちがいじゃない
RubiniusSpecじゃん
そう
実装所見
典拠がMRIってだけすな
RubySpecの人向けに我々の思う「spec」について喋ったもの "THE SPECIFICATION of Ruby, which MRI people say, is imaginary one."
ruby 1.9 needs ruby
そういえばruby1.9でrubyがビルドに必要な理由を知らないことに気づいた
BASERUBYにヘンなの指定すればわかる
使うから。
「ビルド」に必要かどうかは「ビルド」の定義によるかなあ
いま、必要だと反応した人達は、普段から必要な人達。
tar玉引っ張ってくる程度の付き合いの人なら不要。
じゃあ言い直してみよう
ruby 1.9系でconfigureにbaserubyを要求されるのは何に使うからだろう
make distcleanしてからやってみればすぐわかる
ほう
insns.defからの*.incの生成
ふむー
enc/trans/*.transからのソースの生成
transソースの生成はminirubyだけどクロスだと手元のか
というかmake prereqね
で、
今make prereqしてみたら通んねえわけだが...
{ko1_ndk} http://www.atdot.net/sp/readonly/8zfcbl_shyouhei
こんな。
{sora_h} ./tools/preproc.rb: 3: require: not found
なにこれ...
shで実行されてるみたいな
ripperェ...
うむ
toolsってなに
ext/ripper/tools/
ああ、ext/ripper/ か
RUBYが未定義か
ばぐぽいな。
soraおめでとうsoraのおかげでバグを見つけた
!!!
RUBYが空とかどうやったら起きるんだべ
{shyouhei} > cd -P /home/shyouhei/ruby.devel.svn/trunk/ext/ripper && exec make -f depend top_srcdir=../.. srcdir=.
exec make -f dependだからでは?
なんだそりゃ
そこにRUBY=$(BASERUBY)を追加かな
あったあった
ruby が空 (sora) とかすごいな
前からこうだっけ?
2009-03-14からはこうみたい
うける
まあなんというか割と他人事ぽい
ripperはコンパイルするだろ
起きないし。
prereqでやらなけりゃ起きないか
普通にやる分には普通にext/ripper/Makefileで作られるからねえ。
make-snapshotもENV["RUBY"]セットしてるし
trunkでprereqる酔狂が今まで出現しなかったってことか
いつもやってるんだけど
GNUmakefileの中からmakeを実行するときにRUBY="$(RUBY)"で渡してた
export RUBY してるし
おまけにripperってターゲットではしっかりRUBY="$(RUBY)"してたという
