なるせにっきスマートフォン用の表示で見るなるせにっきこの広告は、90日以上更新していないブログに表示しています。noexpandtabと設定されているようです。MLに投げてみようか?ためらう理由が分からない。みんなruby-listにはもっと気楽に投げていいと思うんですよ。charset=utf-8]結構ML連携に失敗している事はあります。LKMLは全員が口をそろえて、あんなん全メール読んでられっか。--rebaseがデフォルトの上位ラッパーを使うべきな気がするのです。Rubyだとbisectがスクリプトで出来るのか。bisect用スクリプトをtool/あたりに入れておいて欲しいな。RubySpec対応の進捗コミット権を得たmameさんが大暴れした結果、trunkでのtest失敗が560→485→263→188→112などと激減。MSPECOPT=spec/rubyspec/library/net/1.9の互換性つれづれこの項目は(この項目に限らないのだが、これは特に)編集・コメントに成瀬の主観が混じっているため、そこを差し引いて読んでください。yehudaから1.9-shimが必要という話を聞いている。ActiveSupportが吸収層を持たなきゃ行けないのはおかしいとな。Zygmuntowiczと共に主導的役割を果たしている人。yuguiさんと他のチャンネルで話しているのであろう。1.6向けにknuさんが中心になって提供した互換レイヤ・追加モジュール。shim方式は機能追加が主だった1.6→1.8では機能した。まるっと1.9じゃそれも困る。shimというか1.9再実装になる事が想定される昨日まで、RubySpecはtrunkで500個以上の失敗があった。それは1.8と1.9の非互換変更の個数を示しているわけで、この目標を達成するには1.8の実装をそれだけ変えないといけない事を意味する。新しいリリースで既存コードが動かないのは深刻な問題、とyehudaに言われている。1.9.2で書いたコードはずっと動くようにしたい。1.9/1.8で両対応にするための負荷軽減」であろう。こちらでは非互換変更に対して不満を述べている。5.10やMicrosoftは互換性維持のために多大なコストを払っている。それがMicrosoftの力の源泉だし。Rubyにはuseも__future__もないのが下位互換を難しくする。__future__useも__future__も今回の下位互換の話とは全く関係ないと思う。Ruby的にはいちいち指定しなくても使えるようにぶち込んでしまう。ソースの前処理レイヤのようなものを公開する気が皆無なのも影響しているのだと思うが。namespaceが互換性問題を救うと思うんだ。Riteでなんでも解決的なにおいが過去のバージョンの挙動を自在に取り出せるーとかなると確かに超技術だけど、維持できる気がしないのと、C実装部分がねぇ。組み込みクラスにメソッド追加ってのはリスクのある行為なのですよね。必要なライブラリがjarで固まってるのは移行とは言わんか。必要な互換性バージョンをマジコメるしくみはダメかな。requireの話はgemに加えてIronRubyのrequire拡張を念頭に置いている。Javaでjarに固めるのはRailsで関連ライブラリをvendor下に置くのと同じですかね。マジックコメントはありえないと思います。それは完成度100%に漸近するだけの話で、ようするに停滞しているってことなわけです。あ、これは設計図がちゃんとある場合ね。作りながら考えてる時は手戻りはある。その後発散してQCの話に。影響範囲の大きい話をする時は、最初から着地点を想定して話さないと容易に発散してしまうのです。思うにYehudaが本当に困っているのは1.9.1→1.9.2でも連発されている非互換変更で、彼が要求するべきだったのは作れもしない1.9-shumではなく、非互換変更をcoreの外にいる人間がより知りやすくする方法だったんじゃないかなぁ。そうそう、Rubyのユーザは「Rubyに理不尽な仕様があった場合、その挙動は容赦なく変更される」ってのは知っておくべき事だと思います。2010-02-26ちょっと忙しいので概略だけ。2018-02-14はじめての投資SEGV探偵が往くはてなブログをはじめよう!nurseさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。