> 第13回Asakusa.rb議事録第13回Asakusa.rb議事録
> 日時日時
2009/8/11(Tue) 19:30~22:00
> 場所場所
永和システムマネジメント 東京支社
http://www.esm.co.jp/company/map_tokyo.html
> 内容内容
Wycatsにチャットとかで訊かれたあれこれをそのまま卜部さんに訊いてみた。
> 参加者参加者
うらべさん
松田さん
かくたにさん
おぐらさん
かわぐちさん
志村さん
荻野さん
レオさん
郡司さん
> Ruby 1.9 vs REE(Ruby Enterprise Edition)Ruby 1.9 vs REE(Ruby Enterprise Edition)
海の向こうではなぜRuby 1.9への移行が進んでいないのか?という話
Wycats sais(抜粋)
こんなポストを書いてみたら反響がすごくて。
Yehuda Katz: and now they do not wish to switch to Ruby 1.9
Yehuda Katz: because they say "I need CoW from REE"
Yehuda Katz: http://yehudakatz.com/2009/07/17/what-do-we-need-to-get-on-ruby-1-9/
(以下、同ポストのコメント欄より抜粋)
"We are using REE on our production servers. When we will have stable REE 1.9 (or any other stable production ready Ruby implementation) then we will be happy to use Ruby 1.9."
"Sorry, I should look things up before I speak. Nope, ruby 1.9.1 is still not copy-on-write enabled, so it looks like there is still a reason to have a REE v1.9.1"
"As I’m using REE, I won’t upgrade until there’s a REE 1.9.x."ガイジンさんたちはREEがお好き
みんな1.9よりREEがいいらしい。
Yehuda Katz: many people responded about REE to my request :/
matsuda-akira: Hmm
matsuda-akira: seems strange to me
matsuda-akira: because REE is not so popular like that in Japan
Yehuda Katz: yes I know
Yehuda Katz: but very popular in the USWycats' worry
コミュニティが分断してしまうことが心配。
Yehuda Katz: I do not know what internal thinking in ruby-core is but I am worried about split community
Yehuda Katz: and people not using 1.9
Yehuda Katz: already people go to REE to put patches in they think ruby-core will not take
Yehuda Katz: so REE is putting in all patches that Matz says no to
Yehuda Katz: like the CoW patch
Yehuda Katz: and now the conclusion is that people wish to use REE instead of 1.9"we should find a way to make all happy"
名言ktkr。
Yehuda Katz: they said today they will make REE of 1.9
Yehuda Katz: but it still is silly... we should find a way to make all happy> REEで採用されてるパッチたちってなんでRuby本家に取り込んでもらえないの?REEで採用されてるパッチたちってなんでRuby本家に取り込んでもらえないの?
Yehuda Katz: I am speaking with Ruby Enterprise people... they wish to know what is reason not to merge each part -- so they can either fix or know why
> じゃあREEとやらをちょっと見てみようじゃあREEとやらをちょっと見てみよう
そもそもREEって誰がメンテしてるんだっけ?
PhusionのHongli Laiさんがメイン?
卜部さん: そういえばruby-coreでたまに見かける気がする。
ソースはGithubで公開されてるよ
http://www.rubyenterpriseedition.com/development.html
REEにはこんなパッチが入ってます
Overview of branches in the repository http://wiki.github.com/FooBarWidget/rubyenterpriseedition/overview-of-branches-in-the-repository
Yehuda Katz: I am speaking with Ruby Enterprise people... they wish to know what is reason not to merge each part -- so they can either fix or know why
matsuda-akira: what to merge, for example?
Yehuda Katz: the GC patch that lets you tune the GC sizes
Yehuda Katz: is the most obvious one
Yehuda Katz: there is also MBARI patches, which I think is on the way (I think I remember Matz saying this)
Yehuda Katz: and big one is optional CoW> GCパッチについてGCパッチについて
matsuda-akira: I once heard a committer metions to the GC patch that
matsuda-akira: it might be good for Rails but not for every Ruby program
Yehuda Katz: right... but if it is good for Rails, why we cannot make it optional?
=>
卜部さん: 「Rubyはオプションを好まない」ので、これは難しそう。
こんな話もあるらしいので、
Yehuda Katz: but for instance Twitter got a 40% improvement by using the GC tuning patch in REE
少なくともRailsユーザーにとってはこれを生かせる仕組みが何か入ってくれると嬉しいかも知れないですねぇ。
(参考) ruby gc tuning http://blog.evanweaver.com/articles/2009/04/09/ruby-gc-tuning/
> CoWパッチについてCoWパッチについて
これは当時はなんかダメだったらしい。
卜部さん: もう一回送ったらacceptされるかもしれないから、是非再チャレンジしてください。
これは、このパッチに限ったことではなくて、Rubyでは2度も3度もしつこく主張したら聞き入れられるというのはよくあることなので、一度rejectされたぐらいで諦めないでほしい、ということらしい。
(参考) CoW: (Copy-On-Write)
> MBARIパッチについてMBARIパッチについて
そもそもMBARIパッチってなんですか?
MBARIで作られたパッチ群のこと
MBARIってなんですか?
ググレカス
ぐぐったよ!
The Monterey Bay Aquarium Research Institute http://www.mbari.org/about/
こんなところでもRubyが使われているんですねぇ。
MBARIパッチってどうよ?
内容はこちらのリポジトリを参照。 http://github.com/brentr/matzruby/tree/masterパッチに関しては、とにかく巨大すぎるのが問題。MBARIパッチと呼ばれるものの中には、良い変更も悪い変更も混じっているのでそのままでは取り込めない。 一つ一つの内容は悪くないから個々のアトミックなパッチに分けて送ってくれ、ということ。
これは以前にも伝えているはずなんだけど、その後音沙汰がない(?)
中田さん: あれはパッチ提供のアンチパターンの典型の一つじゃなかろうか
> MBARIパッチの中身についてMBARIパッチの中身について
ruby_engine
卜部さん: これは悪くないね。っていうかこれは入ったんじゃなかったっけ? => なんだ、入ってるじゃん。
ということで、取り込み済み。
railsbench
GCのパッチ。Railsが速くなるらしいよ。ふーむ。
single_threading_fix
これはもう取り込み済み。
zero_copy_context_switch
これはシグナルの問題があるので微妙。このままではダメかも。
caller_for_all_threads
これは純粋な機能追加ですね。これは入ってもいいんじゃないかな。提案してください。
まとめ
MBARIパッチと言われるものの大半は実は既に取り込まれてたみたい。MBARIを適用するとパフォーマンスが上がるとかいうけど、見た感じパフォーマンスに影響してそうなのはGCのやつぐらいかと。
> Rubyの非公式GithubミラーについてRubyの非公式Githubミラーについて
ついにRubyがぎっはぶに!
http://github.com/shyouhei/ruby
まだ5人しかf**kしてない。~
卜部さん: 全員顔見知りじゃねぇかw
なるせRubyはかなり大幅に変更が入ってるらしい。
svnとの同期は卜部さんがたまに手作業で
Rubyにコミットするための道がもう一つできた
卜部さん: forkしてpull requestを送ってください。実はこっち経由のほうが受け入れられやすいかも?
> ActiveSupportからRuby本体に入れて欲しい機能についてActiveSupportからRuby本体に入れて欲しい機能について
Wycats氏から、ActiveSupportとかextlibからいろんな機能をどんどんRuby本体に取り込んでくれたりすると嬉しいんだけどなぁ、という話。
Yehuda Katz: but maybe we can collaborate around ActiveSupport
Yehuda Katz: maybe more parts of ActiveSupport can be part of core?
Yehuda Katz: or maybe some parts can be stdlib?
Yehuda Katz: A major goal for me is for ActiveSupport to be good Ruby library on its own
Yehuda Katz: maybe a supplement stdlib
Yehuda Katz: What I really want is just to make ActiveSupport a good Ruby extension library例えばどのへん?
Yehuda Katz: I wish class_inheritable_accessor in Ruby core
Yehuda Katz: or really extlib's version
Yehuda Katz: because semantics are so messy :Pclass_inheritable_accessorについて
- 実装
AS: http://github.com/rails/rails/blob/master/activesupport/lib/active_support/core_ext/class/attribute_accessors.rb
extlib: http://github.com/datamapper/extlib/blob/master/lib/extlib/class.rb
- 内容について > 卜部さん: 機能としては悪くないけど、リテラルが増える? @@@ とかにする?w #### Mashについて
MashとはRailsで言うところのHashWithIndifferentAccessのこと。
Yehuda Katz: I think it would be exciting to get Mash in Ruby core
- Rubyで書くとMashは遅い Yehuda Katz: it is very slow to do in pure ruby
Yehuda Katz: but Rails cannot have C extension
Yehuda Katz: if it was just in C it would be almost as fast as Hash
Yehuda Katz: because getting String from Symbol in C is very fast
卜部さん: そんなことはないと思う。Cで書いてもRuby版とほとんど変わんないんじゃないか?試しにやってみなよ。 #### Symbol#to_procの話
あれは卜部さんが中田さんを焚きつけてなんかRubyに入れちゃったけど、当時反対意見もあった。Symbolごときがメソッド呼び出しの意味を持つのはなんかおかしいので、どうせそれをやるならMethodを表すようなリテラルを新設すべきでは?という。実際、そっちのほうが正しいには違いないんだけど、色々考えるのが面倒なので結局ASのSymbol#to_procの仕様そのままのものを入れちゃって、今に至る。
> Ruby 1.9のspecがない件Ruby 1.9のspecがない件
1.9にはspecがないからみんな困ってるらしい。
Yehuda Katz: I have already started to discuss training people on 1.9
Yehuda Katz: there is very little demand though
Yehuda Katz: I have been somewhat worried about 1.9 for a while... it is important for us to have specs for what Ruby 1.9 is doing
Yehuda Katz: to be honest, that is biggest American grievance about 1.9
Yehuda Katz: we do not have specs for 1.9 so good
Yehuda Katz: so for instance it is hard for JRuby to implement
Yehuda Katz: and it is hard for Rails to know what we are supposed to do
Yehuda Katz: many in community here think ruby-core does not care about ruby-specRuby specってどうなってるんだっけ?
卜部さん: 昔Yuguiさんが頑張ってたけど最近はあんまり更新されてない気がする。でも今の状態でもかなりちゃんと動いてはいると思うよ。
ruby-core does not care about ruby-spec?
卜部さん: いや、もちろんそんなことは全然なくて、協力する気は大いにあります。(ただちょっとリソースが足りてないだけ)> 卜部さん: Rubyのtrunkでいきなり仕様が変わったりするのはたいがいMatzが何かでかいコミットをしたとき。でもtrunkはMatzの遊び場だから、trunkまでspecとかで縛っちゃうのはちょっとちがう気がする。Ruby 1.9.2については仕様もまだfixはしていない。
Rails 3はRuby 1.9.2で動作します!(という予定)
Yehuda Katz: and I have been working (with you!) to make sure Rails3 works on 1.9
Yehuda Katz: plus Rails 3 will probably target 1.9.2 :)
(参考) ruby192_on_rails
> savepointssavepoints
Railsのdevelopmentモードでファイルが書き換えられたらリロードするという機能を実現するために、現状ではめちゃめちゃ頑張ったhackをしている。言語の機能でこれをもうちょっと簡単に実現する方法があるといいんだけど、という話。
Yehuda Katz: I will think more on reloading... if there is way for Ruby to help it is better than massive hacks in ActiveSupport
Yehuda Katz: it is so when a user saves a file we can refresh with the new contents
Yehuda Katz: unoad and then reload
Yehuda Katz: but problem is in dependencies
Yehuda Katz: if foo_controller.rb requires other file
Yehuda Katz: right now Rails unloads everything, but there is no official support for this
Yehuda Katz: so we remove_const
Yehuda Katz: and also sometimes remove methods
Yehuda Katz: (to fix 1.8 memory leak)
Yehuda Katz: I wish to be able to say "from now on load classes into zone" and then just wipe zone
Yehuda Katz: or something like this
Yehuda Katz: that is too complicated probably
Yehuda Katz: each object would have to have zone
Yehuda Katz: it is not even zone really
Yehuda Katz: it is more savepoint
Yehuda Katz: it is to say "remove all objects created after savepoint"
Yehuda Katz: that is similar to what we do with fork"Python can do this natively"
Yehuda Katz: Python can do this natively
Yehuda Katz: (because of imports)
Yehuda Katz: python has reload(module)MLで提案してみた
http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-core/24520?24448-24832+split-mode-vertical
卜部さん: その件はMLの返信に書いたとおり。例えばソケットとかどうすんの?
「こまけぇこたぁいいんだよ!!」
Yehuda Katz: there is response on list
Yehuda Katz: Urabe says it is impossible ;)
Yehuda Katz: and I should get help from OS
Yehuda Katz: yes I know
Yehuda Katz: for instance, you will not be able to handle network sockets
Yehuda Katz: or global variables
Yehuda Katz: but that ok> 1.8と1.9のconst_defined?の挙動の違いについて1.8と1.9のconst_defined?の挙動の違いについて
RailsのBTSで挙がったバグ報告。
- LH#2975 https://rails.lighthouseapp.com/projects/8994/tickets/2975-inconsistence-constantize-behavior
- const_defined?の1.9との挙動の違いについて http://redmine.ruby-lang.org/issues/show/1915
const_defined?が第2引数を取れることが判明!
ていうかそれ全部るりまに書いてあったよ! http://doc.okkez.net/192/view/method/Module/i/const_defined=3f
スーパークラスや include したモジュールで定義された定数を検索対象にするかどうかは第二引数で制御することができます。
結論1
卜部さん: とにかく1.8か1.9のどっちかがなんかおかしいことは確か。
結論2
でもconst_defined?とか使わずにいきなりgetするのが正しい漢のプログラミングスタイル。
結論3
みんな、るりまをもっと読もう!
> その他雑談その他雑談
Lighthouseって使いにくくない?
-
- ログインしづらい
- 検索がしづらい
- プレビューがない
> 次回次回
2009/8/18(Tue) 19:30~