Log from #ruby-ja @ ircnet

2011-09-09.txt

mame1: RubySpec の話題で盛り上がってるのだな
mame1: RubySpec はテストフレームワークが複雑すぎてコアのバグが起きたときにデバッグが大変
mame1: というのは細かい話かな
mame1: RubySpec のコミット権持ってる Ruby コミッタってどのくらいいるんだろう
ko1_ndk: そのへんに brian ford が居ます
ko1_ndk: なんか伝えますか
mame1: おうえんしてます！
ko1_ndk: (1) 言語共通のテストは RubySpec にまとめましょう！　そうすると，テストをみんなで共有できて嬉しいです．
ko1_ndk: (2) test/* は MRI 特化したテストがあるので，RubySpec にするのは無理です
ko1_ndk: (3) いや，だから共通部分は RubySpec にまとめようよ
ko1_ndk: という流れでしょうか．
mame1: 会話になってないよね
ko1_ndk: CRuby 的には，test/* の意図を汲み取って RubySpec に入れてくれるといいですよね
mame1: test/* に入ったカバレッジ向上のための大量のコーナーケースを
mame1: 言語仕様として固めたい？
ko1_ndk: 誰が苦労を被るか，って話だと思うんですが
ko1_ndk: JRuby とか，Rubinius とかは，カバレッジを上げるために何かしてるんですかね．
mame1: test/* 消せとは言ってないんじゃない
mame1: 少なくともこれから増やす分は RubySpec にしよう
ko1_ndk: そうなのか
ko1_ndk: 共通部分は，と読んでいたんだけど
ko1_ndk: 全部，なんですか
mame1: これから増やす処理系依存でないテストは、RubySpec にしよう
ko1_ndk: 処理系依存かどうかの判断って結構難しそうですよね
mame1: 今ある test/* をどうこうしろとは言ってない気がする
mame1: 消せとも、RubySpec に移植しろとも
mame1: git なのが問題なんじゃないだろうか
ko1_ndk: ruby-lang-spect とか
ko1_ndk: ruby-lib-spec とか
ko1_ndk: 分かれると見る側は嬉しいのか，ディレクトリが分かれているのか
ko1_ndk: MRI 変えてテストを一緒に追加できないのは disadvantage だと思う．
mame1: MRI 変えて？
ko1_ndk: 文法要素を変えて，でもいいですが．
ko1_ndk: MRI の変更 -> rubyspec へ変更をコミット，はおかしいと思う
mame1: ああ
ko1_ndk: 一緒にテストをコミットしたほうがいいと思う
mame1: 他の処理系を遠慮無く撃墜ですか
ko1_ndk: いや，そっちじゃなくて
mame1: ああ、コミットをまとめたいということか
ko1_ndk: yes.
ko1_ndk: 久々に rubyspec 動かそう．
...
ko1_ndk: 今 brixen に話をしている
mame1: なにを？
ko1_ndk: rubyspec の話
ko1_ndk: カバレッジの話は，入れればいいんじゃね，と言われた
mame1: brixen は気にしないでしょう
mame1: 気にするのは我々
ko1_ndk: Rubinius 用の corner case も，jruby 用のコーナーケースも
ko1_ndk: 入れちゃえばいいんじゃないか，と
ko1_ndk: とりあえず，考え得る disadvantage を
ko1_ndk: 並べるという．
ko1_ndk: 宿題をもらいました
ko1_ndk: 私の環境が悪いのかな
ko1_ndk: 64bit Linux 環境だとまともに動く
ko1_ndk: 一度 clean してやってみます
ko1_ndk: http://t-a-w.blogspot.com/2007/02/making-ruby-faster.html
ko1_ndk: こんな話があったんだなあ
mame1: かんがえうる disadvantage か
tal0: windows対応する気はどのぐらいあるんでしょうか＜rubyspec
tal0: linux rubyのコンパチビリティテストには良いと思うけど。ポータビリティを向上させる気があるのか
uj_: https://github.com/rubyspec/rubyspec/contributors
mame1: windows かあ
mame1: 1.9.2 リリース当時は「だれかやれよ」「おまえやれよ」って言い合ってたな
uj_: rubyspec contributorsは分かるけどcommitterは分かりませんね
tal0: Finished in 134.953125 seconds
tal0: 3456 files, 16823 examples, 220283 expectations, 99 failures, 608 errors
tal0: >ruby -v
tal0: ruby 1.9.4dev (2011-09-06 trunk 33199) [i386-mswin32_100]
uj_: とりあえずrubyspec contributorsはruby committersより多いことは分かりました
tal0: しんどい。
mame1: 一個貢献したらコミット権進呈の方針だよね
uj_: いわゆるtermtter方式
mame1: termtter がはじめたの？
uj_: まあたぶんrubyspecの方が先ですね・・・
ko1_ndk: disadvantage スレを作らなければ
tal0: なんかでwindows対応の為にforkを削ってるみたいな文章を見た気がするので少しはやる気あるとはおもってるんだけれど、そのやる気度を知りたい
mame1: windows でたよりになる人は当時はいなかったけど
mame1: Luis とかどうなのかな
nurse: Windowsはかなり論外なテストが多かった気がするんだけど、
nurse: そもそもgitを入れるところからしてWindowsはだるい
mame1: MRI trunk 用のテストとして RubySpec を使うと
mame1: 仕様が決まってないのに RubySpec にテストが追加されるのはいいのかな
mame1: ガード書けって言われるんだろうな
uj_: 僕は1.9.2リリース以前のrubyspecにしか関わっていなかったのだけど、
uj_: 当時はguardは
nurse: そもそも俺らが書きたいのはspecじゃなくてtestなんだけど
uj_: MRIに関しては1.8と1.9という大雑把なくくりだけで分けていたけど
ko1_ndk: おお
mame1: おお
ko1_ndk: ＞仕様が決まっていない
uj_: いまは1.9.2, 1.9.3みたいな細かいくくりでやっていたりするのかな
mame1: そのはず > 1.9.2/3
uj_: もしそうでないのなら、1.9全体で同じ挙動のみのspecを書くべきという指針ということかな
uj_: ふむふむ
uj_: ちゃんと区別する方針
mame1: 1.9.1 は brixen に正式リリースと認めてもらえなかった
mame1: 1.9.2 からは spec 化するにたるものだと認めてもらえた
mame1: から、といっても 1.9.3 は出ていないが
uj_: ふむふむ
mame1: 1.9.2 まではリリース毎に「これが本当の 1.9 のはじまりだ」って言ってた気がするしな
uj_: 1.9.2「1.9.1がやられたようだな・・・」
ko1_ndk: 俺たちの ruby 1.9 はまだ始まったばかり
nurse: ていうか、なんで俺らがdisadvantageを出さないといけないんだ?
nurse: 受益者がこっちの利益を出すか、作業全部負担するもんじゃないの
nurse: MLでかけ
mame1: ささださんがお給料もらってやるんじゃない？
uj_: 1.9.3の考えうるすべてのdisadvantageですか
uj_: 1.9.2と比較して。
ko1_ndk: 東大はそれにお給料くれるんだろうか．
mame1: いやいや (笑)
nurse: RubySpecのでは
mame1: EY からもらうのかと
uj_: 1.9.3を使うと、String#preventを使うことになり、コンピュータ専門用語で日常語でないprependという単語に慣れ親しんでしまうという危険性がある
uj_: とか
ko1_ndk: 受益者は CRuby 以外が
uj_: rubyspecのか
ko1_ndk: なるべく統一された仕様となり，嬉しい人
uj_: ぼくはrubyの中身をはじめてさわったときは
uj_: rubyspecを手がかりに勉強して
uj_: とても効率的だったきがします
uj_: あ、advantageだ・・・
mame1: その受益者が「統一すると MRI コミッタにもこんないいことあるよ」と説得してこいと
uj_: 効率的すぎてヤバい、みたいな意味でdisadvantageに。
mame1: なんかあるのかな
mame1: RubySpec にしたらハゲが直りました
ko1_ndk: まだ spec としていいかわからないものを
ko1_ndk: spec として登録するのはどうなの，ってのはなるほど
mame1: ささださんのお給料に貢献した
mame1: で、ガード書けって言われるんだろうけど
mame1: めんどうくさいよね
mame1: 1.8 でも動くように 1.9 のテストを書くというのは
nurse: というわけでお怒りのメールを書いた
mame1: 結構嫌かもね
mame1: spawn が使えないとか
nurse: が、英語が酷すぎて通じない気もする
nurse: それはまだマシで
nurse: syntaxレベルで違うとファイルを分けないといけないという×ゲームが
mame1: もうあるよね確か
mame1: > For example I can't find which is the expectation 4 or 5.
mame1: のところは charles の返信を読むまで意味がわからなかった
nurse: もうあるよねはどこに？
ko1_ndk: trans> Test suite output differences and remarks about guards in the trunk are all driving attention away from that.
ko1_ndk: g:translate bot (en>ja): トランク内のテストスイートの出力の違いとガードについての発言は離れているから、すべての運転注意です。
ko1_ndk: m:translate bot (en>ja): テスト スイートの違いを出力し、トランク内の警備員についての発言からは、すべての運転注意です。
uj_: syntaxレベルといえば
mame1: rubyspec にファイルを分けてる例があったような
nurse: ありますね
uj_: shyouheiさんが1.9 syntaxを通す1.8.8を出すみたいな話が数年前にしていたようなしていなかったような
uj_: パースできるけど実行時にエラーみたいな
mame1: リソース不足で諦めの方向
nurse: それを断念したってのが1.8.8がキャンセルになった有力な理由の一つ
uj_: なるほど。
ko1_ndk: trans> Anyway why you want us to blame RubySpec?
mame1: そんなモチベーションのわかない作業もなかなかないよな
ko1_ndk: g:translate bot (en>ja): とにかくなぜあなたは私たちはRubySpecのせいにしたいですか？
ko1_ndk: m:translate bot (en>ja): とにかくなぜ私たちを非難する RubySpec をするか？
nurse: 別のバグが出ちゃってそれを潰すのが思ったより大変で、困難やるより他のことやった方が的な
uj_: 同意
nurse: blameよりcritisismとかそういう感じかしら
ko1_ndk: なぜあなたは我々に RubySpec を非難させたいのか
nurse: そんな感じ
uj_: transr> なぜあなたは我々に RubySpec を非難させたいのか
ko1_ndk: g:trans_r (ja>en>ja): なぜあなたは私たちにRubySpecを非難するか
ko1_ndk: m:trans_r (ja>en>ja): なぜ私たちを批判する RubySpec とするか。
nurse: おれはRubySpecなんか嫌いなんだってのは
nurse: ここ1年くらいではわたしがRubySpecのコミット数トップなのをあわせて見て頂けるといいすね
nurse: 他の人が壊したの直してるだけだけど
ko1_ndk: そんな努力が
mame1: 向こうに
mame1: 向こうに何やれって言ってるの？
tal0: すごい貢献している
nurse: workはtest-all監視してmspecに翻訳したらって意味だった
ko1_ndk: それが一番いいような気はする
mame1: それはエスパーでないと通じないな
ko1_ndk: 誰がやるの，って幹事だけど
ko1_ndk: 感じ
nurse: とりあえず俺はやりたくないって意味である
nurse: 背景として翻訳するのがだるいから最初からRubySpecに入れてよって言ってるので、やだよぼくRubySpecきらいだもんってダダこねてる図
mame1: 普通に assert って書きたい
nurse: should == きもい
uj_: assert_equal a, b
nurse: 宣言的に書きたいってのはすでにメールに書いた気はする
uj_: a.should == b
mame1: それも意味わかんなかったけど
mame1: assert って意味なのか
uj_: 相互変換するwrapperの開発・・・
nurse: ていうか、これってRuby自体のテストだから、
nurse: あんまりRubyのオブジェクト自体を拡張するのは好かなかったりもする
mame1: 宣言的っていうとむしろ a.should == b のように DSL っぽく書きたいとも読める
nurse: minitest自体が拡張してるのであれですけど
nurse: そうよめるのか
mame1: 自然言語的というか。
mame1: Ruby のオブジェクトを拡張していいのは小学生までだよねえ
ko1_ndk: > RubySpec keep finding edge cases and bugs in MRI that Ruby developers cannot learn about in any other source.
nurse: Rubyが信用できないからテストしてるのにテストでRubyの変態機能使ってどうすんねんと
ko1_ndk: ruby developer って MRI developer じゃないか
mame1: テストじゃなくても変態機能はジョークでしか使わないのがぼくのジャスティス
mame1: Luis の話だと windows で動くようにはなっているのか
nurse: Luisはmingwだからなぁ
nurse: 平気で/tmpとかenvコマンドとかに依存してた気がするんだけど
mame1: brixen か誰かが doze 死ね派だった気がする
mame1: いい感じに釣れてるな
tal0:  /tmpに依存してる
tal0: mingwもそこは引っかかるはずなんだけど
tal0: LuisはRubySpec使ってるとはいってるけど File.expand_path specsしか使ってない？？
ko1_ndk: 日本語だ
ko1_ndk: 機械翻訳？
tal0: これが機械翻訳なら世界を獲れる
ko1_ndk: 確かに．
ko1_ndk: 私の英語もこれくらいうまくなれれば
tal0: TLで割と英語の話は流れて勉強しようかなと思うんだが、そもそも英語で何を話したいかと考えると、まず技術を勉強しろ俺と言う気もしてどこに力を入れるか揺れている
ko1_ndk: 技術の勉強を英語ですれば
ko1_ndk: 譲歩
tal0: 一応頑張ってruby-coreを読むようには。
ko1_ndk: を，誰に求めているのかよくわからないのですが．
ko1_ndk: MRI developer なのか，誰か test/* を移植しろよ，って言ってるのか
tal0: そのまま動くか、機械的にトランスレートできればいいんだと思うんだけど、
tal0: RubySpecがtest/*をそのまま使えない理由がよくわかっていない
tal0: だれか教えて！
ko1_ndk: rubyeventmachine が悪いの亜ｋなあ
ko1_ndk: http://redmine.ruby-lang.org/issues/5299
tal0: 第一感はそんな気がしますが
uj_: pizzaed
ko1_ndk: Enumerating advantages / disadvantages over them are not
ko1_ndk: effective to solve the situation it seems.
ko1_ndk: 卜部君にこんなことを言われてた
ko1_ndk: advantage と disadvantage を挙げようとしていたのに
ko1_ndk: > Or why not just include `make RubySpec` in `make test-all`?
ko1_ndk: これはいいような気がする
ko1_ndk: が，F が増えるんだよな
uj_: make test-spec
ko1_ndk: test-rubyspec  desune
uj_: ですね
ko1_ndk: >       @tmpdir = "c:/tmp"
ko1_ndk: これは酷い！！！
uj_: www
tal0: expand_pathのテストだけで実際のファイルとかは作ってないみたいなんだけど、
tal0: expand_pathってファイルシステムどこまでみてるんだっけとか考えてコード読んでる
tal0: うー 英語が読みこなせない。
tal0: If you're used to a tool, getting full to speed and covering those
tal0: guards inside other tool can be time challenging and hard work, sure.
tal0: be がVかな？
tal0: (If you're used to a tool, getting full to speed ) and (covering those guards inside other tool can be time challenging and hard work, sure.) こうか
ko1_ndk: http://www.atdot.net/sp/view/b158rl
ko1_ndk: こんな感じでまとめてみました
ko1_ndk: どうだろう
ko1_ndk: (4) trunk is not unstable.  For example, some modifications are revertd 
ko1_ndk: soon.  Should we add such features as Specs?
ko1_ndk: こう書いてみたけど
ko1_ndk: 実験的なコードでも spec を書くのは大事だよなあ
tal0: そうですねぇ
ko1_ndk: trans> Shouldn't ruby-core help maintain an implementation-agnostic Ruby behavioral test suite? If so, why isn't that happening, and why couldn't it be RubySpec? If not, why not?
ko1_ndk: g:translate bot (en>ja): 実装にとらわれないRubyの行動テストスイートを維持するためのruby -コアではないでしょうか？もしそうなら、なぜ起こっているわけではない、そしてなぜそれがRubySpecことができませんでした？そうでない場合は、なぜでしょうか？
ko1_ndk: m:translate bot (en>ja): Ruby コアは、実装にとらわれない Ruby 行動テスト スイートを維持するべきではないか。もしそうなら、なぜそれが起こっていると RubySpec することができませんでしたなぜそれか。場合は、なぜですか？
ko1_ndk: どうしようかな
ko1_ndk: > We all pay, MRI and other implementation developers pay the price.
ko1_ndk: ってのが，
ko1_ndk: MRI developer に pay しろって言ってるんだよなあ．
...
nurse: a paper tiger って通じるんだろうか