日々の破片

_ WebDAVメモ

.NET Framework 3.5のWebClientクラスのuploadメソッドを呼ぶのだがどうにもエラーになる。

調べると、WebDAVでファイルを送り込むのはきわめて簡単だとわかり、HttpWebRequestを使って実装した。PUTを使うこと、URIでファイル名まで指定すること、ヘッダ変数TranslateにFを指定すること(と、Exchange関係のMSDNページに出ているのだが、IISのWebDAVでは不要な気はする。もっとも付けても害は今ところないので入れている)くらい。成功すると初回はcreatedが返り、2度目以降はnocontentが返る。

だが、サーバ側のログを見ていると、401と20xで必ずペアで出ていることがわかった。（Credentialsプロパティを指定する必要があって、それはWindows認証なのだ）ということは、500Mのファイルとか送信するのはばかげた話だ。

2ファイル目以降は、PreAuthenticateプロパティをtrueにすることで2回送信する必要はないが、初回については何か認証が必要な軽いメソッドを呼ぶのが良いだろう。おそらくそれがMKCOLで、本来送りたいファイルが、/a/b/c.txtなら/a/b(追記：が自然だと思うがMKCOLのURIは/a/b/のように末尾ディレクトリセパレータが必要)を指定するのが良さそうだ。

追記：SendChunkedをtrueにすれば軽減できるかも。

_ windowsの謎

気のせいのような気もするが、net use \\hostname\root の形式でマウントすると、hostnameに現在ログイン中のアカウントと同名、同パスワードが登録されていると、そのまま通るけど、hostname=a.b.c.dの時に、net use \\a.b.c.d\rootの形式でマウントしようとするとユーザ名とパスワードを訊かれる。

ホスト名を入れると気をきかせてユーザIDとパスワードを送り込むが、IPアドレスの場合はユーザに確認するという仕様なのかなぁ。

_ 買ったけど読んでない

本屋へ行ったら松本次郎の新刊が出てたので買った。

地獄のアリス 1 (愛蔵版コミックス)(松本 次郎)

この人は、そういえば、最初講談社で、次が小学館で、そして集英社（途中、太田出版とか行き来しながら）と、典型的ないかした（でも稼げない）漫画家道を歩んでいるようでなんか心配になるが、大きなお世話だなぁ。

ウエンディ (Ohta comics)(松本 次郎)

（いろんな面で衝撃的だったが、これが連載してた講談社ではなく太田出版から出ていたところが前途多難なマンガ道）

_ Win32OLEメモ

soraさんのparallelテストでWin32OLEが死ぬのだが、これが死ぬのが当然な死に方でちょっと弱る。

仕組み上、テストがメインスレッドではないスレッドで実行される。

そこまではそれなりに良い（はず）。というのは、助田さんがメインスレッド以外で呼ばれたときのために、個々のスレッドでCoInitializeしているからだ。

が、実はこの対応自体がいまひとつだった。というのは、そのスレッドの終了時にCoUninitializeするからだ。

通常であればこれは正しい。

しかし、Rubyの場合、オブジェクトの解放はGC起動となっている。

つまり、あるスレッドでCoCreateしたオブジェクトが、そのスレッドが終了した後に解放される可能性があるということだ。

当然、元のスレッドは存在しないので、GCが行われているスレッドでのRelease呼び出しとなる。プロクシが必要な呼び出しであれば、そこで死ぬ。

ということは、クロススレッドを前提としたGIT経由のアクセスだけではなく、オブジェクトの生成はすべてメインスレッドに寄せるか、スレッド終結時に、そのスレッドで生成したオブジェクトの解放をするといった処理が必要となるのではないだろうか（というか、存在しなくなったスレッドで生成したオブジェクトってそもそも廃棄できるのだろうか？）

_ 3/4日記の間違いを訂正

> 仕組み上、テストがメインスレッドではないスレッドで実行される

これは違って、テストの入出力の受け持ちがワーカスレッドで、テストそのものはメインスレッドで実行される（と読めるんだけど自信なし）。

