ワナビーとたわごと

絶対忘れるのでメモ。というかさっきまで忘れてました。たとえばこんなケース。

def foo
bar {|o| return o }
end

この return が実行されるとき、FINISHとかTOPとかを除くと、フレームは

ブロックのフレーム　の上に　barのフレーム　の上に　fooのフレーム

となっているわけです。で、この return は bar からの return ではなく foo からの return として処理しなければなりません。とすると、フレームをたどるときに return の対象ではない bar は無視しなければなりません。

この判定に、現在の trunk ではスコープを用います。つまり、return が実行されたフレームと同一スコープのメソッドフレームを検索し、これに対して return 処理をします。うまくできてますね。

うまくできているのですが、この実装のために、題のチケットに行き着くわけです。クラス宣言が始まった時点でスコープが変わってしまうので、ここで return すると対象のメソッドフレームが見つからなくなってしまいます。そこで現在はコンパイル時点でこれは禁止されています。

んじゃあスコープ以外で判定するか、というとこれも中々で。別の場所で作られたProcオブジェクトをブロックとして渡されて、しかもその中に return が入ってたらどうするか、なんて面倒な問題にもなるわけで、結局スコープで処理するのが一番確実かつ楽だと思うわけです。さてどうしよう。

def bar
yield
end
def foo(&b)
bar {class <<self;return ;end} if b == nil
bar(&b)
return 2
end
p foo
p foo{return :ng}

こんなんなるともう、何がなにやら。

だそうです。おおー素晴らしい。

Bug #1376を手元で修正してて、「そうならいいのになー」と思っていた矢先だったのでこれは嬉しいです。正直、このチケットをささださんが解決してくださる→私がパッチ書いたりあまつさえコミットする必要は全くなくなる、ということが大変喜ばしい。

ちなみに手元では、rb_method_entry で持ってきて body.cfunc.func がrb_equal ではないなら、って感じのものすごい力技をopt_case_dispatchに組み込んでいました。optの意味ないくらい遅くなるよなーどうすっかーと思っていたので、非常に助かりました。

module Foo
def foo(*a)
end
end
module Bar
include Foo
private :foo
alias bar foo
puts “Foo:%x Bar:%x” % [Foo.object_id * 2, Bar.object_id * 2]
p private_instance_methods, instance_method(:bar)
module_function :foo
p “—”
module_function :bar
end

デバックプリントつき。

いや本当は@WORDよくない、と断言したいんだけど、そう思うのは自分だけかもしれないんで少し弱めの表現にしてます。

WYSIWYGが当初思ったより使いづらい。コメントスパム弾きが面倒（なんか登録してWordpress APIのキーを入手しろとか）。

何より致命的なのが、コード、というか<や>を含む文章を貼り付けるのが面倒。

せっかく見てくれる人が増えたところで、 なんとも残念です。さて我慢して使うか、引っ越すか、どうしますかね。

Bug #696（フラクタルベンチ）に関連して。

#!/usr/local/bin/ruby
require 'benchmark'
n = 10_000_000
Benchmark.bm do |bm|
bm.report do
i=-1;while((i+=1)<n);end
end
bm.report do
i=-1;while((i+=1)<n);false;end
end
bm.report do
i=-1;while((i+=1)<n);while(false);end;end
end
end

の結果。

ruby 1.9.0 (2007-12-25 revision 14709) [i386-mingw32]
user     system      total        real
0.750000   0.000000   0.750000 (  0.812000)
0.735000   0.000000   0.735000 (  0.735000)
0.859000   0.000000   0.859000 (  0.859000)

ruby 1.9.2dev (2009-07-03) [i386-mingw32]
user     system      total        real
1.250000   0.000000   1.250000 (  1.250000)
1.594000   0.000000   1.594000 (  1.593750)
1.687000   0.000000   1.687000 (  1.703125)

ほう。以前が速すぎな気もしますが、中々興味深い。

おまけ。disasm結果。

(more…)

最近ブログが続いている。いいことです。チケット追っかけもまとめたし。

