月: 2008年4月

今日の自転車

睡眠不足だったが、なんだかすげえ調子よかった。出勤とはいえ、土曜なので手ぶらであり、ジャージのポケットに携帯電話と身分証と、若干のお金をつっこんで激走。
大学までの往復で、平均は 28km/h か 29km/h くらい出ていた模様。メーターが不調で、記録が消えてしまったんだけど。往路は、登戸から Anchor RCS に乗ったけっこう速い人に引いてもらったり、こちらが引いたり。復路の多摩川はずっと 52×17 回して、35km/h くらい。綱島街道や世田谷通りでは 52×15 をずがーっと回して、ここ最近ない勢い。
もうちょっと調子を上げたら、山にもいかないとね。
自転車は最高に気持ちいいが、やっぱり疲れるし、おなかが空く。ま、それがいいんだけど。
odo 4533.1km

今日の自転車

往路は向かい風で、けっこう苦戦。26.1km/h.
復路は一度環八まで上がって、世田谷通り経由で帰る。
38.02km @ 27.1km/h (1h24m01s) odo 4492.8km
まあまあかな。
ボトルの飲み口が壊れてしまって、ガムテープで補修して帰る。
それでも漏れるので、フレームがだいぶ汚れてしまった。洗車しないとなー。

Qgrey

SPAM 対策で QGrey というのを入れた。greylisting を行う qgreylist に、ドメイン名ベースの selective SMTP relay というのを組み合わせた方式。
人手で作られたブラックリストや NG word list とか、機械学習系のアルゴリズムを使わないので、その手のフィルタよりも安心な感じ。qmail にパッチ当てなくてもいいしね。
satoiku.comの記事 を参考にさせていただきました。
SPAM 激減しました。最高です。

桜

「桜は、散る日がくるまでは雨が降っても、何があっても絶対に散らないんですよ」というのは、去年の桜のころに、信州飯田の和菓子屋さん「赤門や」のおかみさんから教わったこと。
昨日今日は、冷たい雨が降った。
だけど、桜は散らず。
まだしばらくもつかな。
体調が万全ではないので、明日は自転車を自粛。でも、写真を撮ろう。
明後日まで咲いていてくれるといいな。
桜吹雪の中を駆け抜ける瞬間、というのは、日本のサイクリストなら誰もが心踊るひととき。

Windowsとstat()と僕

GMVというのを
ずっと作っている。普段の開発環境は Mac だが、GTK+ を使っており、いちおう
cross platform ということになっていて、各種 Unix (X11) で動くのはもちろん
のこと、いちおう Windows でも動くことになっている。
で、バイナリ配布もやっており、研究室にある僕の iMac でスクリプトを実行すると、
– ソース
– Mac 用の Universal な application bundle (gmv.app)
– Windows 用のバイナリ (gmv.exe)
を生成するようになっている。Windows 向けのビルドには MinGW を使っており、
iMac には MinGW のライブラリと MinGW な gcc のクロスコンパイラがインストール
してある。
しかし、いくら MinGW を使っているといっても、Windows との互換性を維持する
のはけっこう大変で、Mac や FreeBSD できっちり動くプログラムが MinGW な環境でもコンパイルがちゃんと通ったからといって、動くとは限らないのだ。
幸いにして、GMV を使ってくださっている方々の大半 (というか、全員) はMac および Unix 陣営なので、これが問題になることは普段はないのだが、自分の大学の、4月の学生実験だけは別だ。なにしろ、数十人の学生がいっせいにWindows で GMV を使う。これは、ものすごく怖い。
去年は、Windows なテスト環境を PentiumM な ThinkPad T42 しか持っておらず、SMP な環境でたまに落ちるバグ、というので苦しんだ。最近の計算機はみんなPentium4 Hyperthreading をはじめとして、CoreDuo や Core2Duo なわけで、純粋に uniprocessor な環境、というのはほとんどない。で、このときはMinGW なコンパイラを gcc-3.4 から gcc-4.0 にアップデートすることで解決した。
今年はどうかというと、1月にかなり Windows でデバッグをしたので、完璧に動くとタカをくくっていた。まったく甘かった。
Windows native な開発環境は、Cygwin と NTEmacs がメインで、コンパイラやライブラリはやはり MinGW だ。Cygwin はまあ、そこそこ便利なのだが、Windows には fork() がないのが原因なのか、とにかくプロセスが起動するまでがものすごく遅い。したがって、細かいソースファイルをたくさんコンパイルしたりだとか、そういう作業がとてもしんどい上に、MinGW なライブラリを使っていることが関係するのかどうかわからないが、gdb の出力は概ね意味不明であり、stack backtrace なんかはほとんど役に立たないといってよいレベル。したがって、Mac とかそのほかの Unix で完璧に動くようにしておいてからじゃないと、Windows で作業するのは非常にきつい。
今回のバグはなんだったかというと、ファイルのタイムスタンプを調べるのに使っていた stat() の挙動が怪しい、というものだった。thread safe になっていないとか、そういうことが原因なのかなんだかは結局わからずじまいだが、stat() それ自体は成功するものの、そこから数行を実行する間にプログラムがクラッシュするのだ。結局のところ、GLib にある g_stat() を使うことで解決した。この関数は、結果を返す構造体も OS 依存な struct stat のままだし、実際のところ中では何をしているのか見ていないんだけど、g_stat() にしたらあっけなく動くようになった。はー。
まあでも、デバッグの途中で別のバグをみつけて、直すことができたのでそれはそれでいいとしよう。
つらい二日間だった…