（parallel.rbでスレッド作ってるのはここ）
        th = Thread.new do
          begin
            while buf = (self.verbose ? i.gets : i.read(5))
              @stdout.puts "p #{[buf].pack("m").gsub("\n","")}"
            end
          rescue IOError
          rescue Errno::EPIPE
          end
        end

でも、いずれにしてもGCはどのスレッドでも起動されるので、オブジェクトを生成したのではないスレッドで回収に入ることがあるのは間違いない。

不思議なのは、-j 1で実行するとほぼ完走することが多い（死ぬこともある）。でも、-j nでnが大きいほど、個々のプロセスで実行するテストは少なくなるはずだから、これは不思議（当然、GCの頻度も下がるはずだし）。

では、なんで死ぬのかと言えば、やはりスレッドの存在としか思えない。

で、以前作ったGITのやつを引っ張り出して来たら、ほぼ死ななくなったようだけど、イベントの処理エラーテストに引っ掛かる。理解不能なところに入り込んでしまった。

さてではどうしようかなぁとか。

_ C#でうまく書けなかったプログラム

ちょっとした状態を持つフィルタ処理があって、Javaだったら次のように書くところだ。

interface Filter {
    Filter filtrate(string, Writer wtr);
}
static Filter state1 = new StateA();
static Filter state2 = new StateB();
...
Filter filter = state1;
for (;;) {
    String s = ifile.readLine();
    if (s == null) {
        break;
    }
    filter = filter.filtrate(s, wtr);
}
...
wtr.close();

上でフィルタは受け取った行を処理し、次の状態を判断してそれを返す。

で、C#で作るのだから、クラスみたいな上っ面はいらなくて、多分デリゲートというかラムダでどうにかなるんじゃないかと思った。

で、まずは、上のfiltrate相当のメソッドを定義してみて

Func<string, TextWriter

まで書いてはたと気づく。このデリゲートが返すのは、第一パラメータにstring、第2パラメータにTextWriterを取るデリゲートだ。ということは、

Func<string, TextWriter, Func<string, TextWriter, Func<string...

書けない。

というわけで、interfaceというか、Classのような上っ面が必要なのかなぁと、Javaで書くのと同じようにinterfaceとclassで実装したのであった。

_ win32oleとparallel.rb

どうにも良くわからないので、テストを最小構成にしていったら、びっくり。

-vの有無でハングしているのだった。こりゃわからないはずだ。

というところまで。

もちろん、クロススレッドRelease呼び出しは原因の1つではある。

と思ったら、-vが無くても止まるときは止まるから関係ないのか。（でも、Variantを作るだけのOLE2.DLLしか呼ばないテストを同時に流すだけでも止まるときは止まるんだよなぁ）

追記:ちょっと思いついたが、スレッドでCoUninitialize呼んでなくて、あるいは呼んだためにそのスレッドが終了しないとかかも。

_ 記録

さて、いろいろな面倒事があるので、きれいさっぱり勤め先を休んで東京国際展示場に向かう。ひさびさのスーツである。足元はリーガル（でもゴム底の比較的歩きやすいやつ）。

というのはとあるコンソーシアムの関係でマイクロソフトのブースで説明員の役回り当番だからだ。

で、13:30からブースに立って、まあ直接商売のことになるわけではないので、興味を持ったような人に適当に説明したりしながら、早く終わらないかなぁ、おれは長いこと立ってると立ちくらみしたりしていやなんだよなぁと14:30頃のことだった。

ぐらりと目の前が揺れた感じがしたので、あーあ、立ちくらみ来たから裏でさぼるかと思って、だが良く見ると揺れているのはおれの脳みそではなく、全体のようだ。

で、横にいる人にこれ地震だよねぇ？ とか訊いたりしていたら、本格的に来ましたよ。

おれは、天井の照明が落ちてくるんじゃないかなぁ、その場合、矢倉の近くのほうがむしろ安全かなぁとか考えていたのだが、段々そんなおっとりがたなで構えていられない様相を呈してきた。が、壁際のほうはむしろいい加減なベニアの展示ブースとかがあって、そちらもまずそうだし、さてどこが一番安全だろうかとか考えながらしばらく過ごす。

