参加してました。コミッタ特権でタダ飯を食らえるのも残念ながら最後です。
今まではマジタダ飯にならないように何かしら発表することを心がけてたんですが、今回はネタ準備できず、ついに聞くだけ。"1.8 and 1.9" でちょびっとだけ壇上出たけど、その分弁当もらってしまったし。申し訳ない。なのでせめて見た発表ごとの一言感想を書きました。最後に。
そして Ruby とかなり関係ない Alloy 本は、ジュンク堂出張店で販売していただき、個人的な予想をはるかに上回る人数 (予想 1 桁、結果 2 桁) に汚い字でサインさせていただきました。ありがとうございます！おまえら買ったばかりの本を汚していいのか！ちなみにサインは実行可能な Quine になっています。typo してなければ
RubyKaigi 中のコミッタの行動にプライバシーはないと思うので、サインさしあげたコミッタだけ晒すと mrkn さん、nari さん、usa さん、matz (サインした順) 。追記: と、tal さん。最初にサインした人なのに書き漏らしたー さらに追記: と、nagachika さん。失礼しました……他に忘れてる人がいたらご連絡ください X-(
去年ぼくが壇上で「(コミッタに) 大切なのは継続力」とか口走ったのが何人かの方に影響していたようで、いや、申し訳ないですね。本人は燃え尽きたとか言われてますので。
燃え尽きたというか、1.9.3 はやらないと決めていたのです。おかげで 1.9.3 も順調にずれ込んでいるようだ、くくく。
あと、matz に Array#bsearch について直談判して、基本 accept の方針をいただきました。やったぞー。
詳細な API についてちょっと議論が続いているので、興味のある人は今のうちに議論に参加お願いします。具体的には shinh さんとか
発表については、「parse.y の歩き方」は面白かったですね。聞く前は「去年と同じっぽいから聞かなくていいかな」とか思ってたけど。着眼点が本当にすばらしい。尊敬に値する。asynchronously は、ひょっとしたら冗談抜きでこの API だけで erlang や go に勝てるんじゃないかとか思った。個人的にはコミッタに推薦してもいいレベル。というか言語デザイナーになったらよいのでは
最後に言ってた ennnnd は変態的ですばらしいと思ったのでとりあえず実装しておきました。反省はしていない。
$ cat t.rb
1.times do
1.times do
1.times do
puts "ok!"
ennnd
$ ./ruby t.rb
ok!diff --git a/parse.y b/parse.y
index aca2b6a..c17b095 100644
--- a/parse.y
+++ b/parse.y
@@ -70,6 +70,7 @@ enum lex_state_e {
EXPR_DOT, /* right after `.' or `::', no reserved words. */
EXPR_CLASS, /* immediate after `class', no here document. */
EXPR_VALUE, /* alike EXPR_BEG but label is disallowed. */
+ EXPR_ENNND,
EXPR_MAX_STATE
};
@@ -205,6 +206,7 @@ struct parser_params {
NODE *parser_lex_strterm;
enum lex_state_e parser_lex_state;
+ int parser_end_count;
stack_type parser_cond_stack;
stack_type parser_cmdarg_stack;
int parser_class_nest;
@@ -281,6 +283,7 @@ static int parser_yyerror(struct parser_params*, const char*);
#define lex_strterm (parser->parser_lex_strterm)
#define lex_state (parser->parser_lex_state)
+#define end_count (parser->parser_end_count)
#define cond_stack (parser->parser_cond_stack)
#define cmdarg_stack (parser->parser_cmdarg_stack)
#define class_nest (parser->parser_class_nest)
@@ -6632,6 +6635,11 @@ parser_yylex(struct parser_params *parser)
int fallthru = FALSE;
#endif
+ if (lex_state == EXPR_ENNND) {
+ if (end_count-- > 0) return keyword_end;
+ lex_state = EXPR_BEG;
+ }
+
if (lex_strterm) {
int token;
if (nd_type(lex_strterm) == NODE_HEREDOC) {
@@ -7874,6 +7882,21 @@ parser_yylex(struct parser_params *parser)
return kw->id[1];
}
}
+ else {
+ char *p = tok();
+ if (*p == 'e') {
+ int i = toklen() - 2;
+ p++;
+ for (; i > 0; i--) {
+ if (*p++ != 'n') break;
+ }
+ if (i == 0 && *p == 'd') {
+ lex_state = EXPR_ENNND;
+ end_count = toklen() - 3;
+ return keyword_end;
+ }
+ }
+ }
}
if (IS_BEG() ||追記: と思ったらすでに JRuby でも CRuby でも実装されてたわー。
以下は他の見た発表についてメモ程度ですが感想を。今までは自分が発表した後で感想を探して見るのが楽しかったので、みんな感想書いてあげるといいと思うよ。
1 日目
Next version of Ruby 1.8 and 1.9
なんか質疑で盛り上がってしまった private constant について 2 分くらい話しました。2.0 の話とかはグダグダ。仕込んどけよと思いますよね (ぉ
Ruby を利用した大規模ウェブサービスの開発・運用
Rails Rails した話もひとつくらい聞こうということで聞いてみた。でも正直よくわからず。Rails まわりは毎年ツール名とかキーワードが変わっていくので大変ですね。
Ruby 用のリアルタイムプロファイラ
笹田研研究発表とかでちょくちょく話を聞いていた内容ですが、聞くたびにツールとしての完成度が上がっているのですごいですね。
組込みシステムのための動的コンポーネント機構とVMの最適化
今回は「よく実装したなあ」とコミッタたちも感心するレベルの Ruby 改造発表が多かったのですが、その 1 つ目。省メモリ化などのために send 命令の圧縮とかしたって。すごい。
でも、こういう改造がわりと誰でも (といったら失礼だけど) できるようになったのは、YARV によって Ruby 実装が近代的に整理されたおかげなんでしょうねえ。
CRubyGC の並列世界
「よく実装したなあ」2 件目。nari さんなのでいまさら感心しないけど (ぉ
闇 RubyKaigi
闇なのであえて書かない。VDD!
2 日目
安全なプログラムの作り方
起きたら 10:15 ……！ ust で終わりの方だけ見た。すみません
コンソールに生 String を出力するだけで security issue になるのは、$SAFE とかで対策してあげるべき話だったりしないかなあ。
Drip: Persistent tuple space and stream.
咳さんとかまさに継続力ですよね。すごい
Writing Friendly Libraries
英語だから不真面目に聞いてたらほとんどわかってない……あとでちゃんとみる
ThreadGroup クラスの強化とその利用法
「よく実装したなあ」3 件目。ThreadGroup とか言いながら classbox/refinement/method shelter に並ぶ新しいモジュール化機構が提案されている不思議。
事前にメーリングリストに投げられた提案 (リンク先化けてる) が大長編すぎた話題作ですが、提案の分割と、ユースケース説明の追加で通るものも (通らないものも) ありそうですね、という話をした。
JIS X 3017の読み方
噂の JIS 化の話。まだちゃんと読み通したことがない。コミッタが砕け散ったというクイズに参加したかった。
感想が手抜きになってきた……
この辺で (nari さんにサインするために (嘘)) 会場に向かう。
Method Shelters : Classboxes でも Refinements でもない別のやり方
「よく実装したなあ」4 件目。
個人的にはいいと思ったんだけど、matz はじめ反対派多数の様子。慣れな気もするんだけどなあ。
まあ、唯一わかりやすユースケースの mathn で使えるのかよくわかんなかったし、他のユースケース不在で議論しても不毛だけど。
この問題だけに 3 つも 4 つも提案手法が出てきてるので、ここらでケーススタディ発表が欲しい。
CRubyのロックデザインの解説および改善案について
去年の末頃にささださん、小崎さん、tal さん、ぼくで突発的に盛り上がっていた話題の集大成。
と言ってもぼくは Python の GIL の機構を調べただけで (それもこれとかこれとかプレゼン資料読んだだけ) 、あとの高度な議論からはわりとドロップアウトしたので、他の 3 人ががんばっていたのを茶化したり応援したりしていた。こういうシステムプログラミングできるひとたちはすごいよね。
LT
nagachika さんのトラチャン (ruby trunk changes) 統計版が期待通り面白かった。書くのに疲れてきたので他の感想は勘弁ください。
懇親会
4 年くらい行ってたのでぼちぼち知り合いもできていた、というところで RubyKaigi 終了だよ！
でも、コミッタでも油断するとすぐぼっちになるので、ぼっち対策としてコミッタになることはおすすめしません。
3 日目
テスティングフレームワークの作り方
ちょっとだけ cutter 使ったことあるよ！
あとみんな Rabbit 使うといいと思うよ (須藤さんにショッカー人形もらったので棒読み)
分散オブジェクト環境DeepConnectの新バージョンについて
ちょっとだけ fairy 使ったことあるよ！ ドキュメントの typo を指摘しまくるとか嫌なことしたことも
O/R Mapper を支える技術
クエリをオブジェクトで表現するといいことあるよ、という内容。理解し間違えてなければ。
ぼくも Sequel 使ったときに同じようにいいなーと思った気がするけど、SQL も他の O/R マッパも知らないのでためになった
ところで NoSQL がもっと広まったら、SQL ベースじゃない O/R マッパが必要になるのかなあ。
LT
前日より技術よりな内容が多かった気がする。いくつかだけ