これはたぶん、というかほぼ確実に、rubykaigi効果でしょう。お酒に酔った勢いでいろんな人に話しかけたよーということを以前書きましたが、なんだか今はkaigiの雰囲気に酔ってるようで、いまだに変な高揚感があります。これがいつ切れるのか私には見当がつきません。いかにも自己啓発セミナーとかに引っかかりそうな安っぽい精神構造だなーと自分に苦笑しながら、せめてあと数ヶ月くらいは続いて欲しいな、と。

今のうちに、切れたあとの対応策を考えておかねば。

Yugui さんからコメントいただきました、ありがとうございます。IRC、挑戦してみます。

強制されたり勧誘されたりするまでもなく、とりあえず仕組みがあるんだから使っとけ、と言う意見もあるかとは思います。ごもっともです。ただ、よくわからないものに対する恐怖感が強いんですね。使ったことない知らないライブラリとかは喜んで読むのにね。

以下言い訳兼軽いトラウマ話。ずうっと以前、ネットゲームと言うものをやってみようとしたことがありまして。確かサッカーか何かのゲームだったと記憶しています。だだっ広い練習場でドリブルか何かの操作練習をしていたところ、なんか近づいてくるキャラクターがいたんです。で、そのキャラがチャットしてきて、ああこれは誰かプレイヤーなのだ、返事せねば、と思ったのですがチャットの方法がわからない。どうしようもなくなってその場を離れたことがあって、なんとも申し訳ない気持ちになったことを今でもよく覚えています。今にして思えば、操作説明ページを開きなおして落ち着いてチャット方法を探せばそれで良いのですが、すぐ返事しなければとテンパッてしまいまして。それ以来、リアルタイムでのオンライン系統のものに苦手意識を持ち続けることになったと、まあそういうわけで、長い長い言い訳終了です。

その辺がtwitterやなんかも使ってみたいのに踏み切れない原因かも、と自己分析しています。 頭の回転が遅い奴はこういうのだめなんじゃないかと言う思いもあって、ずるずるとそのままです。

そうそう、言い訳その２。そもそもなんで前段の疑問にたどり着いたかと言うことなんですが、あれですよ某匿名巨大掲示板。何しろ巨大だから Ruby に関する話題も取り扱っていて、私も見ている訳なんですが、そちらでの発言でこんなものを見つけたのが発端でした。以下、斜体文は引用です。

ざっとIRCでアンケートを取ったところ(IRCにいるということは現在アクティブであると推察される)、

ん？ということは、もしかして IRC にいない私は非アクティブということになるのかも？と。まあ確かにアクティビティは低いですが、まだまだ Ruby に関わっていたい気持ちはあるので、非アクティブといわれるのはちときつい。そういうことであれば、これはもう苦手だとか言ってる場合ではなかろうな、いやでもな、という葛藤の末の記事でした。

とまあグダグダと言い訳を続けてみたわけですが、既に結論として出ている通り、 IRC、挑戦してみます。大事なことなので二回言いました。他人から見ると馬鹿馬鹿しいでしょうが、私にとってはかなり、そうとう、大きな一歩なんですこれ。

コントリビュータはぜひ入っとくべきとか半強制とかそういうものなんでしょうか？クライアントの使い方がわからなくて、いったん入室したものの「あれーどうすんだー」とかいって切断したことが２，３度ありましたが、それ以降やってないです。

というか、ログが残らない場所で発言すると自分で何言ったかわからなくなっちゃって怖いです。 メールですらよく忘れるのに。それも含めて、MLと対比してのメリットがわからない。
普段はこのブログを誰も見てないことに安心感を覚えてましたが、こういう疑問が出たときはツッコミがたくさん来るブログやtwitterやってる人たちがうらやましい。かといってこんなバカな質問を誰かに投げるわけにもいかない。うがー。まあいいやとりあえず現状維持、ですか。

最近ずっとrubyの話。これでいいのかゲームはどうした。

何か手に負えそうなものはないかとチケットを漁っていると、Bug #1325 にfiber tests kill windows なるチケットを発見。簡単に訳すと「Windows で test-all すると test_fiber.rb でメモリ食いでスワップしまくって落ちるよ、単体起動だと落ちないよ、fiberの数を制限すれば落ちないけど根本の解決ではないよ」ということのようです。