ここで、エプソンの矢倉がまったくたわみも揺れもしないのに驚く（これでおれの中でエプソン株が急上昇した）。

でも、まあ、揺れが止まって、と思ったら、もっとすごいの来た。そこで外へ一回避難すると、お台場のほうから黒煙が立ち昇っているのが見える。一体何が起きているんだ？

その後会場でアナウンスが始まり、りんかい線とゆりかもめが止まったと言う。で、展示もここで終了。エプソンの知り合いが暗い顔をしてやって来て、今日、これでトラックとか出なかったら撤収できないし（本来長野へ引き上げるはずの）おれはどうなるんだろう……とか言っている。でもこいつは弱音をぴーぴー吐きながら着実にかっちりきっちり片を付ける大した技術者だってことは知っているから、例によって弱音を吐きながらもどうにかするんだろうなぁとか思いながら適当に大変だねぇとか合わせるわけだが、実はおれも大変だ。どうやって帰ればいいんだろう？

何しろ、りんかい線もゆりかもめも止まっているんだから、島へ取り残されたも同然だ。

地震で止まったのだから、そりゃ線路の安全も高架の安全も関係ない水上バスだよなぁと考えて波止場へ向かうと早くも長蛇の列。しかも、運航停止と出ている。バカじゃないか（と、その時点では大津波が襲っていることを全く知らない）と文句を垂れながらバスのほうへ向かうが、ここは信じがたい長蛇の列だ。

では、諸君徒歩だ。

で、頭の中で道を考えるのだが、地震のすごいのが来たのだから、レインボーブリッジは封鎖されているかも知れないかも、という疑念が湧く。もしそうなら、まっすぐ有明から銀座を目指すのが無難だ。銀座に出れば銀座線もあれば山手線もあるから普通に帰れるだろう。

かくして、有明へ向かう。

アリーナを左に見ながらテニスの駅を越えて、ひたすら銀座へ向かうのだが、一本道の上、まわりを同じく黙々と歩く人がいるから道を間違える心配もない。

かくして、築地へ着いた。

途中、もち屋の前を通ったらクリーム大福がうまそうだったので立ち寄ってお土産に購入。店のおばさんが会員カード作るか？ と訊くからいらないと答える。すると、なんかすごい地震だったようだけど外はどうなっている？ と訊かれる。おれも良くわからんが、りんかい線とか止まっているから有明から歩いてきたんだと答えると、どこへ行くんだ？ と畳み掛けてくる。それで銀座へ行って電車へ乗るつもりと答えたら、地下鉄は止まっているみたいだよ、ってのは赤坂から歩いてきたって人がさっき来たとか教えてくれる。うーむ、ならば山手線だよなぁとか思いながら外へ出る。

確かに、勝どき橋あたりで大江戸線の入り口に人が溜まっていたのは止まっているからか、と納得する。ってことは東銀座もなしだよな。

で、さらに歩いて服部セイコーの交差点へ来ると、交番から大きな声でアナウンス。JRは止まっているよ！

えー、JRも止まっているのか。

さすがに疲れたので、おれは電車に乗りたかったのだが。

で、シャンテのあたりを通ると、早々と店じまいしているところがちらほら。

（で、この後、桜田門経由国会議事堂前－永田町－赤坂見附－青山と進むのだが、赤坂見附を越えたところで17:30くらいになっていたのか、帰宅者の大群に飲み込まれてしまうのであった。

_ 今日の被害

Kバレエの夏の夜の夢・ピータラビットが14日に延期。

残念ではあるけど、その程度の被害ならあきらめるしかないな。

_ 今日の被害

Kバレエの公演は結局中止となった。しかも振替のロメオとジュリエットは既に買ってしまっているわけで、払い戻しを落ち着いたらする。残念。

_ 今日の被害

ガーン！ フィレンツェ歌劇場が帰伊しちゃったよ。

ガリバルディの150年をせっかく祝ってやろうと思ったのに。

レクイエムなんてちょうど時宜を得ていたのになぁ。

