#58
013_log.md
#58

Public 013_log.md

Updated at 2016-11-23 01:17

第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への移行が進んでいないのか？という話

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 US

Wycats' 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本家に取り込んでもらえないの？

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って誰がメンテしてるんだっけ？

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パッチについて

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パッチについて

これは当時はなんかダメだったらしい。

卜部さん: もう一回送ったらacceptされるかもしれないから、是非再チャレンジしてください。

これは、このパッチに限ったことではなくて、Rubyでは2度も3度もしつこく主張したら聞き入れられるというのはよくあることなので、一度rejectされたぐらいで諦めないでほしい、ということらしい。

(参考) CoW: (Copy-On-Write)

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パッチの中身について

ruby_engine

卜部さん: これは悪くないね。っていうかこれは入ったんじゃなかったっけ？ => なんだ、入ってるじゃん。

ということで、取り込み済み。

railsbench

GCのパッチ。Railsが速くなるらしいよ。ふーむ。

single_threading_fix

これはもう取り込み済み。

zero_copy_context_switch

これはシグナルの問題があるので微妙。このままではダメかも。

caller_for_all_threads

これは純粋な機能追加ですね。これは入ってもいいんじゃないかな。提案してください。

まとめ

MBARIパッチと言われるものの大半は実は既に取り込まれてたみたい。MBARIを適用するとパフォーマンスが上がるとかいうけど、見た感じパフォーマンスに影響してそうなのはGCのやつぐらいかと。

Rubyの非公式Githubミラーについて

ついにRubyがぎっはぶに！

http://github.com/shyouhei/ruby

まだ5人しかf**kしてない。~

卜部さん: 全員顔見知りじゃねぇかw

なるせRubyはかなり大幅に変更が入ってるらしい。

svnとの同期は卜部さんがたまに手作業で

Rubyにコミットするための道がもう一つできた

卜部さん: forkしてpull requestを送ってください。実はこっち経由のほうが受け入れられやすいかも？

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 :P

class_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がない件

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-spec

Ruby 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

savepoints

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?の挙動の違いについて

RailsのBTSで挙がったバグ報告。

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～

  • 0
  • 0
Imports/Qwik/010_log.md
Imports/Qwik/1.md

Comments0