* まもなく移轉
當サイトはまもなく移轉します。
* みっくみく事件の決着
驚いた。ドワンゴが殆ど完全に折れる形で、しかもこんなに早く決着が付くとは思はなかった。こんな結末になるとは夢にも思はなかった。
* Quốc ngữ と日本語
ベトナム語は六つの聲調を持つ言語であるが、現在それを表記する爲に用ゐられてゐる Quốc ngữ ではその六声調を書き分ける事が出來るらしい。
* 自然物と信仰／生體機械としての人間／初音ミク／オープンソース戰爭
みっくみくが JASRAC された件には非常にもやもやとさせられる。だから出來るだけ消化しようと試みた。Every man thinketh his burden is the heaviest.
* HsHyperEstraier 0.1
HyperEstraier の Haskell 用バインディングである HsHyperEstraier を公開した。
_
sábado, 31 marzo 2007
Haskell ―― System.IO.Handle のスレッド安全性
Cuenta Larga = 12.19.14.3.8; tzolkin = 5 Lamat; haab = 1 Uayeb
[Trackback Ping]
GHCで、
1. Handle を開く
2. スレッドを二つ起動。一つを t1、もう一つを t2 とする。
3. t1 がその Handle を hWaitForInput する。
4. t2 がその Handle を hClose する。
斯うすると t1 が Bad file descriptor 例外で落ちる。それはいいのだが、これを數百回繰返すと何かをかしな事が起こるらしい。具体的には書いてゐる最中の httpd なのだが、ab で負荷を掛けると httpd と ab がデッドロックしてしまふ。原因がどうしても分からないしぐぐっても特に情報が出ないので GHC のソースまで讀んでみたが、Handle の操作はちゃんとスレッドセーフになるやうに作られてゐて、やっぱり分からない。
hClose する前に t1 を killThread したら解決した。謎…
_
viernes, 30 marzo 2007
自衛と臆病
Cuenta Larga = 12.19.14.3.7; tzolkin = 4 Manik; haab = 0 Uayeb
[Trackback Ping]
自衛の爲に不機嫌な顏をして相手のツラに唾を吐き付けるやうな態度を、私も學ぶ必要があったのではないかと思ふ。露骨にやれば子供そのものだが、もう少し控へ目で理性的なやり方だってあるだらう。
小さい頃から然うした事をしないで來てしまった。普段は人を避けて引っ込み思案で、不滿を滅多に口に出さず、自分の立場を案ずる餘裕がある限り拳を振り上げたりしなかった。つまり臆病だった。そんな事では不幸になるだけだ。
『長年少しずつ溜まって行った憎しみが或る時爆発して、突然自分の家族を殺してしまふ』と云った事件は多く、身につまされる。明日は我が身かと思ふ。殺された者は無論不幸だが、殺してしまった者はそれよりもずっと、二重の意味で不幸だ。長年の苦しみに文句一つ言はずに耐へ忍んだ事が先づ不幸であり、そのために人殺しの罪を背負ふ事になった事が第二の不幸である。殺すつもりなど、その直前までは少しも無かったのだらうに。
−−
ところで最近 Haskell の fcgi ライブラリで FastCGI アプリを書いてゐたのだが、FastCGI と云ふものはどうにも良くない。何が良くないかと云ふと、FastCGI はリクエストがあって初めて動作を始めるものであるから、バックグラウンドで定期的に動作するやうな處理を書けないのが良くない。然うした處理は獨立したプロセスとして cron か何かで起動する事になるが、cron と云ふものは登録するのも解除するのも面倒で、crontab は人間が弄る事しか考へられてゐない。では anacron を使へば良いかと云へば然うでもなく、そもそもクライアントへの應答とバックグラウンド處理が獨立して動作するのは何となく氣味が惡いし、相互の情報のやり取りも簡單には行かない。
だからライブラリとして使ふ爲の httpd を書く事にした。これなら一つのプロセス内のスレッドで httpd が動き、別のスレッドで他の處理が動くやうに出來るので都合が良い。もっと早く斯うすれば良かった。
別のやり方としては定期處理も含めた全ロジックを單體のプロセスに任せて FastCGI スクリプトからは RPC でそれを呼ぶだけと云ふのもある。これは實際にやって見るまでは素敵なアイディアに見えるのだが、大體にして内部處理に於いては外界との交信と比べてかなり多くの情報が流れるものであるから、RPC そのものに掛かる時間的・空間的コストが馬鹿にならない。内部處理と表層をそこまでして分離する必要があるほど複雜怪奇になりがちなシステムを組まうとしてゐるのでなければ、やめておいた方が良い。勿論、一つの關數内に HTML 斷片と SQL 文の両方を書いたりするくらゐならば、無理にでもプロセスを分けた方が何倍もマシではある。ついうっかりそのやうな馬鹿なコードを書いてしまふリスクを物理的に回避出來るからだ。
RPC 方式にはその RPC I/F を他の用途に轉用出來るメリットがあるが、既存の特定の RPC プロトコルに拘りさへしなければ、一つの CGI でブラウザからのリクエストと RPC I/F でのリクエストを区別無く扱う事は可能だ。入力は application/x-www-form-encoded または YAML か何か。内部では應答として YAML か何かを生成し、ブラウザが相手だった場合だけそれを HTML に變換してから出力すれば良い。HTMLのフォームに細工する必要はあるが、そんなに難しい事ではない。で、httpd を書く必要に氣附いたのは、この方法でまともな BBS を書かうとしてゐる最中の事だった。FastCGI アプリとして書いてゐたから、これは書き直しだ…。
key=value;key=value;... と XML を相互變換する上手い（それほどまずくない）方法については後で書く。忘れなければ。
2002
10
11
12
2003
1
2
3
4
5
6
7
8
9
10
11
12
2004
1
2
3
4
5
6
7
8
9
10
11
12
2005
1
2
3
4
5
6
7
8
9
10
11
12
2006
1
2
3
4
6
7
8
9
10
11
12
2007
1
2
3
4
5
6
7
8
9
10
12
2008
1
4