_ 思わぬところでエラーになるとは

rubyでtest-allするとWEBrickのテストが引っ掛かる。

当然、WEBrickに何か良からぬことが起きていると考える。

そこで、nmake -TEST="-v webrick" test-all とかやって、WEBrickだけテストしてみる。

すべてがうまく流れ去る。

はて？

で、フェイルになっているのはエラーのせいだと気付く。エラーになっていて500が返るから200を想定しているテストがフェイルする。

で、エラーについてはバックトレースがあるので眺める。するとcgi_runner.rbというのが環境変数の詰め替えをしているところだと気付く。

なんでそんなものがエラーになるのだろう？ と、そこはスルーする。

それで深みにはまる。

スルーしなければ、今まで環境変数に入っていたものの詰め替えなのだから、変えているものだけが理由だと気付けるはずだ。

で、変えているのはtest_cgi.rbの中でRUBYLIBに対して行っているやつだとわかるはずだ。

が、そこをスルーしてしまったばかりに30分くらいprintfを入れたり無駄なことをしてしまう。

というわけで、デバッグってのはなかなかおもしろい。

_ アプリケーション死すともプロセス死せず

CPUが早くなって、しかもコア数が増えて同時実行可能なプロセス数が増えると、考えもしないタイミングが生まれる。

GetExitCodeProcess APIは、"If the process has terminated and the function succeeds, the termination status returned may be one of the following"だから、プロセスは現在完了形でターミネートしていて、呼び出しに成功したらステータスが返る。ということはプロセスはターミネートしているはずだ。

でも、どうもそうではない。というのは、ロジカルに特定のプロセスがCDしているディレクトリが、そのプロセスがターミネートした（追記：と、上のようにGetExitCodeProcess呼び出しの結果から判断した）にもかかわらずアクセス中のプロセスが存在して消せないという状態になることがあるからだ。

ExitProcess APIの説明を読むと、Exiting a process causes the following:として、

1. プロセスがオープンしたすべてのオブジェクトハンドルをクローズする

2. 呼び出したスレッド意外のすべてのプロセス内のスレッドの実行がターミネートする。 DLLのDLL_PROCESS_DETACHを呼び出す。

3. プロセスオブジェクトはシグナル状態になる。

4. すべてのスレッドがシグナル状態になる。

5. プロセス状態はSTILL_ACTIVEから終了値に変わる

と書いてあるから、プロセスハンドルがシグナルになるのは3でGetExitCodeProcess呼び出しより前に思える。だが、この数字は単なるドットの意味しかないとしたらどうだろうか？

Terminating a Processの章には次の記述がある。

"When a process terminates, its termination status changes from STILL_ACTIVE to the exit code of the process.

When a process terminates, the state of the process object becomes signaled, releasing any threads that had been waiting for the process to terminate. For more about synchronization, see Synchronizing Execution of Multiple Threads."

この順で処理されるとしたら、まず終了ステータスがSTILL_ACTIVEから退出コードに変更される。次に、プロセスオブジェクトがシグナル状態になる。

CPUが高速で、同時に実行できるプロセスが2つ以上あれば、上記の文章がその順序に発生するとしたら、ちょうど改行の位置でGetExitCodeProcessを呼び出すことが可能だ。

これは結構おそろしい。つまり、他のプロセス（や他のスレッド）に対して自分の状態変化を複数の状態変数を通して教える場合、その順序は厳密に文書化しなければならないし（したがって、MSDNのTerminating a Process（多分正しい順序)と、ExitProcess（多分正しくない順序）のように矛盾があってはならない）、逆に教えられる側は、その順序を守るか、さもなければすべての状態変数の確認をしなければならないということだ。

大変な時代に突入したものだ。

追記：コメント欄のNyaRuRuさんの他のプロセスの介入の可能性という指摘は確かにあるので(今回の僕のケースだとちょっと考えにくいけど)、可能性いろいろということで。（すると結論は、ソースが読めないOSでは、微妙なタイミングの処理を正しく記述することは不可能というような方向になったりするのかも知れない）

_ 買ったマンガ、買えなかったマンガ

