Public 013_log.md

## 第13回Asakusa.rb議事録

### 日時

2009/8/11(Tue) 19:30～22:00

### 場所

永和システムマネジメント 東京支社  
[http://www.esm.co.jp/company/map\_tokyo.html](http://www.esm.co.jp/company/map_tokyo.html)

### 内容

Wycatsにチャットとかで訊かれたあれこれをそのまま卜部さんに訊いてみた。

### 参加者

うらべさん  
松田さん  
かくたにさん  
おぐらさん  
かわぐちさん  
志村さん  
荻野さん  
レオさん  
郡司さん

### Ruby 1.9 vs REE([Ruby Enterprise Edition](http://www.rubyenterpriseedition.com/))

海の向こうではなぜ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/](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さん](http://izumi.plan99.net/blog/)がメイン？

> 卜部さん: そういえばruby-coreでたまに見かける気がする。
#### ソースはGithubで公開されてるよ

[http://www.rubyenterpriseedition.com/development.html](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](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/](http://blog.evanweaver.com/articles/2009/04/09/ruby-gc-tuning/)

### CoWパッチについて

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

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

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

(参考) CoW: ([Copy-On-Write](http://ja.wikipedia.org/wiki/%E3%82%B3%E3%83%94%E3%83%BC%E3%82%AA%E3%83%B3%E3%83%A9%E3%82%A4%E3%83%88))

### MBARIパッチについて

#### そもそもMBARIパッチってなんですか？

MBARIで作られたパッチ群のこと

#### MBARIってなんですか？

ググレカス

#### ぐぐったよ！

The Monterey Bay Aquarium Research Institute [http://www.mbari.org/about/](http://www.mbari.org/about/)  
こんなところでもRubyが使われているんですねぇ。

#### MBARIパッチってどうよ？

内容はこちらのリポジトリを参照。 [http://github.com/brentr/matzruby/tree/master](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](http://github.com/shyouhei/ruby)

#### まだ5人しかf\*\*kしてない。~
> 卜部さん: 全員顔見知りじゃねぇかw

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

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

#### Rubyにコミットするための道がもう一つできた
> 卜部さん: forkしてpull requestを送ってください。実はこっち経由のほうが受け入れられやすいかも？
### ActiveSupportからRuby本体に入れて欲しい機能について

Wycats氏から、ActiveSupportとか[extlib](http://wota.jp/ac/?date=20081202#p01)からいろんな機能をどんどん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](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](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](ruby192_on_rails.html)

### 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](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で挙がったバグ報告。

- LH#2975 [https://rails.lighthouseapp.com/projects/8994/tickets/2975-inconsistence-constantize-behavior](https://rails.lighthouseapp.com/projects/8994/tickets/2975-inconsistence-constantize-behavior)
- const\_defined?の1.9との挙動の違いについて [http://redmine.ruby-lang.org/issues/show/1915](http://redmine.ruby-lang.org/issues/show/1915)

#### const\_defined?が第2引数を取れることが判明！

ていうかそれ全部るりまに書いてあったよ！ [http://doc.okkez.net/192/view/method/Module/i/const\_defined=3f](http://doc.okkez.net/192/view/method/Module/i/const_defined=3f)

> スーパークラスや include したモジュールで定義された定数を検索対象にするかどうかは第二引数で制御することができます。
#### 結論1
> 卜部さん: とにかく1.8か1.9のどっちかがなんかおかしいことは確か。
#### 結論2

でもconst\_defined?とか使わずにいきなりgetするのが正しい漢のプログラミングスタイル。

#### 結論3

みんな、[るりま](http://doc.loveruby.net/wiki/)をもっと読もう！

### その他雑談

#### Lighthouseって使いにくくない？

- [http://lighthouseapp.com/](http://lighthouseapp.com/)

  - ログインしづらい
  - 検索がしづらい
  - プレビューがない

### 次回

2009/8/18(Tue) 19:30～