面倒なバグが発見される。Procの中からbreakやreturnが実行されたとき、 ジャンプ先が存在しないケースがあるので、その場合にはLocalJumpError例外が発生する。 その例外の発生条件がbreakとreturnで異なっていることに気がついていなかった。
つまり、
def foo1
Proc.new{break}.call
end
def foo2
Proc.new{return}.call
end
とあるとき、foo1の方はbreakのジャンプ先であるProc.newの呼び出しが完全に終了しているため、 飛び先が存在しないのでLocalJumpErrorが発生する。しかし、foo2の方はreturnの飛び先である foo2(の終端)がまだ存在しているため、そのままreturnすれば良い。
で、長い時間かかってなんとなくうまく動いているところまで持っていったのだが、 まだよくわからないコードが残っている。リファクタリングしないとな。
東京に移動。内容を具体的に書くのはまずいような気がするので、 印象とキーワードだけ。必要に応じて妄想してください。
結局事務局の努力により、無難な線にまとまりそう。
プログラミングコンテスト、プロコン、検索にかからない、 自前サイトの必要性、 プレゼンスの改善、インセンティブ、結果のフィードバック、 ノウハウの蓄積ができるように、 プログラム実行を作品として見るか、ソースコードそのものを見るか、 ソースコードレビュー、公開するかどうか、 一点突破主義を認めたい、自己申告制。
セキュリティキャンプ、セキュリティ甲子園への道、 合宿、講義、雑談、学習、次年度のチューター。
先日、オープンソースカンパニーであるという、 株式会社ユヒーロについてとりあげたら、 ユヒーロ代表であられる伊藤寛之氏が、わざわざブログを始めてまで反応してくださった。
自ら「ユヒーロがオープンソースカンパニーを名乗る資格を有しているかと考えると、私自身も個人的には“NO”である」と認めつつも、「思いつきであるにせよオープンソースカンパニーを名乗ることの本当の気持ちを考えてみると、今まで、そしてこれからもお世話になるであろうオープンソースソフトウェアに少なからず貢献したいという思いがあったことも事実」であり、また、
ユヒーロが真のオープンソースカンパニーを目指すにあたって以下のことを目指していく必要がある。
- オープンソースソフトウェアを利用する人たちが少しでも増えるように努力すること。
- オープンソースを利用する人たちがより快適に利用できるようにサポートしていくこと。
- 自社のソフトウェア「HiTo!」を将来的には、オープンソースとすること。
後日、オープンソースと人について改めて考えてみたい。
と非常に前向きに考えておられる。念のため書き添えておくが、 私はオープンソースをただ利用するだけの企業を軽蔑したりはしない。 が、オープンソースに積極的に貢献しようという気持ちのある人や企業には賞賛を惜しまない。
Welcome to the Open Source World.
Matzにっきは、オープンソースカンパニーとしてさらなるステップを踏みだそうとしている株式会社ユヒーロを引き続き応援します。
オープンソースは(隠されているところがないので)教材としてふさわしいものが多いし、 オープンソースに理解のある優秀な人材を輩出してくれれば、 業界全体がよくなるかもしれない。
こちらも暖かく見守りたい。
今日はニュースが多い。
この文面を読む限りでは最悪の展開になったということかしら。
ヨーロッパはソフトウェア特許に関して一進一退を繰り返しつつも、 悪くない動きを見せていたのに、ここで一転、大企業に有利な決定がされたということは、 世界がより住みにくい世界になったということを意味しているような気がする。
将来、引退したらヨーロッパにでも住もうと漠然と思ってたんだけど、 あんまり良くないかなあ。どこかの国が(tax heavenならぬ)patent heavenとか宣言して、 自国内では外国の特許は無効(もちろんWTOにも加盟しない)とかいう動きを見せたら、 ...一発で外交圧力でつぶされそうだな。
日本にも夏時間(DST)を、という話。反対。
Rubyが海外にも使われるようになった2000年頃からしばらく、 毎年春と秋になるとアメリカやヨーロッパから時刻に関するバグレポートがやってきた。 夏/冬時間の切り替わりで一定期間だけずれが生じるというものだ。 で、これがまた面倒なバグでねえ。 あるケース(たとえばアメリカ)で直ったかと思うと、ヨーロッパではうまくいかなかったり。 夏時間のない日本に住んでて今まで本当にしあわせだったと痛感したものだ。
省エネや活動時間の調整は各自で行いましょう。 もう大人なんだから。
検索エンジンを開発している後輩(部下)たちには参考になるかも。 ....ならないかも。
AJAXフレームワークを使ったWebサイト開発を支援するツールキット。 現在はPHPのみをサポートしているが、ASP, Perl, Python, Rubyにも移植したいとのこと。
ちょっと見た感じでは、AJAXプログラミングがちょっとラクになるかな、という気はした。 150行弱のPHPコードでここまでできたら上出来か。
もうちょっと洗練する余地はありそうな気もする。
というものを、OOPSLA 2005と併催するからProgram Committeeとして参加してくれないか、 というメールが来る。名誉なことだから受けたいのだが、 参加できるかもわからないしなあ。ちょっと迷いが。
子供たちが通っているスイミングスクールがある海洋センターが、 小さなお祭りをするということで、遊びに行く。 が、この日は妙に寒くて、雪は降るし、出店とかも中止になったものが多かった。 息子はスーパーボールすくいを本当に楽しみにしていたので、かなりがっかり。 唯一やっていた射的も6発もらってひとつも当たらなかった(最後の一発は私が撃ったのに当たらなかった)ので、 ますますがっかり。相当落ち込んでいた。
とはいうものの、隣のいろり茶屋で食べたお蕎麦はおいしかった。
その他、買い物をいくつか。
子供たちを起こして準備させ、いつもよりほんの少しだけ早い時間に教会に出発する。
しかし、途中で私がネクタイをしめていないことに気づく。 どたばたしていたのでしめわすれたのだろう。 さすがにスーツにノーネクタイではかっこうがつかない。 すごすごと引き返す。 結局、普段よりも遅くなった。がっかり。
断食証会。
集会終了後、ふたりほど面接。うちに帰る。
明日、プレゼンテーションがあるのでそのスライドを準備していたら MagicPointがsegmentation fault。 新しいバージョン(1.12a)をダウンロードしてコンパイルしてみたが やっぱりダメだった。
mgp2psは動くので、明日はとりあえずPDFファイルを作って プレゼンすることにした。
デバッガで実行するとdraw.cのobj_draw()関数で XCreateImage()がNULLを返しているのに、 その内部にアクセスしようとしているから、らしい。
if (obj != NULL) { /* VFONT exist */
xim = XCreateImage(display, visual, depth, ZPixmap,
0, NULL, width, height,
8 << (depth - 1) / 8, 0);
xim->data = malloc(xim->bytes_per_line * height);
が、追求はここまで。なぜNULLを返すのかわからない。 今まで動いていたスライドでもダメだから、 問題があるのはスライドではなく、おそらくXの設定なんだろうけど。
なにがいけないんだろう。
追記
唯一心当たりのある設定変更であった、/etc/X11/xorg.confの
Section "Extensions"
Option "Composite" "true"
EndSection
の部分をコメントアウトしたら、ちゃんと動くようになった。 どこがどういう関連を持って動かなかったのかまったく想像もつかないけど。 分かる人が見たら分かるのかなあ。
NetBeansがRubyをサポートした、という話。 Sunは本気っぽい。
Rubyが解説されている。しかも、マンガですよ、マンガ。
正直、よくわからないオチであったが、 それは置いておくことにしよう。
ずーっと昔、私は日本オラクルの面接を受けたことがあって*1、アレンとはその時にあったことがある。 ほとんどは仕事の話で、教会の話をひとことふたこと話したような気がする。 あんまり昔なんではっきり覚えてないけど。
*1 で、転職してたら人生変わってたろうなあ
今年もGoogle Summer of Codeがやってきた。 例年RubyCentralが参加しているのだが、 今年はそれに便乗するか、RubyAssociationとしてか、 メンターとして参加しようかなあ。
本当はRuby専門でRubyAssociationが主催すべきなのかもしれないけれど。
で、いずれにしてもどんなテーマが考えられるかなあ。
James Goslingが「Emacsは使うな」と言った、という話。
いや、私だって設計が古いEmacsを使い続けたいわけではない。 けれども、世の中にEmacsを置き換えるに足るツールが他に存在しないんだからしょうがない。 今まで使ってない機能が満載のEclipseを紹介してくれても 私にはうれしくない。
とりあえず、「今使ってる機能」を提供してくれる編集環境がほしいだけなんだが。 Emacsのフル機能を使ってるわけじゃないから、
くらいあれば。
今まで使ってない機能としては
とかあれば良いけど、なくても我慢できる。
Railsは(人々の注意をPythonに向けるという意味で)Pythonにとってもっとも良いものとなりえる、 という話。
私としてはRubyが他の言語(LispとかSmalltalkとかPythonとか)の 呼び水になったとしてもそれはそれでよいと思っているのだが、 Railsの連中はどうなのかな。
まあ、それでも他の言語に逃げなくても済むように いろいろな機能を提供し続けることは止めたりはしないけど。
いつか追い越せ、他言語。
RubyQuiz #157の結果から、 JRubyにおけるStructのアクセスがMRIより遅い、 というが正式にバグ認定されたという話。
まあ、勇気ある判断である。
ところで、このRubyQuiz #157ベンチマークであるが、 CRubyで試してみたところ、以下のようになった
matz@x61[ruby] ruby -I lib /tmp/157_benchmark.rb
user system total real
FRANK 24.060000 4.090000 28.150000 ( 28.630580)
JUSTIN 5.560000 0.410000 5.970000 ( 6.440966)
LIONEL 0.460000 0.050000 0.510000 ( 0.525290)
DOUG 2.970000 0.420000 3.390000 ( 3.515856)
PHILIPP 1.330000 0.070000 1.400000 ( 1.476920)
BILL 0.360000 0.030000 0.390000 ( 0.397130)
matz@x61[ruby] ruby1.9 -I lib /tmp/157_benchmark.rb
user system total real
FRANK 7.800000 0.020000 7.820000 ( 7.931905)
JUSTIN 3.500000 0.020000 3.520000 ( 3.527578)
LIONEL 0.220000 0.000000 0.220000 ( 0.218631)
DOUG 1.730000 0.010000 1.740000 ( 1.764487)
PHILIPP 0.800000 0.000000 0.800000 ( 0.800930)
BILL 0.180000 0.000000 0.180000 ( 0.182412)
ま、とりあえずRuby1.9の方がそれなりに速いってことで一安心。
が、うかうかしてるとJRubyに追いつかれるな。 競争は良いことだ。どきどきするけど。