王狩の発売日だというのでリブロに行ったが置いてなかった。ていうか、リブロはこの作家のマンガを置いていたためしがないような気がする（ZOOKEEPERも一貫して置いてなかったし）。というわけで、アマゾンかな（が、マンガ1冊を注文するのもおれは気が引けるので欲しいものが溜まるまで待ち状態）。

王狩(2) (イブニングKC)(青木 幸子)

（書影を見て、なんでこいつが表紙なのか？ とちょっと驚き）

一方へうげものは普通に平積みなので購入。ついに太閤どんは逝ってしまったか。どうにも徳川よりも石田三成に肩入れして読むせいか、もの悲しさがたまらんなぁ（というか、徳川は嫌いだし）。

へうげもの(12) (モーニング KC)(山田 芳裕)

_ スピーチではなく唄

英国王のスピーチを観ようと、子供と早く家を出て、ル・シネマで昼過ぎのチケットを買って、マンガを買ったり飯食ったりした昼下がり、あらためてチケットを見てびっくり。10:なんとかとかスタンプが押してある。発券時刻じゃないの？ とか子供が楽天的なことを言うが、そんなこたないなぁ。

で、窓口に行って、確認しなかったこっちも悪いけど、とか言ったら、あっさりと非を認めてくれて、でも今回は……と言われるまでもなくロビーは大混雑だし満員印も出ている。

で、子供がこっちも観るつもりだとか言うので、おれはまったく興味を惹かれなかったのだが、まあそういうのもありかもと、イシグロカズオのわたしを離さないでのほうに変えてもらって観た。

うーん、なんとおそるべきメロドラマ。

物語の複雑さ巧妙さは驚くべきで、いくようにでも解釈できる多層性を持つ。

が、映画としての退屈さもまた驚くべきで、音はうるさい、目線はしつこい、語りはくどくど、ゴダールなら20分の中編、ハワードホークスなら30秒のTVCMにしてしまえそうなひどい映画だ。

この映画監督がぐずなのは、主人公の女性を（おそらく観客の感情移入対象にしやすくするためだろうが）普通に生きている女性として描ききってしまったところだろう。唯一、外部の視線が入るのは海辺のカフェのシーンだけで、ここでは主人公も他の登場人物と同様の存在として描かれているが、それ以外ではすべて他の登場人物を外部から見る存在として作られている。それが、物語の構造を破壊してしまうだけの間違いとなり、その間違い（というか、間違っているのを承知で脚本と演出が作られているのは、観客の視線に合わせたいからだろう）を無理矢理つじつま合わせるために、くどい説明的なシーンと感情の流れを大げさに表現する音楽となって立ちあらわしているに違いない。

観ている間中で、退屈で退屈でいらいらするのなんのって（こういうのは作劇法の問題なので、気持ちよく睡眠に誘われるわけではなく、単にいらいらする。シュレンドルフやテリーギリアムのような超一流のふりをした108流監督に固有の現象だ。が、こっちの監督は108流までいかなくてせいぜい3流どまりなので不快感は実はないのだけど、シーンが本来持つべき緊張感の欠落はどうにもひどいものだ）。

と、映画としては最悪の代物に近いが、物語のうまさはなかなかのものだ。

過去をあり得た過去として別のテクノロジーを被せる思弁的な意味でのSFになっている。

わたしを離さないで (ハヤカワepi文庫)(カズオ・イシグロ)

男主人公の演技は、ジャンピエールレオーを模範としたかのようで、そのために、この人たちはある種の欠落を抱えたしかし私でありあなたである人たちそのものに見える。（だが、主人公が異物となっているため、単にやぼったいだけに見える）

幸福の象徴であるべき馬の印象の弱さや、いやそれはちょっとと感じさせる絵画や、真に重要な逆転の瞬間の何も考えていないかのようなスルーっぷりとか、唐突であるべきところのだらだらに対してどうでも良いところのねちねちっぷり（とか、思い出しても映画になっていないあらばかり思い出されるが、結局は監督の力量の無さが、難しいところのまともな演出の放棄と音楽任せによって、気分で流しやすいところに時間を使うことになったのだろう）。

