Programming Ruby Second Edition が届く。
proc_initgroups に目をつけて core を吐かせようとするも失敗する。
static VALUE
proc_initgroups(obj, uname, base_grp)
VALUE obj, uname, base_grp;
{
#ifdef HAVE_INITGROUPS
if (initgroups(StringValuePtr(uname), (gid_t)NUM2INT(base_grp)) != 0) {
rb_sys_fail(0);
}
return proc_getgroups(obj);
#else
rb_notimplement();
return Qnil;
#endif
}
という実装なので、StringValuePtr(uname) が評価された後に base_grp の to_int で uname を replace し、StringValuePtr(uname) の値が指す領域を開放してしまおうと考えたのである。
が、しかし、(手元の) gcc は引数を右から評価するので、 StringValuePtr(uname) の前に NUM2INT(base_grp) が評価されて目論見通りにはいかないのであった。
まぁ、HAVE_INITGROUPS かつ評価順序が左からなものがあれば話は変わって来るが。
あ、あともうひとつ条件があって free したときに OS にメモリを返させることができないといけない。 そうしないと、SEGV までにはできない(かもしれない)。
glibc だと malloc に要求する大きさが (たぶん) 128K 以上の場合は mmap で確保し、 free するとその時点で munmap してくれるので、 その条件を満たせるのだが。
time_t が 64bit になれば、2038年を越えても表現できるようになる。
akr@amd64-linux1:~/ruby/ruby$ ruby -e 'p Time.local(3000,7)' Tue Jul 01 00:00:00 PST 3000 akr@amd64-linux1:~/ruby/ruby$ ruby -e 'p Time.local(3000,1)' Wed Jan 01 00:00:00 PST 3000
が、(いまのところ) 夏時間で問題が起こる。 たとえば、EST5EDT では、3000年は夏時間がなくなっている。
akr@amd64-linux1:~/ruby/ruby$ TZ=EST5EDT ruby -e 'p [Time.local(2000,1),Time.local(2000,7)]' [Sat Jan 01 00:00:00 EST 2000, Sat Jul 01 00:00:00 EDT 2000] akr@amd64-linux1:~/ruby/ruby$ TZ=EST5EDT ruby -e 'p [Time.local(3000,1),Time.local(3000,7)]' [Wed Jan 01 00:00:00 EST 3000, Tue Jul 01 00:00:00 EST 3000]
また、NZ では、つぎのように一年中夏時間になる。
akr@amd64-linux1:~/ruby/ruby$ TZ=/usr/share/zoneinfo/NZ ruby -e 'p [Time.local(2000,1),Time.local(2000,7)]' [Sat Jan 01 00:00:00 NZDT 2000, Sat Jul 01 00:00:00 NZST 2000] akr@amd64-linux1:~/ruby/ruby$ TZ=/usr/share/zoneinfo/NZ ruby -e 'p [Time.local(3000,1),Time.local(3000,7)]' [Wed Jan 01 00:00:00 NZDT 3000, Tue Jul 01 00:00:00 NZDT 3000]
夏時間を気にしないとすれば、 2038年問題は Linux では比較的早期にとりあえず解決されてしまう気がする。
時間が解決する問題についてはあまりコストをかけないほうがいいと思うので、 Date: フィールドを Time にするのもそれほど悪いということはないかも知れない。
CIA Open Source Notification System
うぅむ。こんなシステムがあるとは。
自分の行動も http://cia.navi.cx/stats/author/akr に載っている。
ちょっと大きめの地震があってテレビをつけてしばらく待つと、 地図が出て震度や震源が出る。
う、震源がつくばのあたりではないか。
それなら、というわけで (つくばに設置してある) cvs.m17n.org に ssh してみるが、 とくに問題はないようだ。
gcc の -aux-info というオプションを始めて使ってみた。
これを使うと、関数のプロトタイプ宣言が抽出できるのだが、 #ifdef などでコンパイルされなかったのは取り出せないので微妙なところではある。
ちょっと CIL を使ってみる。
しばらく前からメモは damemo でとっているのだが、 いくつか気になるところがはっきりし始めたので、作り直し始める。
くーすについてちょっと調べる。
いろんな側面があるのだとは思うけれど、 ざっと読んだ段階では顧客と開発者の分業に注目しているという印象が残った。
ちょっとしたきっかけで、daily build をしばらく中断していたのだが、 別の場所で動かし始めてみる。
今度は build 結果を公開するかな。
そういえば、daily build に関連しなくもないことで、以前から考えていることがある。 それは、build したものをいつ削除するか、ということである。
定期的に (今回は一日にひとつ) 増えるので、削除しないとすれば、 必要な disk 容量は時刻に対してだいたい線形に増加していく。
この増加を抑えるために、新しいものはほとんど残しておいて、 古いものはまばらに残しておくということが考えられるが、 そのように残しておくためにはどのようなアルゴリズムで削除すればよいだろうか、 という疑問である。
即座に思いつくのは、ランダムに削除することである。 毎日ランダムにひとつ削除すれば、古いもの程削除される機会が多いので、 古いもの程まばらになっていくと想像できる。
では、ランダムではないアルゴリズムにはどういうものが考えられるだろうか? そして、そのアルゴリズムは時系列に対しどのような分布で build を残すだろうか?
また、時系列に対する分布を与えられたときに、 その分布で build が残るように削除を行なうアルゴリズムは考えられるか?
どうやら、とくに問題なく動いている模様。
今日のぶんでは、test_core_03_notify(Rinda::TupleSpaceTest) が失敗しているけれど、これはなんか気のせいな感じ。
クリスマスまでの日数は次のようにして求められる。
% ruby -rdate -e 'p Integer(Date.new(2004,12,25) - Date.today)' 59
daily build は毎回 clean な状態から build する。
これは、ふだん手元で build するのとは違う。 手元では、checkout 済みの working directory で cvs up して make するわけで、 だいたいにおいて以前のオブジェクトファイルなどが残った状態から build する。
この違いは、普通はとくに気にならない。 ところが、今日はその違いが表面化した。 手元では ripper のテストがいくつか失敗するのに、 clean build ではまったく問題がでないのである。
たぶん ripper まわりの依存記述がおかしいのだろうけれど、 まぁ、そのへんのオブジェクトファイルを消して作り直せばとりあえず問題なくなるので、 今回は気にしないことにしよう。
[latest]