Ruby 1.9.0 リリース 46
ストーリー by Acanthopanax
鋭意開発中 部門より
鋭意開発中 部門より
/.jと同じく、Rubyも1.9.0をクリスマスリリースしていたようだ。当初予定していたRuby 1.9.1ではなく、Ruby 1.9.0となったのは、期待していたほど安定したものではないためとのこと。ただ、予定していた非互換な変更はすべて取り入れられたとのことである。
/.jと同じく、Rubyも1.9.0をクリスマスリリースしていたようだ。当初予定していたRuby 1.9.1ではなく、Ruby 1.9.0となったのは、期待していたほど安定したものではないためとのこと。ただ、予定していた非互換な変更はすべて取り入れられたとのことである。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
まつもとさんと笹田さんのインタビュー記事 (スコア:5, 参考になる)
まつもと×笹田、Ruby 1.9を語る [atmarkit.co.jp]
む、たしかに速くなっている。 (スコア:4, 参考になる)
真っ正直にフィボナッチ数を計算する関数を書いて試してみたが、1.8の処理時間の20%くらいで1.9は結果を出すね。
Re:む、たしかに速くなっている。 (スコア:1)
分かっていて書いているのでしょうが、
フィボナッチ数の計算などはまさに1.9が高速化した部分なので、そういう結果になりますね。
一般的なRubyアプリケーションがそれだけ早くなるかというと、まったくそうではありません。
参考）
まつもと×笹田、Ruby 1.9を語る [atmarkit.co.jp]
高速なRuby用仮想マシンの開発（笹田耕一さん） [nabble.com]
http://ustream.tv/channel/ylug-83th-kernel-reading-party [ustream.tv]
It's not who is right, it's who is left.
Re:む、たしかに速くなっている。 (スコア:1)
なるほど、階乗を再帰で求める関数を書いてみたけど、1.7倍程度の速度しか出ないね。階乗の計算とフィボナッチ数の計算のどこに質的な差があるのかなあ？
Re:む、たしかに速くなっている。 (スコア:1)
フィボナッチ数列: 自分自身を2回呼ぶ→5倍
たらい回し [srad.jp]: 自分自身を3回呼ぶ→50倍
って感じですね。「関数呼び出し」のオーバーヘッド改善とかかな。
5倍速？ (スコア:0)
Re:5倍速？ (スコア:3, 興味深い)
そう。5倍も速い。
Re:5倍速？ (スコア:1)
たらい回しは 50倍早かった (スコア:1, 興味深い)
下記のようなコードだと，
- 1.8.5 → 3.5秒
- 1.9 → 0.07秒
- jruby-1.1b1 → 0.68秒
なんて感じで，たらい回しが50倍ぐらい早くなっていました．jruby も早い．Re: (スコア:0)
少し意外。
luaがレジスタマシン（というのかわからないけど）、rubyがスタックマシンということで、
luaの方が速いと思っていたんですが。
Re:む、たしかに速くなっている。 (スコア:2, すばらしい洞察)
rake, gem (スコア:2, 参考になる)
- rakeとgemが標準付属。
- Enumerable強化。enumerator組み込み。
- m18n。
- Hashが順序を保持。
あたりが大きい。
あと、何も知らずに1.9.0でRubyデビューしていらん苦労をする人が続出しそうなのが(ちょっと前から散見される)怖いな。
Re:rake, gem (スコア:4, 参考になる)
まず，zlibが添付されていないので，zlibを入れていないとzlib.dllがありませんエラーがでます．
http://www.zlib.net/ [zlib.net]からコンパイル済みzlib.dllを落として，
パスの通ったところにファイルを置きます(ファイル名がzlib1.dllになっているので，zlib.dllにリネーム)．
これでgemは動くようになるのですが，そのままgem install hogehogeすると，
ダウンロード先，インストール先がなぜかC:\LANの下になります．
これは，ruby\lib\ruby\1.9.0\i386-mswin32のrbconfig.rbファイル内で，
あと，結局最後まで直らなかったのですが，gem update --systemがエラーで止まります．
一応rbconfig.rb内で，Config = RbConfigとやってはいるようですが，
なんでエラーになっているかはさっぱり分かりません．．．
Re:rake, gem (スコア:3, 参考になる)
ちょっと前まではRuby公式から「ダウンロード」でたどれるWindows版Rubyバイナリのページ [ruby-lang.org]が
- ruby1.6.4のzip
- ruby1.6.8のzip
- ruby1.8.6のzip
- ruby1.9.0のzip
という素敵でフラットな一覧になってて「よくわかんないけどとりあえず一番番号が大きくて新しそうな1.9.0をダウンロードしました」という惨事が少なからず起きてました現在はunstableというディレクトリが掘られてるので今後は少なくなるような気がします
Re:rake, gem (スコア:1, 参考になる)
それでも、実際には一番新しいstableリリースである1.8.6-p111ではなくて、一番下にある1.8.6-p36をダウンロードしちまう輩は必ずいる。
One-Click Ruby Installer [rubyforge.org]ユーザーなのでその手の話とは無関係なAC
Re:rake, gem (スコア:1)
と昨日インストールするときに勘違いしてしまいましたよ。
Re:rake, gem (スコア:1)
# ついでに l10n (localization)
Hashが順序を保持 (スコア:1, 参考になる)
Re:Hashが順序を保持 (スコア:2, 参考になる)
o preserving item insertion order
となってますので，Hashは公式に作成順序を覚えるようになったみたいですね。
Re:Hashが順序を保持 (スコア:1)
>別クラスにした方がよくね？
マニュアルのほうを書き換えてしまったほうが早いでしょう。
「rubyのHashは順序情報付き連想配列です。」と。
Hashの取り出し順序が予測不能である事に依存したコードを書いている人が居ない限り問題ないですよね。
Lv5以下の社員全員にデスマーチ！
Re: (スコア:0)
Hashの管理範囲から外れてるような。
別クラスにした方がよくね？
Re:Hashが順序を保持 (スコア:2, すばらしい洞察)
何かの都合で1.9より前のRubyで動かすときにハマる恐れが高い。
そういう心配をしなくていいくらい月日が経ってからじゃないと、結局
このことはどうでも良いことではないだろうか。
まぁ、デバッグとかするときに、少々加えた順序がわかって役立つかも
しれない。
Re: (スコア:0)
むしろこれが期待できるとエクセルを読み込んだとき{"sheet1"=>0,"sheet2"=>1,...}てなhashを作る必要なくなるからうれしい。
Re:Hashが順序を保持 (スコア:1, すばらしい洞察)
Re: (スコア:0)
DelphiのTStringsを思い出してしまったぜ・・・。
# というか、この辺はまつもとさんの感覚のみか
Re: (スコア:0)
俺はPHPのarray関係のうんこ関数群を連想して、
ゲロがでそうになった。
Re: (スコア:0)
までの流れを見る限り、CRuby(とJRuby)という「特定のRuby(言語)実装におけるHashではたまたま順序が保持されるようになった」だけという認識でいたほうがよさそうですね。
言語仕様としては定めていない、と。(というかまともな言語仕様ないし)
順序付きHash (スコア:0)
ある程度互換性はあきらめてるみたいだし。
Re: (スコア:0)
についてもう少し知りたい。キーの順序を保持？
連想配列の実装が二分木になったとか、そういう話ですか？
Re: (スコア:0)
Re: (スコア:0)
要素の追加順序を保持するHashクラス (スコア:1)
[ruby-dev:24570] [nagaokaut.ac.jp] (と、 #1272878 [srad.jp] で紹介されている [ruby-list:43896] [nagaokaut.ac.jp] を含むスレッド) を読むと、ハッシュテーブルの各エントリーに、追加順で次のエントリーと前のエントリーへのポインターを付けて、二重リンクリストにしてあるようです。キーによる問合せをしたい場合はハッシュテーブルとして使い、要素を列挙したい場合はリストとして使います。
この方法だと、当然ながら、必要な領域の増分は 1 要素あたり定数、追加や削除に必要な時間の増分は 1 操作あたり定数、列挙は 1 要素ごとに定数時間でできます。削除が不要な場合は、追加順を保持しない通常のハッシュテーブルのほかに追加順を保持するためだけの配列なりリストなりを持つことが多いと思いますが、この方法に比べて Ruby で採用している方法には削除も速いという利点があります。
# Ruby はほとんど使っていません。
クリスマスリリースではない (スコア:2, おもしろおかしい)
Re:クリスマスリリースではない (スコア:2, すばらしい洞察)
ChangeLog [ruby-lang.org]
Re:クリスマスリリースではない (スコア:1, 参考になる)
各地の公式mirrorに行き渡るまでリリースのアナウンスは
控えられます。
ついでに言うと
バージョン管理システムに、RELEASE tagが付いた日
isoファイルが作成されてftp鯖に置かれた日
アナウンスがされた日
と三つあります。
Re: (スコア:0)
> isoファイルが作成されてftp鯖に置かれた日
> アナウンスがされた日
> と三つあります。
なんか、「二人の記念日」がいっぱいあるという話を連想しました。伝聞なので、どなたか検証させてください。
いや、あなたがたカップルの記念日の話ではなくて…。
Re: (スコア:0)
2.結婚式・披露宴を行った日
3.諸々の都合で式の後に新居に入居した日
Re: (スコア:0)
それは ChangeLog を書いた（後コミットした？）日時。
「release [excite.co.jp]」の意味から考えても、発表／公開した日時をリリース日時とするのが一般的では？
Re:クリスマスリリースではない (スコア:1)
Re: (スコア:0)
Re: (スコア:0)
Re:クリスマスリリースではない (スコア:1)
このリリースの位置付け (スコア:2, すばらしい洞察)
Re: (スコア:0)
Re:このリリースの位置付け (スコア:1)
僕もそう思っているのですが、それほど遠くない将来、不安は解消するかもしれません。
RubyConf 2007レポート [rubyist.net]のRubiniusのセクションにminispec.rbのことが書かれているのですが、これはRuby実装の挙動の正しさを確認するためのテストです。複数の実装のあることがこのようなテストの成熟を促し、いずれは「標準仕様」がフォーマルに定められるのではないか？という期待を抱かせます。Matz Rubyは後方互換性を重視してこなかったわけですが、今後は、バージョンによる差異が明確になり、「実装が仕様だ」という状態を脱するのではないか、と。
# Common Lispのようになるのが理想かな。まずコミュニティベースで仕様が定められ、それを複数のベンダが実装する、というね。
まずは (スコア:0)