ただ、実質的には何の救いもない物語にもかかわらず、きちんと平安と魂の救済で終わるのは見事かな（が、そういう過酷な運命をありのままとして抱擁してしまう物語というのは美しくはあるけれど、あまり良い物語とは思えない）。英国王のスピーチのほうがやっぱり観たかったな（こっちは過酷な運命に立ち向かうわけじゃん）。

追記：単に、社会というくだらないものに出て行って今日の飯のために金を稼ぐというのは自分を殺すことだというある種の若者の観点と諦観を物語化したものだ（したがって、そこには若者の悩みや喜びや悲しみがある）とみなせば、そこそこのできの映画かも知れないなぁとも思う。その意味では卒業白書とかいちご白書なんかと同じような青春映画の傑作の列に並べることもできるかも知れない。が、その見方をさせるには、ジャンピエールレオー風の男主人公の造形は失敗じゃないかとも思う。いろいろ考えさせるところは悪くはない。

_ ネットワークフロー

アスキーの嘉平さんから『ネットワークフロー解析入門』をもらったのは良いが、なんのことだか良くわからないのでしばらく放置していたのを、読み始めたのが金曜の夜。だいたい読み終わって、しかも結構おもしろかったので紹介します。

まず、目の前にCatalystがあるなら読むべき、Catalyst（ではなくても良いが）それなりに複雑なネットワークがあって、それを管理したりメンテしたり問い合わせに答えたりするようなことをやっているのなら必携、といった本でした。（ということは、おれにはほとんど関係ないのだが、でもおもしろかった）

まずネットワークフローという言葉を知らなかったのだが、「フローとは、同じ送信元IPアドレスと送信先IPアドレス、送信元ポートと送信先ポート、IPプロトコルをすべて共有する一連のパケットである(P.27)」と定義されている。最初、そこを読んだときは、それが何の役に立つのか不思議だったが、元はCISCOのルータのタリーなわけで、そうやって管理しているからそれを出力する機能があるということなのだろう。で、そのままではそれほどは役に立たない（とは言え、異様なトラフィックの検出とかなら利用できるだろうし、ゲートウェイ向けや、ゲートウェイ発であればそれだけでもいろいろ調べられる）ので、いろいろツールがある、ということで、本書の最初の3章くらいはフローの意味とかツールの使い方、ちょっとだけIPプロトコルの解説、そしてフィルタリング方法からレポートのいろいろ、最後はPerlを使ったカスタマイズの方法と、gnuplotを使ったグラフの作り方。

なぜ、それがおもしろいのかと言えば、結局とんでもない量のフローからどのように意味ある情報を読みとるか、について書いてあるからだ。という点からは、なんでも良いから統計的な処理をしてみたいけど大量な情報が欲しいなぁと考えている人で、目の前にCISCOがあるか、スニファーポートを持つスィッチを使っていて余っているコンピュータがあれば、結構楽しめると思う。

というわけで、みんながみんな読んで意味があるとは思わないが（とは言え、IPの基礎的な部分をヘッダ部の実例を示して説明してあるので、そのあたりの知識を求めているのであれば最初の80ページくらいを読むだけでも結構役に立つと思う）、良い本でした。

ネットワークフロー解析入門 flow-toolsによるトラブルシューティング(Michael W. Lucas)

でも、もう少し、汎用的な（つまり誰にとっても役に立つ）本を読むのなら、こちらを勧めるけど。

ミニ実験でつかむパケット解析手法 ネットワーク原理の観察からトラブルシューティングまで(荒井 美千子)

追記：ああ、おれの書き方は間違っている。「ネットワークフロー」と書いているせいで、そういう単語に見えるけど、「ネットワーク」と「フロー」は切って読むべき（書くべき）。書名も「ネットワーク （についての） フロー解析入門』と読むべき。本文中でも引用が示すように、『フロー』という言葉を使っているし、1つのフローは、同一ソースアドレス/ポート、同一デスティネーションアドレス/ポートということからわかるように、まさにFlow（流れ）。