うげ、以前fiber関連のパッチ送ったときにSEGVするからやっぱり取り下げますといったことがあったんですが、これが原因か。しかしこれをどうにかせんとテストが出来ず、テストできなければパッチにバグがある可能性は捨てきれない。

Array.new(1024*1024*200)とかしてメモリを圧迫してテストしてみたんですが再現せず。今のところtest-allでしかSEGVしてくれません。test-allなら高確率で落ちるようなので、何度も回しまくってデバッグするしかないんでしょうか。時間かかるなー勘弁してください。何とかうまい再現方法はないものか。

なんで起動オプションでGCアルゴリズムを変えるのが難しいかをもう少し詳しく。

Rubyには多くのコマンドラインオプションがあります。例えばセーフレベルを指定するものとかだと、rb_argvなんかのオブジェクトを汚染させたりするわけで、当然この処理の前にオブジェクトは作成されているわけで。そこでとるべき道は２つ。

1. GC変更オプションは、他のオプションよりも前に書かなければいけないものと規定する（それ以外の場所にかかれたときはエラーか無視）。たとえば -e オプションなどは、その意味から明らかですが一番最後でなければだめです。
2. まずGC変更オプションの処理だけを行い、その後でそれ以外のオプションを処理する。全オプションの引数の個数を知っていて、それらをスキップしなければなりません。また新しいオプションを作ったときにも２重に変更が必要になります。

とりあえず２．は全くだめ。２重管理なんて良いところ無しです。１．はまだ良い気がしますが、それでも使い勝手があまりよくないし、それになんだか気持ち悪い。

それで昼間思いついたんですが、もしかして環境変数を起動時に見るのならいけるんじゃないかと言う気がしています。RUBY_GC=”lazysweep” ruby -e ‘p 1′ みたいな感じで。もし上手くいったら久々にパッチ送りつけてみようかな。

以前Rubyのブロックという記事で、ブロックが遅くてどうにかならんもんかと書いたのですが、実はwhileを使うと速いみたいです。

$ ruby -rbenchmark -ve ‘
n = 5_000_000
Benchmark.bm(5) do |bm|
bm.report(”for”) {
for i in 0..n
end
}
bm.report(”each”) {
(0..n).each do end
}
bm.report(”times”) {
n.times do |i| end
}
bm.report(”while”) {
i = 0
begin end while (i += 1) < n
}
end
'
ruby 1.9.2dev (2009-07-03) [i386-mingw32]
user???? system????? total??????? real
for??? 1.531000?? 0.000000?? 1.531000 (? 1.593750)
each?? 1.516000?? 0.000000?? 1.516000 (? 1.578125)
times? 1.421000?? 0.000000?? 1.421000 (? 1.515625)
while? 0.594000?? 0.000000?? 0.594000 (? 0.625000)

すごーい。小手先でブロック使いまわして高速化するパッチとか、もうなにそれバカみたいって感じです。全然必要ないです。もしかしたら最近入ったローカル変数のキャッシュというのも効いているのかも。

ずうっと以前、allegroというゲーム用ライブラリのRubyバインディングに挑戦したのですが（放置中）、画面に1ドットずつ炎をレンダリングしていくサンプルで泣きたくなる速度しか出なかったのを思い出しました。このwhileの処理速度なら、今のtrunkなら満足いくコマ数が出せるかもしれませんな。すばらしい。

RubyのGCアルゴリズムを自由に変えられないか、ちょっと考えてみました。

メモリの解放を考えるときは当然メモリの確保も考えないといけないわけで、 Rubyが（GC対象にする）最初のメモリを確保するその前に、GCアルゴリズムを確定しなければならず、またそれ以後で変わることもあってはならないというのが大前提です。

であるので、とりあえずプログラム中でrequire ‘boehm-gc’みたいにするのは却下。-rで読み込むのも却下。 1.9には各種preludeがありますので、オブジェクトがすぐに生成されます。そもそもKernelやObjectですらGC対象であるので、Init_Objectが呼ばれるより前に確定しなければならないわけです。よってコマンドラインオプションを新規に作るぐらいしかなさそう。しかし！

