本 日 の h o g e

■ [Py] Pikzie 使ってみた

確かに見やすくて素敵かも．

が，time.strptime 使ったら死んだ． assert_* 以前に死ぬのが謎．

import time
import pikzie

class TestTime(pikzie.TestCase):
    def test_strptime(self):
        time.strptime('2008 Nov 10 00:00:00', '%Y %b %d %H:%M:%S')

で

$ python hoge.py 
E

1) Error: TestTime.test_strptime
hoge.py:6: time.strptime('2008 Nov 10 00:00:00', '%Y %b %d %H:%M:%S')
/usr/lib/python2.4/_strptime.py:269: _TimeRE_cache = TimeRE()
/usr/lib/python2.4/_strptime.py:213: 'Z'),
/usr/lib/python2.4/_strptime.py:229: to_convert = sorted(to_convert, key=len, reverse=True)
/usr/lib/python2.4/site-packages/pikzie/__init__.py:5: list = iterable[:]
exceptions.TypeError: unsubscriptable object

Finished in 0.015 seconds

1 test(s), 0 assertion(s), 0 failure(s), 1 error(s), 0 pending(s), 0 notification(s)

ジェネレータをスライシングしようとしてこけたのか． けど 2.4 だから __builtins__ に sorted は定義済みのはずだけどなぁ．

あと assert_search_syslog_call が syslogd 1.4.1 相手だとよくキョドる． mark を見つけられなくて死亡することが多い． 深く追ってないけど，何か select 後の最初の read で EOF が返って，空文字列と比較しちゃってる風味．

ああ

即興で作った pikzie-svn-20081202.ebuild．

オレオレ証明書の https が含まれてるせいで interactive になってしまう． まあ，オレオレ ebuild なので気にしないことにする．

うお

今日 (12/02) svn up したら strptime の方は直ってた． 相変わらず kou さん反応 HAEEEEEEEEEEE!!!

てか tracker に書けば良かったかな...

■ [日記] kahakai 終了

今まで会社では kahakai を使い続けてたんだけど，もう何か普通にはビルド通らないし，無理やり通しても XIO 何たらかんたらで死亡するようになってしまった．

かといって自宅マシンと同じく compiz-fusion + emerald + kde とするにはパワーが足りなすぎる (と思う)． もっさり動作は精神衛生上とてもよろしくない． 動作が軽快でなければビジュアルなど極限まで切り詰めてかまわん．

設定とかめんどすぎてやってられんので，GUI でポチポチ設定できる (+数年前まで使ってたので何となく勝手が分かる) からという安易な理由で WindowMaker にしてみたんだけど，早くもウィンドウフォーカスとワークスペース移動にストレス爆発気味．

fluxbox かなー． これも昔使ってたけどもう WindowMaker と同じく全く覚えてないや．

■ [戯言] んー

俺は視野が狭いなあ． つくづく思う．

■ [日記] なんと

ウィスキーをグラスに注がずにボトルで飲むのは一般的には珍しいということが分かった．

個人的には全然違和感ないんだけどなあ．

■ [日記] はて

降りかかる火の粉は払わねばなりますまいとか以前に燃えさかる大木があらぬ方向から次々倒れ込んでくるよなー．

尻紙家の人々というか何というか．

■ [戯言] くそう

いつぞや も書いた気がするけど，CPAN モジュールのバグを踏んだり「ねーよwwww」な仕様やコード見たりすると萎える．

まあ，最近では Python の標準モジュールにも思ったけど． socket#makefile で返ってくる奴はタイムアウトを無効化されてるとか，SocketServer のサーバソケットを非同期的な感じにしようとするときもいことするはめになったりとか．

時と場合によるけども，ネットワーク (に限らず I/O 全般) プログラミングで永遠にブロックしっぱなしは危険信号出まくりだと思うのだが． ブロッキング I/O は書く側は楽だけど使う側には罠の多い茨の道なだけに，それを末端に押しつけるのはどうかと思うぞ．

最低限スマートな逃げ道の用意はしておいて欲しい．

Twisted という選択肢もあるけれど，外部モジュールで Python の魅力が半減するという罠．

■ [Py] subprocess.Popen

って，何も考えずにテキトーに使うとデッドロックするのか... ってもしかして使い方間違ってる?

from subprocess import Popen, PIPE

p = Popen(['/bin/cat'], executable='/bin/cat',
          stdin=PIPE, stdout=PIPE)

p.stdin.write('a' * (65536 * 2))
p.stdin.write('\n')

これで再現． もちろん os.write を使っても一緒．

strace とかかましてみれば分かるけど， python も cat もパイプへの書き込みでブロック． まあ当然と言えば当然なんだけど．

しかしこれを回避するために自前で select とか， 何か subprocess のうまみが半減してる気がするよなあ... ってまあそれしか思いつかん以上やるしかないのだけれど．

いけてねー．

うーん

subprocess - Subprocess management - Python v2.6.1 documentation

Warning: Use communicate() rather than stdin.write(), stdout.read() or stderr.read() to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process.

そう言われてもねえ．

子プロセスに渡したいデータが断続的に発生するものだったらどうすんのさ． それがバッファできるほど小さくないデータだったらどうすんのさ．

■ [戯言] うーん...

もうあかんやばい時間もうない死ぬ死ぬってなってから分担したんじゃ遅い．

そうなる前に，まだどうにかなるうちに，それを回避しておきたかったのだけれど．

そうなった時に備えて裏でしこしこ「こんなこともあろうかと」を準備しておくしかないのかな． うまくいった暁にはその努力はまるっきり無駄になるけれど，それを覚悟で...

ここ数ヶ月の間だけで 2 度も 3 度もそれで燃えさかる大木を直撃されている身としては，もはやそうやって身を守る以外に選択肢が見つからない．

■ [戯言] まあ

大変なのは大変だと思い込む自分の心の弱さ．

別に大変でも何でもなくむしろ大変態の俺．