2003年12月28日(Sun) 体力勝負の一日
● 貧乏旅行は続くよ
夜行でベネチアへ。行きがけには6人掛けの個室に5人が座る。イタリア・フランス国境にある友人の別荘にスキーに行くドイツ人女性は、イタリア人の車掌にスペイン語で乗り換え駅のことを尋ねていた。アメリカからの2人はリュックサックを自転車の鍵で棚に固定している。なるほどね。
ベネチアでは、パンを食べた後、ムラノ島にわたりガラス博物館を見学したり帰りに墓地の島で降りてみたり。午後から降り出した雨はだんだんと水溜りを作って寒さを増すのでした。地図を眺めながら小さな路地を行ったり来たりするのは楽しい。B&Bで食べた昼食も喫茶店で飲んだコーヒーも運河の横にみつけた安い料理屋さんで食べたベネチア風イカのイカ墨あえもとてもおいしかったのでした。
帰りの夜行は4人。イギリスの英語をしゃべると思っていた兄ちゃんはマイアミで選挙管理の仕事をしてるのだそうだ。前回は彼は関係してなかったけど今度は大丈夫だから見ててね、とのこと。ふむふむ。一週間の休みでヨーロッパを回ったのだそうで、日本人みたいな旅行をしている。最後の一日をミュンヘンで過ごして明日の朝4時に空港に向かうのだそうな。ベジタリアンの女の子はバイエルン料理を楽しめただろうか?
イカ墨料理は僕の消化器系の処理速度を測定する重要な手がかりになるのでした。結果は書かないけど。
2005年12月28日(Wed) 巨大なブルドーザーが運ばれていった
● 昨日はジョギングのあとトラブル対応山頂行きコースでした。あーあ。お返事したいメールがたくさんたまってきている。
● @nifty:デイリーポータル Z:オノマトペであそぼう
擬音語や擬態語をオノマトペというのだそうな。写真がおもしろいなー。何かに似ていると思ったら「にほんごであそぼ」にこういうコーナーがあったんだ。
● 最新の日記にいろいろなサイトから1つずつリファラが付く
かなり古い日付のURLからも来ているので、きっとお行儀のよくないロボットがいるのだろう。おひきとり願うよう準備中。
(追記) もうわかりました。…20020729.htmlから3秒間に4回。「Mozilla/5.0 (compatible; BecomeBot/2.3; MSIE 6.0 compatible; +http://www.become.com/site_owners.html)」64.124.85.210から来てました。ではさやうなら。
● いよいよだめかもメインマシン
viでコーディングしてたらいきなり目の前が真っ黒に。コンパイルもしてないしcron jobも終わったところだったのに。
とりあえずkernelのバージョンを落としてみた。年度末のゴタゴタが終わるまで持ってほしいところだけれど…と書いて、年度末過ぎたらしばらくモノを買う予算が降りなくなることに気づいた。うぎゃー。
● 夏目漱石じゃない1000円札ってどんなのだっけ…。この前の出張で見たはずなんだけどな。
● kernelを変えるとconfigureが失敗する
configure: error: C preprocessor "/lib/cpp" fails sanity check See `config.log' for more details.
とおっしゃる。言われる通りconfig.logを見ると、
/usr/include/bits/local_lim.h:36:26: linux/limits.h: No such file or directory
うひょい。kernel-headers、もう残ってないんですけど…。
というわけで次に行くべきはこれまで使ってたkernelのUP版か。
2006年12月28日(Thu) いい天気。事務シゴトを淡々と。
● [run] 最短コース 25分19秒 3.14マイル 8.1分/マイル
久しぶりに走ろうとしたらジョギングパンツとTシャツを忘れてきたことに気づいたので、普通の短パンで。やっぱり足の動きが制限される感じだったけれど、タイムは悪くなかったみたい。
● [Ruby] 計算時間の謎
ささださんが、Arrayの総和を求めるのにかかる時間がo(N)以上になってそうだ、とお
っしゃっている。なんだか楽しそうだったので、事務シゴトの裏で測定してみました。
全体を見ると確かに放物線のようですが、僕は直線がつながってるのかなあ、という印象を受けました。配列がCPUのキャッシュに入るか入らないかとか、配列のインデックスがFixnumかBignumか、とかで直線の傾きが変化する、という説はいかがでしょう?(ってここに書いてもな。)
測定は、ささださんのRubyスクリプトをbenchmark.rbとして下記のシェルスクリプトから起動しました。
#!/bin/sh echo \# `ruby -v` echo \# `uname -srm` echo \#n time power=1 njobs=3 while [ 1 ]; do n=`echo $power | awk '{printf("%.0f", 2**$1)}'` power=`echo $power | awk '{print($1+0.2)}'` t=`ruby benchmark.rb $n` echo $n $t done
測定は、ruby 1.8.3 (2005-09-21) [i686-linux]
(古っ!)とLinux 2.6.12-4msmp i686
のもの。実メモリ1Gバイト、Xeon 2.8GHz×2、HTありでのものです。
● やっぱり最新表示の時はvolatile.tdrを読んだ結果か、そのキャッシュの残りしか@refererに入らないみたいだ。なんでだろう…。(追記) 最新表示のイニシャライザが特別製のようです。最新表示の場合はプラグインの中で一日ごとのリファラを消して読み直すようにしたらリンク元を表示できるようになりましたが…はたして副作用がないかどうか。(また追記) いや、最新表示で誰かが自分の日記にリンクをしてくれたのを知りたいので、volatile.tdr だけが表示されるのがいいんだ。
2007年12月28日(Fri) ずーっと雨
● twitterは遅くWindowsはBlue screen
ログインに5分、updateは反映されず。仕事の記録を付けるのにこんなに待たされるのはいかんよね。自前でやらないといけないかな。
そしてWIndowsマシンはBlue screenに。ftsisk.sysという文字が見える。インサイドMicrosoft Windows (@IT) によれば、「FtDiskドライバ(\Windows\System32\Drivers\Ftdisk.sys)は、基本ディスク上のボリュームを表現するディスクデバイスオブジェクトを作成し、シンプルボリュームを含む、すべての基本ディスクボリュームの管理を担当します。」とのこと。やっぱりSolid state diskがダメになりつつあるのかな…。
● [Ruby] 手元でruby-1.9.0
$ uname -srm Linux 2.6.12-4msmp i686 $ ./configure --prefix=$HOME/local/ruby-1.9.0 $ make $ TMPDIR=$HOME/tmp make test (中略) PASS 821 tests
おっけー。ではtimespecの実験を。
$ rm -f thread.o $ make cflags=-DTHREAD_DEBUG miniruby $ ./miniruby -e 'Thread.new{}.join(1000000000)' 0xb7f146c0 - create - stack size: 524288 0xb7f146c0 - create: 0x81b1258 (0)0xb7f146c0 - thread_join (thid: 0xb7bdbbb0) 0xb7f146c0 - native_sleep 999999999 0xb7f146c0 - native_sleep: pthread_cond_timedwait start (-2096083237, 229791000) 0xb7bdbbb0 - thread start: 0x81b1258 0xb7bdbbb0 - thread start (get lock): 0x81b1258 0xb7bdbbb0 - thread end: 0x81b1258 0xb7bdbbb0 - ubf_pthread_cond_signal (0x81709b0) 0xb7f146c0 - native_sleep: pthread_cond_timedwait end (0) 0xb7f146c0 - rb_thread_schedule 0xb7f146c0 - rb_thread_alone: 1 0xb7f146c0 - native_sleep done 0xb7f146c0 - thread_join: interrupted (thid: 0xb7bdbbb0) 0xb7f146c0 - thread_join: success (thid: 0xb7bdbbb0) 0xb7f146c0 - rb_thread_terminate_all (main thread: 0x81709b0) 0xb7f146c0 - terminate_i: main thread (0x81709b0) 0xb7f146c0 - rb_thread_alone: 1
tv_secはやっぱり負になる。昨日のパッチを当てると、
$ ./miniruby -e 'Thread.new{}.join(1000000000)' 0xb7f196c0 - create - stack size: 524288 0xb7f196c0 - create: 0x81b1258 (0)0xb7f196c0 - thread_join (thid: 0xb7be0bb0) 0xb7f196c0 - native_sleep 999999999 0xb7f196c0 - native_sleep: pthread_cond_timedwait start (2198884125, 614500000) 0xb7be0bb0 - thread start: 0x81b1258 0xb7be0bb0 - thread start (get lock): 0x81b1258 0xb7be0bb0 - thread end: 0x81b1258 0xb7be0bb0 - ubf_pthread_cond_signal (0x81709b0) 0xb7f196c0 - native_sleep: pthread_cond_timedwait end (0) 0xb7f196c0 - rb_thread_schedule 0xb7f196c0 - rb_thread_alone: 1 0xb7f196c0 - native_sleep done 0xb7f196c0 - thread_join: interrupted (thid: 0xb7be0bb0) 0xb7f196c0 - thread_join: success (thid: 0xb7be0bb0) 0xb7f196c0 - rb_thread_terminate_all (main thread: 0x81709b0) 0xb7f196c0 - terminate_i: main thread (0x81709b0) 0xb7f196c0 - rb_thread_alone: 1
NetBSDとの比較はまた後ほど。
● NetBSDとLinuxでtimeval.tv_secのバイト数が違う
下記のプログラム(timesize.c)をコンパイルして実行してみた。
#include <stdio.h> #include <stdlib.h> #include <sys/time.h> #define print_sizeof(var) {printf("sizeof(" #var ") is %d\n", sizeof(var));} int main(void) { struct timespec ts; struct timeval tv; print_sizeof(ts.tv_sec); print_sizeof(tv.tv_sec); return EXIT_SUCCESS; }
手元では、
$ uname -srm; gcc -o timesize timesize.c; ./timesize Linux 2.6.12-4msmp i686 sizeof(ts.tv_sec) is 4 sizeof(tv.tv_sec) is 4
このホストでは、
$ uname -srm; gcc -o timesize timesize.c; ./timesize NetBSD 3.1.1_PATCH alpha sizeof(ts.tv_sec) is 4 sizeof(tv.tv_sec) is 8
というわけで、ruby-1.9.0-0のthread_pthread.cの412行目の足し算
ts.tv_sec = tvn.tv_sec + tv->tv_sec;
がうまくいってないのかな。ここで、tsはtimespec型、現在時刻の入るtvnと待ち時間の長さが入るtvはtimeval型。
えーと。timespec.tv_secは、NetBSDではヘッダファイルよりtime_tで、Linuxではman nanosleepよりtime_t。
ちょっといじってみたけど…うーん。単純に型キャストすればいい、というわけでもなさそう。ちゃんと勉強しなくちゃな。
● [Ruby] x86_64でruby-1.9.0-0
$ uname -srm Linux 2.6.23-31m.mo4 x86_64 $ ./configure --prefix=$HOME/local/ruby-1.9.0 $ make $ make test : PASS 821 tests
これは、まあうまくいくよな。
$ rm -f thread.o $ make cflags=-DTHREAD_DEBUG miniruby $ ./miniruby -e 'Thread.new{}.join(1000000000)' 0x2aaaabacc280 - create - stack size: 524288 0x40084950 - thread start: 0x7ea860 0x2aaaabacc280 - create: 0x7ea860 (0)0x2aaaabacc280 - thread_join (thid: 0x40084950) 0x2aaaabacc280 - native_sleep 999999999 0x40084950 - thread start (get lock): 0x7ea860 0x40084950 - thread end: 0x7ea860 0x2aaaabacc280 - native_sleep: pthread_cond_timedwait start (2198909773, 996561000) 0x40084950 - ubf_pthread_cond_signal (0x7700f0) 0x2aaaabacc280 - native_sleep: pthread_cond_timedwait end (0) 0x2aaaabacc280 - rb_thread_schedule 0x2aaaabacc280 - rb_thread_alone: 1 0x2aaaabacc280 - native_sleep done 0x2aaaabacc280 - thread_join: interrupted (thid: 0x40084950) 0x2aaaabacc280 - thread_join: success (thid: 0x40084950) 0x2aaaabacc280 - rb_thread_terminate_all (main thread: 0x7700f0) 0x2aaaabacc280 - terminate_i: main thread (0x7700f0) 0x2aaaabacc280 - rb_thread_alone: 1
お。パッチなしでもtv_secが期待通りの表示になってる。
tv_secの大きさは…
$ uname -srm; gcc -o timesize timesize.c; ./timesize Linux 2.6.23-31m.mo4 x86_64 sizeof(ts.tv_sec) is 8 sizeof(tv.tv_sec) is 8
ふむふむ。 tv_secの大きさがtimevalとtimespecで同じだと問題がないのかしらん。
● [Momonga] x86_64でskypeを使う
skype_static-1.4.0.118-oss.tar.bz2をいただいてきてみた。
$ ./skype_static-1.4.0.118-oss/skype ./skype_static-1.4.0.118-oss/skype: error while loading shared libraries: libXrandr.so.2: cannot open shared object file: No such file or directory
lib64にあるライブラリは使えないんだろうね。 というわけで、とりあえず、
$ ldd ./skype_static-1.4.0.118-oss/skype | grep 'not found'
して足りないライブラリを、i686なMomongaマシンからコピーしてきて、 ./skype_static-1.4.0.118-oss/lib/というディレクトリを掘ってつっこんでみました。
LD_LIBRARY_PATH=./skype_static-1.4.0.118-oss/lib ./skype_static-1.4.0.118-oss/skype
起動したよ!…びっくり。そんなもんなのかあ?
(追記)scim-skkで漢字を入力するには、LANG=ja_JP.EUC-JPにする必要があるみたい。
● [Momonga] gnashを作る
紆余曲折があってgnashを作ってみることにしました。Momongaのgnash.specをもらってきて、とりあえず
rpmbuild -bb gnash.spec error: Failed build dependencies: libmng-devel is needed by gnash-0.8.1-1m.mo4.x86_64 libxml2-devel is needed by gnash-0.8.1-1m.mo4.x86_64 SDL-devel is needed by gnash-0.8.1-1m.mo4.x86_64 SDL_mixer-devel is needed by gnash-0.8.1-1m.mo4.x86_64 libogg-devel is needed by gnash-0.8.1-1m.mo4.x86_64 libvorbis-devel is needed by gnash-0.8.1-1m.mo4.x86_64 gstreamer010-devel is needed by gnash-0.8.1-1m.mo4.x86_64 fltk-devel is needed by gnash-0.8.1-1m.mo4.x86_64 gtkglext-devel is needed by gnash-0.8.1-1m.mo4.x86_64 curl-devel is needed by gnash-0.8.1-1m.mo4.x86_64 mesa-libGL-devel is needed by gnash-0.8.1-1m.mo4.x86_64 mesa-libGLU-devel is needed by gnash-0.8.1-1m.mo4.x86_64 boost-devel is needed by gnash-0.8.1-1m.mo4.x86_64 agg-devel is needed by gnash-0.8.1-1m.mo4.x86_64
足りないパッケージをyum installしてもう一度、
$ rpmbuild -bb gnash.spec error: Failed build dependencies: agg-devel is needed by gnash-0.8.1-1m.mo4.x86_64
あら?aggもTO.Alterなのですね。agg.specをもらってきて、ソースとパッチもいただいて、
$ rpmbuild -bb agg.spec # rpm -Uvh ../RPMS/x86_64/agg-* $ rpmbuild -bb gnash.spec <中略> ERROR: No DocBook2X tools installed! Either install it from http://docbook2x.sourceforge.net or .deb users: apt-get install docbook docbook2x docbook-utils docbook-xml docbook-xsl texinfo xsltproc or configure without --enable-docbook <中略> WARNING: You need to have the MTASC compiler packages installed to run some of the tests in Gnash testsuite. You can install it from http://mtasc.org or .deb users: apt-get install mtasc WARNING: You need to have the 'swfmill' tool installed to run some of the tests in Gnash testsuite. You can install it from http://iterative.org/swfmill/
とりあえずERRORだけ直そう…他にもいろいろ足りないものがあって、
$ diff -u gnash.spec{.r18367,} --- gnash.spec.r18367 2007-12-29 01:12:25.000000000 -1000 +++ gnash.spec 2007-12-29 02:24:10.000000000 -1000 @@ -26,6 +26,8 @@ BuildRequires: firefox BuildRequires: boost-devel BuildRequires: agg-devel +BuildRequires: docbook2X, kdelibs-devel, expat-devel, libutempter-devel +BuildRequires: libidn-devel, libacl-devel %description @@ -98,6 +100,11 @@ %{_libdir}/mozilla/plugins/libgnashplugin.so %changelog +* Sat Dec 29 2007 zunda <zunda at freeshell.org> +- (kossori) +- added BuildRequires: docbook2X, kdelibs-devel, expat-devel, + libutempter-devel, libidn-devel, libacl-devel + * Sat Sep 1 2007 NARITA Koichi <pulsar@momonga-linux.org> - (0.8.1-1m) - update to 0.8.1
して作ってみた。
$ rpmbuild -bb gnash.spec <中略> In file included from /usr/include/gtk-2.0/gdk/gdkcairo.h:23, from /usr/include/gtk-2.0/gdk/gdk.h:30, from /usr/include/gtk-2.0/gtk/gtk.h:31, from gtk_glue.h:26, from gtksup.h:30, from gui_gtk.cpp:30: /usr/include/gtk-2.0/gdk/gdkcolor.h:30:19: error: cairo.h: No such file or directory <後略> $ locate cairo.h /usr/include/cairo/cairo.h /usr/include/gtk-2.0/gdk/gdkcairo.h /usr/include/pango-1.0/pango/pangocairo.h /usr/lib64/ruby/site_ruby/1.8/x86_64-linux/rb_cairo.h
えー。gdkcolor.hのミスか、configureが-Iオプションを足し足りないのか…。 ごめん。今宵はここまでにします。
2009年12月28日(Mon) 山頂見えるけどちょっとVog
● それぞれのイベントに独立にタイムゾーンを設定できるカレンダーはRuby 1.9.2で可能になる?
Palm OSでは簡単に実現できていたように見える、それぞれのイベントに独立にタイムゾーンを設定する機能がなぜモダンなカレンダーアプリケーションに無いのか、理由かもしれないことを思いついた。
akrさんによる、Ruby札幌02での講演「Rubyにおける2038年問題の解決」(PDF) で思い出させていただいたのが、POSIXのzoneinfoのAPIが基本的に単一のタイムゾーンしか扱えないようにできている、ということ。システムコールの時刻に関するAPIはローカル時刻を扱う時にシステム全体のタイムゾーンか、あるいはTZ環境変数を見るんだよね。僕の作ったアプリケーションのいくつかは、マルチスレッドになれないなあ、とひやひやしながら、TZ環境変数を書き換えながらローカル時刻を扱っている。カレンダーアプリケーションでイベントを表示したり編集したりするたびにプロセス全体にロックをかけてTZ環境変数を操作してたら、実用にならないくらい遅くなりそうだ。POSIXなんて知らなかったPalm OSにはこういう制限が無かったのかもしれない。
これに対して、Ruby 1.9.2ではTimeオブジェクごとに任意の時差(ってタイムゾーンだよね)を指定可能になるのだそうだ。みなさん、これは使いやすいカレンダーアプリを作るチャンスですよ♪特にGoogle calendarさん〜。僕も書きたいけどきっと余裕が無い orz。
ってSunbirdのローカルなカレンダーは既に複数タイムゾーンに対応してるんだよね。どうやって実装されてるのか見てみたい。いつ。
● 自転車のサドルが来た。Sette Lynx。ケツに合うといいな。
> さく [で、夏目漱石でないなら野口英世だったのか伊藤博文だったのか。ATMじゃ伊藤博文は使えないかもな。]
> zunda [虚ろな目の女性が書いてあった、という印象が強かったのですが、野口英世も伊藤博文も女性じゃないですよね。ということは僕..]
> h12o [虚ろな目の女性は5000円札に樋口一葉でしょうかね?]
> zunda [おぉ〜この人だぁ。5000円札だったのですね。]