rubyのメイン関数は ruby_init -> ruby_options の順番に進むため、ここにまで手を加えなければなりません。そこまでして、オプションも作って、という非常に大掛かりな変更になります（GCを変更するのだから当たり前と言えば当たり前ですが）。

得られるリターンに対してちょっとリスクが大きすぎるかもしれません。それならパッチを当ててrubyをコンパイルし直す現状の方がいいのかな、と。

GCを開発する人の立場を考えると、たとえばgemでgcを出しておけば多くの人に試してもらってバグが取れてハッピー、とかあるかもしれないけど。そこまでGCで極端な差が出ることは小さなプログラムではまずないし、大きな、しかも長時間動かすプログラムを作る人の場合、rubyの最コンパイルぐらいはそれほどの手間ではないでしょう。

ということで、GCの動的差し替えは「できるかもしれないけど（多くの人にとって）リスク > リターン」ではないかという結論になってしまいました。やっぱ思いつきはだめだね。どうにもすみません。

まさか自分がここまで酒に弱くなってるとは思いませんでした。Beer bustではビール2缶とウイスキーほんのちょっとしか飲んでないのにすげーふらふら。

で、酔った勢いで有名どころの方々に突撃。ささださんにはvm(_core).hがインストールされないとruby_debug移植なんて無理っすよーとか言った気がする。（なんという態度。ごめんなさい。）これについては何かしらのAPIが用意されるということのよう。楽しみです。

あと念願の「前田さんに謝る」を実行してきました。本当にご迷惑おかけして申し訳ありませんでした。nariさんにはGCアルゴリズムを動的に変えれないっすかねーとか無責任発言をした気がする。酔いが醒めて考えると、これはちょっと難しいでしょうね。

久々に昔の学校の先輩にご挨拶をしたり、充実した日でした。あとはテク妍の星一さんにフリゲ好き、ツクール好きとして話しかければ完璧だったのに…ううむ。あ、普通はstar rubyの、ですか。いいんです私にとって星さんはうえのさんなんです。

さて今会議、ここまででは継続と変化という2つのキーワードが多く取り上げられた気がします。バグ取りも何もかも継続できていない、どうしようもない自分を変化させなければ。とりあえず帰ったらチケットを古いほうから洗ってみるとします。あーあとruby_debugももうちょっと追いかけてみたい。

＜追記・編集等＞

（追記）

Rubykaigi参加に当たって、自分のTシャツが少ないのでの会場で買おうと思っていました。ノベルティとしては定番なのでまさかないはずはなかろうと。

そしたらコミッタとスピーカ対象の無料配布だけなんだとのこと。うむう。

正直名乗りたくないわけです。だって、ねえ？コミッタってほどコミッタじゃないですもん申し訳なくて。だから一般参加したのに。でも実物見るとTシャツ欲しーい！

まあ仕方ない。名札（自分で好きに書いて首から書ける方式です）に書いた本名の下に、「（ワナベ）」って書いて名乗り出てみました。

当ったり前なんだけど、受付さん戸惑う戸惑う。そりゃワナベなぞよっぽどruby-devを熟読してる人ぐらいしか知らんわ。さらになんかコミッタは名札の色から違っててそれで判断するみたいです。うおお危ない！よかった一般参加で本当によかった！さらに「関係者席」と書かれた紙を見て「もしコミッタ枠で参加してたらここに座ってたかも」と思うと、よかった一般参加で本当によかった！

んで「明日コミッタ用の名札に替えてもらって云々」という話をされたのだが冗談ではないですよ。そんな、名札に「ワナベ」と書くのさえ躊躇したのに（これは「こんな名前誰も知らないし」という当然の結論を得て問題なしと判断）そんな。んじゃいいですと言ったんだけど、「数に余裕あるしいいから」と言って下さったボランティアスタッフの方どうもありがとうございました。

いいですと言っておきながら、そこから立ち去らずにしばらく話していたことを考えると、テンパりながらもどうやってTシャツをもらうかの算段をしていたのかもしれないと、そんな無意識の判断に反吐が出る。まったく申し訳ない。しかし物（Tシャツ）はもらう。