ruby1.9パッケージ準備中
Ruby 1.9.0のリリースにそなえてruby1.9パッケージを作ってみている。今ところの予定ではrakeもrubygemsもruby1.9.debとlibruby1.9.debに含めるつもりでいる。何か要望が出てきたらパッケージを分けるなどするかもしれない。
残る課題はパッケージバージョンの決定。1.9.1がリリースされるのを前提にしていたために、すでに1.9.0+YYYYMMDD-Xというバージョンを付けてしまっている。まさか1.9.0がリリースされるとは、というわけなのだが、kmutoさん案の1.9.0+rel-Xにしようかと考えているところ。
パッケージを作っていて気付いた10月頃からの変化はというと:
- rakeとrubygemsが加わった
- soapがなくなった
- net/ftptls.r、とnet/telnets.rb、その他いくつかのライブラリもなくなった
$LOAD_PATHに埋め込まれているバージョンが1.9から1.9.0になった$LOAD_PATHにvendor_rubyというパスが加わった- make golfが加わった
言語的な変化ももう一度チェックしなおさないとな。
追記(2007-12-26-1): 1.9.0がリリースされたみたい。Ruby 1.9.x以降のRubyについてはバージョンの三桁目(teeny)が0のときは開発版、1以上になったら安定版というルールになった(はず)なので、今回のはまだ開発版ということになるのだと思う。このため、少なくとも1.9.1がリリースされるまでは、これまで通り、1.8.xがDebainのデフォルトのRubyであり続ける。実際には1.9.1よりもリリースが進んで、かつ、何らかの(たとえばメンテナ間での)意見を聞いてからということになると思う。なお、DebianのデフォルトのRubyはruby-defaultsパッケージが提供するrubyパッケージで決められている(主メンテナはukaiさん)。
追記(2007-12-26-2): Vine Linuxのrubyパッケージでも同様にRuby 1.9.1がリリースされた後、適当なタイミングで移行(するかどうかなど)を検討することになるのだと思う。
追記(2007-12-26-3): tarballはruby-1.9.0-0なのね。-1とか出るんだろうか。
Capistrano 2.1とRuby 1.8.6
Capistranoをいじってみようとしたところ、以下のようになってしまった。
$ bin/cap You are running Ruby 1.8.6, which has a bug in its threading implementation. You are liable to encounter deadlocks running Capistrano, unless you install the fastthread library, which is available as a gem: gem install fastthread Please specify at least one action to execute. Usage: cap [options] action ...
CapistranoのMLやレポジトリのログにあたっても具体的な影響についての記述はないのだが、少なくともCapistrano自身のテストでデッドロックが発生するということらしい。というわけで、実際どうなのよと試してみたところ、1.8.6-2では現象が起きることが確認できた。
$ rake [...] Loaded suite /usr/lib/ruby/1.8/rake/rake_test_loader Started ... [...] ...deadlock 0xb76afb14: sleep:- - ./test/../lib/capistrano/gateway.rb:57 deadlock 0xb7c3a700: sleep:- (main) - ./test/../lib/capistrano/gateway.rb:64 ./test/../lib/capistrano/gateway.rb:64:in `wait': Thread(0xb7c3a700): deadlock (fatal)
また1.8.6.36-1や1.8.6.111-2では現象が起きないことも確認できた。というわけで、1.8.6.36以降ならfastthreadがなくても問題なさそうに思える。毎回メッセージが出てくるのはわずらわしいが、どうしたものだろうな。
ruby1.8_1.8.6.36-1
1.8.6-p36にバグ修正(C++な拡張ライブラリでコンパイルエラーになるというきびしめのやつ)のパッチを加えてパッケージングしたものをuploadした。パッチ具合いは大丈夫かな。
ruby-prof 0.5系のオブジェクトアロケーションプロファイルに対応させるためのパッチ(ruby-Bugs-11497)を入れちゃおうかどうしようか迷ったんだけど、今回は入れないままにした。まあ、それ以前にruby_1_8にしようかと、けっこう悩んだりもした。手がまわらなくなりそうだから止めたけど。
rpmはdebでの様子を見てからにしようかと。
Ruby 1.9の非互換
Ruby 1.9での新機能や変更はChanges in Ruby 1.9に詳しくまとめられているのだが、最近の更新がないようで少し古くなってきているみたい。ChangeLogを追っかけて続きを作…… るというのは難しいので、テスト内容の違い、RDocエントリの違い、おぼろげな記憶などをたりよりに少しだけ探ってみた。あー、非互換のところだけ。
- 文法上ダメになったこと
if、elsif、unless、whenの条件に続けて:を書き、それ続けて実行文を書いてしまう- ブロックパラメータにインスタンス変数を指定する
- ブロックパラメータに同じ変数を何度も指定する
- 挙動が変わったこと
Object#{id,type}なんかがなくなったKernel#{chomp,chop,sub,gsub}{,!}やKernel#{scan,split}などがなくなったException#to_strがなくなったThread.{critical,critical=}がサポート外になり、Thread.exclusiveがなくなった(YARVの制限?)evalによるローカル変数の定義ができない(YARVの制限?)eval("foo = 1"); eval("foo") #=> NameError- 多重代入が整理された結果、一部の挙動が変わった
x = 1; a = *x; a #=> 1.8では1、1.9では[1] x = []; a = *x; a #=> 1.8ではnil、1.9では[] x = [[]]; a = *x; a #=> 1.8では[]、1.9では[[]] x = []; *a = x; a #=> 1.8では[[]]、1.9では[]
- ブロックパラメータでも似たような状況がある(もう少し複雑な条件?)
- クラス変数への値の設定の際、上位クラスを見なくなった(このあたり)
attrがattr_readerのaliasになる(予定? 今は第二引原がtrueかfalseの場合に特別扱いしてくれているが、そのうちダメになる?)- ブロックパラメータがブロック内でローカルになった(外側の変数と重なっても例外にはならない)
- ブロックローカル変数ができた(外側の変数と重なっても例外にはならないが、そのうち例外が上がるようになるのかな?)
foo {|a; b, c| } # bとcがそれ Array#[n,m]へのnilの代入でnilが代入されるようになった?cが文字列を返すprintやputsがnilを「nil」と出力せず空文字列を出力するようになった
とりあえずこのくらいは分かった。見落としがあるかも(ありそう)。それとも意外と少ない? (Threadまわりとか動作上の変化はないのかな?)
そうそう、Changes in Ruby 1.9にあるfoo[]{|x|}というのは一時期たしかにできてたみたいなんだけど、それはたまたまそうなっただけらしく、今(r12207あたりから)は再びできなくなっている。
ruby-termios 0.9.5
田中哲さんに送っていただいたパッチを取り込んでバージョン0.9.5としたものをリリースした。
ruby1.9の各アーキテクチャでのbuild状況 3
さっそくbuildできないぞバグ(FTBFS)をくらってる(hppa Bug#426267、ia64 Bug#426134)。というかここんとこは毎回くらってる。なんとかしなきゃ。
ちなみにDebianでのbuild状況はbuilddのページで参照できる。久々に見たらなんだか見易くなってるな。
