日々の破片

_ 9/1

厄災の日。

災厄、災害、厄災の違いと、それらを見届ける塩の柱。

_ 18世紀のどつき漫才

子供が妙にモーツァルトにはまっている、と思ったらフィガロの結婚にはまっているのだった。

帰宅すると、もう飛ぶまいぞ、この蝶々が、いつだって鳴り響いている(わけなくて、おれが知ってるフィガロはそこだけだ。というかレシタティーボばかりでうんざりなのだが、無限旋律万歳)。

モーツァルト:歌劇「フィガロの結婚」全曲(ジュリーニ(カルロ・マリア))

それにしても図書館で借りられるのはいいもんだ。おれは絶対に買わないからな。フィガロ買うなら別のボエムや別のリングを買う。それにしても司書のジュリーニ、モッフォという選択は絶妙。

で、モーツァルト以外のナニモのでもない音楽はともかく原作にも興味を持ったらしくえらく集中して読んでるなと思うまもなく、お前も読めと、渡された。

フィガロの結婚 (新訳・世界の古典シリーズ)(ピエール=オギュスタン・カロン ド・ボーマルシェ)

で、やたらとシュザンヌがフィガロをぺちぺち叩くのに感嘆する。というか、オペラでもパシパシ音がしてるのだった。

_ ボーマルシェ

フィガロの結婚は、実際のところ1/4は解説で、そこにはルイ王朝末期をさっそうと駆け抜けた劇作家にして天才時計職人(時計勝負とか)、政商(アメリカ独立影の最大功労者)にして謎の未亡人キラー(生涯二回)、怪異なことまるで香水の主人公だがそれとは違って見た目も抜群な伊達男、でも歴史の教科書には名前がきざまれていないボーマルシェという男について語ってある。

これがすごくおもしろい。

フィガロの結婚が潤色されたオペラの脚本と異なり、自由平等友愛ディドロ万歳(直後にボーマルシェはディドロ全集を出版するので広告説も)で、しかし軽妙洒脱の粋で、つまり滅法おもしろく、ボーマルシェに朗読聴かされたルイ16世が怒ることも出来ずに苦虫噛み潰さざるを得なかったのもむべなるかな。

と、面白さ倍増本だった。子供に感謝。しかし考えてみると、こんな好色本を読む年齢になったんだな。

フィガロの結婚 (新訳・世界の古典シリーズ)(ピエール=オギュスタン・カロン ド・ボーマルシェ)

_ 角が増えれば円くなる

子供が夏休みの宿題とかで山ほど新聞を買い込んで読み比べている。

おれの頃は高校でやったから、最近の学校のほうが進みが早いみたいだ。

時々、まとめサイトとか読んでいて不思議なのは、どうしてかくも一方向な主張だけで構成できるのかという点だ。

おれのコモンセンスでは、それはあしき(携帯の辞書だな)魂胆による意図的な操作の発現だ(間違った善意の場合もあるはず)。

つまり歴史には無数の真実と、不可知なたった一つの事実だけしかない。

それを共通の認識とした上で議論や論難があり得る。が、その認識の存在がうかがえないようにしか読めない。

したがってその基盤生成は現在の教育からは失われたのだろうなぁ、と想像していた。

が、子供の宿題をみるとそんなこた、なさそうだ。

ということは、より巧妙にあしき魂胆を隠蔽する技術が開発されたという事だ、

いい世の中だ。

新聞記事が「わかる」技術 (講談社現代新書)(北村 肇)

(これが副読本に指定されていた。いかにも毎日らしいおおらかな中庸ぶりで結構気持ちいい)

_ Snow Leopard

RJBがコンパイルできないとかのバグ報告が来たので、いよいよ買うことにする。ついでに子供や妻の分も買うかということでファミリーパック。が、在庫切れなのか……でも、わざわざ買いに出かけるのもおっくうなのでアマゾンで予約（ということになるのかな）。

Mac OS X 10.6 Snow Leopard ファミリーパック(-)

在庫切れの理由がDVDのプレスし直しとかだといいんだけど。

(ギャ！ 一日違いでコノザマくん――と思ったらちゃんと配送準備に入ってた)

ところで、子供がWordが使いたいとか言うんで（宿題提出用。最悪テキストや手書きでも良いと書いてあるが、ワープロはワープロだ）、OOoを入れてやったが（OSX用のOfficeのライセンスは妻マシン分しかないってのもある）、原稿用紙みたいな設定、つまり文字数×文字数ってのはどこでやるのだろうか（追記：書式-ページ-行数と文字数）。メニューを探しても見つからないし、イルカのような役に立つ機構は備えていないようだし、まるでWordでクラス名などの先頭の大文字が勝手に小文字になってしまうバグや日本語の文章なのにカーニングをしでかすバグの対策するみたいに時間をかけていろいろいじったが、全然わからない。

自分でコードをいじらなきゃならないとしたら、さすがに、Wordを買うほうが安いし自由に利用できるので、2度目があったらWordを買ってやろうかどうか、それより先にOffice LiveがOSXでも利用できたらいいなぁとか考える。

というわけで、とりあえずおれさまマシンを貸してWindows用Officeを使わせてやったり。

_ volatile、マルチスレッド、キャッシュコヒーレンス

The Art of Multiprocessor Programmingだが、1章と2章を何度も読み返しながら、なんでこんなに難しいんだろうか？ と情けなくもあり、おもしろくもあり。わかるということと理解し切るということの相違だなぁ。

で、付録のハードウェアの基礎のところに、TASLockとTTASLockというのが出ていて、それを真似た実装をしてみていろいろ試してみると、どうも書いてあることとは結果が異なる。

TASLockは、TestAndSetなLockで、TTASLockは、Test-TestAndLockで、書いてあることを読むと、意味は同じ、コード量はTTASLockが多く、しかしパフォーマンスはTTASLockのほうが良い、ということになっている。

Javaで実装すると以下のようなコードになる（が、もちろん、現実には異なるコードとなるため、結果が異なるのだが、それに気づくまでえらく試行が必要だったというのが結論となる）。

import java.util.concurrent.atomic.AtomicBoolean;
public class LockBench {
    static AtomicBoolean abo = new AtomicBoolean();
    static void tasLock() {
        while (!abo.compareAndSet(false, true)) {} // tas
    }
    static void ttasLock() {
        while (true) {
            while (abo.get()) {} // test
            if (abo.compareAndSet(false, true)) { // tas
                return;
            }
        }
    }
    static void unlock() {
        abo.set(false);
    }
    static void runThreads(Thread[] ts) throws Exception {
        long start = System.currentTimeMillis();
        for (Thread t : ts) {
            t.start();
        }
        for (Thread t : ts) {
            t.join();
        }
        System.out.println(ts.length + " threads run in " + (System.currentTimeMillis() - start)
                           + " msecs");
        java.util.Arrays.fill(ts, null);
        System.gc();
    }
    interface Lock {
        void lock();
    }
    static class TestThread extends Thread {
        Lock lock;
        TestThread(Lock lk) {
            lock = lk;
        }
        public void run() {
            // (A) 初期化コード
            int x = 0;
            for (int i = 0; i < 1000000; i++) {
                lock.lock();
                // (B)何かおもしろいことを行う
                unlock();
            }
            // (c) 退出コード
        }
    }
    static void bench(int nthreads) throws Exception {
        Thread[] ts = new Thread[nthreads];
        for (int i = 0; i < nthreads; i++) {
            ts[i] = new TestThread(new Lock() {
                    public void lock() {
                        tasLock();
                    }
                });
        }
        runThreads(ts);  // TAS
        for (int i = 0; i < nthreads; i++) {
            ts[i] = new TestThread(new Lock() {
                    public void lock() {
                        ttasLock();
                    }
                });
        }
        runThreads(ts);  // TTAS
    }
    public static void main(String[] args) throws Exception {
        int nthreads = 4;
        if (args.length > 0) {
            nthreads = Integer.parseInt(args[0]);
        }
        for (int i = 0; i < 4; i++) {
            bench(nthreads);
        }
    }
}

上の、何もおもしろいことを行わない(A〜C)が空の場合、以下の結果を得た。NetBurst Xeon 2.8GHzのSMPでHyperThreadありの見かけ4CPUマシン。

c:\home\arton\test>java -cp . LockBench 1 2>nul:
1 threads run in 141 msecs
1 threads run in 131 msecs
1 threads run in 118 msecs
1 threads run in 113 msecs
1 threads run in 118 msecs
1 threads run in 116 msecs
1 threads run in 117 msecs
1 threads run in 113 msecs
--- 1スレッドだともしかするとTTASが速い？
c:\home\arton\test>java -cp . LockBench 4 2>nul:
4 threads run in 936 msecs
4 threads run in 944 msecs
4 threads run in 954 msecs
4 threads run in 967 msecs
4 threads run in 761 msecs
4 threads run in 962 msecs
4 threads run in 931 msecs
4 threads run in 972 msecs
--- 4スレッドだとTASのほうが速い？ （というか、1スレッドで4回回すほうが速いと思う）
c:\home\arton\test>java -cp . LockBench 8 2>nul:
8 threads run in 3924 msecs
8 threads run in 3596 msecs
8 threads run in 3671 msecs
8 threads run in 3815 msecs
8 threads run in 2465 msecs
8 threads run in 3601 msecs
8 threads run in 2924 msecs
8 threads run in 3330 msecs
--- 8スレッドだとTASのほうが速い？
c:\home\arton\test>java -cp . LockBench 16 2>nul:
16 threads run in 11665 msecs
16 threads run in 10544 msecs
16 threads run in 10480 msecs
16 threads run in 9087 msecs
16 threads run in 10105 msecs
16 threads run in 10281 msecs
16 threads run in 10493 msecs
16 threads run in 9325 msecs
--- 16スレッドだとTTASのほうが速い？

しかし、書かれている説明を読むと、この結果（ほとんどの場合TASが速く、TTASが逆転したとしても、顕著な差とはならない）は論理的に納得できない。

TASLockは、getAndSet(true)(引用者注- concurrentライブラリが提供するcompareAndSetと等しい機能を持つ仮想的なメソッド)をロックに適用するたびに相互接続を通じてメッセージを送信し、大量のトラフィックを引き起こす。SMPアーキテクチャでは、このトラフィックによって相互接続が飽和状態となり、すべてのスレッドを遅延させる。（中略）対照的に、ロックがビジー状態である間、TTASLockはスピンし、ロックのローカルキャッシュのコピーを読みとる。このため、相互接続トラフィックを生成せず、パフォーマンスに優れている。

説得的だ。

何が問題かは以下を試してわかった。

static volatile int total; // クラス変数として追加
static int dummy(int x) {
    return x * 2 + 1; // 適当な内容
}
(A) int x = 0;
(B) total += dummy(x++);
(C) System.err.println("total=" + total);

実行した結果は以下となった。

c:\home\arton\test>java -cp . LockBench 1 2>nul:
1 threads run in 206 msecs
1 threads run in 200 msecs
1 threads run in 181 msecs
1 threads run in 207 msecs
1 threads run in 180 msecs
1 threads run in 208 msecs
1 threads run in 180 msecs
1 threads run in 207 msecs
--- 元の結果より倍以上遅い。
c:\home\arton\test>java -cp . LockBench 4 2>nul:
4 threads run in 2406 msecs
4 threads run in 2754 msecs
4 threads run in 2342 msecs
4 threads run in 2672 msecs
4 threads run in 2120 msecs
4 threads run in 2723 msecs
4 threads run in 2306 msecs
4 threads run in 2744 msecs
--- 倍以上遅い。
c:\home\arton\test>java -cp . LockBench 8 2>nul:
8 threads run in 7621 msecs
8 threads run in 8384 msecs
8 threads run in 6943 msecs
8 threads run in 9046 msecs
8 threads run in 6904 msecs
8 threads run in 8987 msecs
8 threads run in 5915 msecs
8 threads run in 9320 msecs

付け加えた処理にはSystem.err.printlnというIO呼び出しがあるが、しかしこれは100万回ループの外なので大きな影響はない。したがって、これだけ遅くなる原因は、volatileなtotalへの代入にあると推測できる。

以下のように変えてみる。

static int dummy(int x) {
    return x * 2 + 1; // 適当な内容
}
(A) int x = 0;
(B) x += dummy(x++); // 多分、畳まれないとは思う
(C) System.err.println("total=" + x);

結果は以下となった。

c:\home\arton\test>java -cp . LockBench 8 2>nul:
8 threads run in 3600 msecs
8 threads run in 2548 msecs
8 threads run in 3083 msecs
8 threads run in 2835 msecs
8 threads run in 3974 msecs
8 threads run in 2866 msecs
8 threads run in 2836 msecs
8 threads run in 3057 msecs

そこで気づいた。

元の説明で、TASLockよりTTASLockが高速なのは、最初のTestで読みとる値をキャッシュとしているからだ。だが、AtomicBooleanのAPIとして考えた場合、getメソッドがキャッシュを返すはずがない。

確認してみる。

(jdk 1.6.0_16 AtomicBoolean.java)
    ……
    private volatile int value;
    ……
    public final boolean get() {
        return value != 0;
    }
    ……

なるほど。

いずれにしても、Javaの仕様からは、もしvolatileなしでvalueを宣言していたとしたら、メインメモリからの読み直しすら必要ない。最悪の場合、永遠に（JVM上の）キャッシュの読みとりになる可能性もあるわけで、この実装以外にはあり得ない話ではある。

それにしてもvolatile修飾子1つでこれだけパフォーマンスに影響を与えるというのは、頭ではわかっているようでもやってみないとわからないものだった。

The Art of Multiprocessor Programming 並行プログラミングの原理から実践まで(Maurice Herlihy)

_ ソ連の数学

ikegamiさん曰く、補助線を見つけられるかどうかという教え方ではない幾何の本。序文を読むと高校1年あたりを対象としているらしい。

数学新書〈第19〉幾何の帰納法 (1962年)(-)

で、最初の4ページほどを読んだらおもしろかった(=読む気にさせる)が、さすがに入手できるもんじゃないね。

最初は数列の最初の幾つかから演繹して定理を見つける方法が間違っていた例を挙げる（さっそくまったく覚えてないけどフェルマー素数とか）。

で、最小の数で成立することと任意のnとn+1の間で成立することの2つの証明で示すことがいかに重要であるかの解説が続き、そこで一区切り。

という内容を置いておいたとして、これがソ連の数学教育の本で、翻訳されたのが1962年というようなあたりの社会環境も同程度におれにはおもしろく思える。

というわけで、ikegamiさんに絶望先生のハードカバー15巻を贈る会に飛び入り参加したおかげで、謎のフリーライターがハチ公前でパフォーマンスを繰り広げるさまを堪能したり（お疲れ様でした。髪の毛が取れたのには仰天したし、背広の背中の汗じみの真摯さに地味に感動した。やるならあそこまでやらなきゃ嘘だな）、とりとめもなく楽しいひと時を過ごせました。どうもありがとう。というか@m0h1canさんのヘアヌード猫Tシャツにもいささかびびったけど。

_ providとprovided

中田さんのヒントで理屈はわかったが、(パッチしてみて)providedを呼んでもfalseが返る理由がわからん。

……Qfalseかな? 帰ったらそこを先ず確認。

_ 今日のダウンロード購入

iTSで買った。

(WHAT IS THE)LOVE&POP?(Base Ball Bear)

明日、iPodで電車の中で聴く予定。

_ ASR-1.8.7.11

Exerb 5.0.0を同梱。

ASR置き場

昨日不思議だった件は、なんのことはなく、一部のDLLが作られていなくて古いDLLとリンクしてたからだった。不思議に思ってprintfデバッグしようと入れた出力が出ないので判明。printf行はそのまま削除して結局使わなかったりしたが、やはり最後にものを言うデバッグ方法ではある。

_ 今日のバグ

クェリストリングのような入力を考える。

「a=b,c=d」とか、もちろん「a=b&c=d&e=f」でも良い。

時々空の値が入ることがある。たとえば「a=b&c=&e=f」とか。

それに対して

String input = "a=b&c=d&e=f";
...
String[] pairs = input.split("&");
for (String pair : pairs) {
    String[] kv = pair.split("=");
    System.out.println("key=" + kv[0] + ", value=" + kv[1]);
}

_ iPod classic用首つりケース

家でiPod classicを使うようになったのだが、Tシャツでふらふらするには全く向いていないのでどうにかしたいと思っていた。ズボンの尻ポケット向きじゃないし、手で持つには繊細過ぎるというか気になる。

既に音楽は50G（しかも64Kエンコードしたmp3とかも山ほどあったりするので曲数は想像よりも多い）を遥かに超えているので、ナノやらシャッフルやらでは役には立たないのだ。

で、アマゾンでいろいろ眺めてもらちがあかない。首から下げるのがおそらく必須条件なわけだが、革のやつでも首から下げられるかわからないしそれなりの値段もするし、かといって……

というか、classicは売れてないんだな、と良くわかった。マーケットが狭いんだ。そうに違いない。

で、少し視野を広げたら30G iPod 5G用というのに、送料より安いのがあるのに目が付いた。

アマゾン評を読むと、紐を通す穴が空いていないから星1つとか、楊枝で簡単に空くから星5つだの、ぶかっこうだけど実用性があるから星3つとか、いろいろだ。

だが、首から下げられることは間違いなさそうだし、5G 30G（5GはgenerationのGか？）と120G classicはほぼ同じサイズだから問題もなさそうだ、で、買った。今日、届いた。

確かにぶかっこうだし（紐が変な通し方しなければならないし、紐がまさに紐以外の何物でもない形状だし）、ホイールを覆うシリコン部は薄くなっているが、感度は悪いは（AからZへ行くまで何度か滑らなくなるのでやり直しが必要になったりするし）、確かにケチもつけたくなる。

でも送料入れても600円だしな。

それに、一度聴く曲決めれば40分（たとえばシェーンベルクが後期ロマン派だったころのやつらとか）とか180分とか（オペラ）はいじらないわけで、結局、良い買い物だったようだ、と思う。

Sumajin Loop G5 30G Clear iPod 5G 30GB シリコンケース/スクリーンフィルム/ストラップ付属 クリア SUMLPG530CL(-)

で、なぜかずーっと、ウィーン時代の若きシェーンベルクを再評価している。

なんて素晴らしい作家なんだろうか。

Gurrelieder(Arnold Schoenberg)

小澤がボストンを振った、当然のように柔和で自然な音に、黒い山鳩ジェシーノーマンのびっくりするくらい美しいトーヴェ。だが、演奏よりも曲そのものだ。

新ウィーン楽派管弦楽曲集(ベルリン・フィルハーモニー管弦楽団)

最良のカラヤンとベルリンでもある、ペレアスとメリザンド。ゴローの剣一閃のおそろしさ。というよりも最初のメロディーの美しさだなぁ。

いや、違う。激しく燃え上がった（ベルリンは全く乱れない）後のレガート(タラーラ,ラララ,ラーラッの部分)の美しさはカラヤンならではなのだな。というか、このペレアスでカラヤンってのは確かにすごい指揮者なのだな、と納得したのだった。今聴いても納得する。天国みたいだ。スパークスとは違う意味で。

Number 1 In Heaven(Sparks)

でも、今はそういう時期ではない。

Pelleas Und Melisande / Variations for Orchestra(Chicago Symphony Orchestra)

で、こちらは理知的で明確かというとそんなことはなく、ブーレーズって本当に才能の固まりなんだなぁと息をのむ美しさ。シカゴはショルティのイメージで荒々しい感じのように思っていたけど、そんなこたない。

アメリカのオーケストラって、5〜60年代の指揮者のせいか、ラテン系な感じがするなぁとか思いだしたりしたり。

で、最後に6重装曲版の清められた夜を聴く。浄められた夜かも。

Verklarte Nacht(Schoenberg)

これは不思議な物語を持つ不思議な曲で、これほど美しい曲で、しかも幻想的なものは多くはないと思う。

月に照らされた森の細い道を若い女と男が歩いている。女は男に過去を話す。男はそれを許し、浄められた夜となる。

ばかみたいな物語に対し、足音のようなフレーズや月の光のような響き、夜の森の音色を配して、確かに音楽劇のようであり、しかし抽象的なドイツのベートーヴェン以来のスタイルのようであり、変な音楽だ。

オーケストラ版は、厚みのせいで、音楽劇の印象が強まる。映画音楽だな。フィルム無しの。

それに対して6重装曲版は声部がはっきり分かれているので、抽象度が高い。が、それでも描写的で、しかもメロディーがあり、響きがあり、ホ音かな、それにしてもシェーンベルクって何を考えていたんだろうか。

そうだ、思い出した。顔つきとか国の変え方とか、その後への影響とか、まるでジョンフォンノイマンみたいだな、と思うのだった。フォンって変だな。ノイマンのジョンさんか。

_ Ruby拡張ライブラリと例外

Rjbのバグ報告を見て、これまで無視してきたというよりも意識していなかった、拡張ライブラリで守るべき処理が1つ判明した。

Sinatraがなんでそんなものを取り出してきたかは知らないけれど、拡張ライブラリで例外を握る場合は、$!をクリーンアップしなければならない。

悪い例）

    int sstat;
    VALUE v = rb_protect(real_funcall, (VALUE)argv, &sstat);
    if (sstat)
    {
        return Qfalse;
    }

これが悪いのは、rb_protectで第3引数が0でない、つまり呼び出し先で発生した例外を無視して、そのままだということだ。

もっとも、スクリプトと拡張ライブラリの合わせ技はあり得るとは思うが。

def foo
  unless native_call
    raise FooError.new($!.message)
  end
end

そうではなくて、拡張ライブラリが提供する関数をそのままユーザに与えるならば、

    int sstat;
    VALUE v = rb_protect(real_funcall, (VALUE)argv, &sstat);
    if (sstat)
    {
        rb_set_errinfo(Qnil);   // cleanup
        return Qfalse;
    }

とすべきで、そうでないと、呼び出し側が$!を参照した場合に握り潰した例外を穿り出せるからだ(痛くもない腹が探られる状態なのに実際に悪事が出てくるというか)。

が、rb_set_errinfoが未定義の1.8の場合の書き方はどうすべきか？

ruby_errinfo = Qnil;

と、したけれど、むしろ1,8ならば#define rb_set_errinfo(x) ruby_errinfo = (x)としておいて、コードは同じにしといたほうが良かったかも。

_ ://0, //0, ://

どうもサイトがなくなってしまったようだが、ADxMenu.jsというのを仕事で利用している。

で、httpsな環境で利用して、かつそれがhttpなバックエンドに対してリバースプロクシでつながっていると、保護された項目と保護されていない項目の混在ダイアログの原因となっていた。

いろいろ調べるとADxMenuは次のコード

document.write("<script id=__ie_onload defer src=javascript:void(0)><?/script>");

を利用して、body.onloadと同じようなタイミングで実行するスクリプトを制御しているわけだが、それが引っかかっているのだった。

「mootoolsでIE+SSLではまった」というページでmootoolsのコードが出ているが、大体、これと同じ問題だ。

もっともADxMenuは問題点を認識していて、document.location.protocolがhttpsであればsrc="//0"に変えようとしている。それは良いのだが、リバースプロクシのほうはhttpにしていたので、document.locaion.protocolはhttpだったのであった。そこで、常にsrc="//0"にするように変えたのだが、疑問がたくさん。

まず、ADxMenuが利用している"//0"というURLだが、これは何なのだろう? 同じプロトコルの0ってことは、https://0.0.0.0ということかな？

他にも探すと"://0"を利用（lightboxがSSLで警告）とか"//:"を利用（mt.jsが原因でSSL接続にならない場合）などのバリエーションがある。なんか、//0の書き間違えのような気もするが、うまく動いているのだろうから構わないとは思うが気になる。IEはデフォルトルートを無視という（良く知られた）仕様があるのかなぁ。

とりあえず、良くわからないまま、ADxMenuの元のコードに合わせて"//0"としてうまく動いている（本当にうまくかどうかがわからないので、ここに書いているのだが）ので、放置しているのではあるが、やはり気になる。

たとえば、このおかしなURIが原因で、IEが100ミリ秒ほど余分なurlmon問い合わせとかしているのなら、それはやめさせたいわけだし。

about:blankがhttpsとそれ以外の混在チェックに引っかからないのは確認している。ポップアップやIFrameの開始時のURLに利用して問題ないからだ。その意味では、about:blankを使うほうが良いようにも思うのだが(追記：とは言い切れない。たとえばポップアップであれば、submitの結果のスクリプト内でabout:blankをポップアップすることは可能だったがスクリプトだけで自動的にポップアップさせようとするとブロックされたのを思い出した（けど、これはURLは関係ないね）。将来的な変更に耐えうる一番良い方法は、最初にリンクした人のように小さなHTMLを用意してそれを呼び出すことだと思える)、わざわざADxMenuの作者がhttpsなら//0と書いているくらいなのだから、何か正当な意味があるかも知れず、しかし、「//0」は検索語ではない（やり方知らないだけかも）ので出所も見つからず、ちょっと気持ち悪い感じ。

_ はじめてのオペラ

ネトレプコの椿姫が届いたので観て聴いた。2回くらい。子供はもっと観ているが、それは別の話。

ヴェルディ:歌劇《椿姫》 [DVD](ネトレプコ(アンナ))

(買うならこっちだが)

で、アマゾン評がおもしろい。廉価版が出る前のほうだ。

ヴェルディ 歌劇《椿姫》全曲 [DVD](ネトレプコ(アンナ))

(今でもこちらも売れているようだが、それが情弱というものによるためか、それとも特典ブックレットが実は付いているというような実利的なものなのかはわからない。同じものだと思うけどな）

おれがオペラを観始めたのは遠く1970年代にさかのぼる。

時代はヴィスコンティの支配下にあり、ゼフィレッリがわがもの顔に君臨し、ドミンゴがコスプレをしまくっている。

おれは、このてのものものしさが大嫌いだった。映画は別かも知れないが、それでも実際のところヴィスコンティとかこれっぽちも好きじゃない。なんでこの時代にあって、歴史そのものでもないのに、コスプレ観なきゃならないんだ？

（いや、でもこないだ新国立劇場で観たアイーダは逆に新鮮過ぎて素直に度肝を抜かれたから、今はそれほどわだかまりは無いらしい）

レコード芸術の写真で眺めたシェローのリングをどれだけ観たかったことか。あるいはヴィンラントだかヴォルフガングだか忘れたが金がないので必然的にシンプルになりましたなリングですら、コスプレオペラよりもはるかにうらやましかった。

いっぽう、演劇では鈴木の忠とか太田省吾とかがいて、コスプレがないわけではないけれど、舞台そのものは簡素化することで想像にお任せすることがあたりまえだった。おれは、断然こちらだ。

で、それから50年経つと、価値観も変わるんだなぁ、と非常に満足度が高いウィリー・デッカー演出の椿姫を観てアマゾン評を見て思う。コスプレじゃないという理由で怒っている人たちがいるからだ。大丈夫。50年たてばまたコスプレ地獄が口を開けて待ち構えているよ。

もっとも、時の番人の医者には少しばかりうんざりはするけどな。わかりやすくすりゃ良いというものではないのは、アマゾン評を読むとわかる。わからない人には意味が不明なままみたいだ。そしてわかる人にはうっとおしければ、そりゃ無価値だ。

それにつけても2幕の最初の戯れっぷりは実に観ていて微笑ましい、良い感じだ。

あと、映像で観ていて、なんでアルフレードの親父が物分かりが良い、良い親父かえらく納得した。

オペラの客層そのもの（特に19世紀後半のヴェルディの時代）だからだ。革命後に力を得たブルジョアで、旧世界の価値観と新世界の価値観の両方を知りぬいたうえで、新たな生活様式を模索し、切り開いてきた文化の新たなパトロン。

これは無下には扱えないだろう。

ヴェルディ1幕の浮かれた唄といえばマントヴァ公爵のあれかこれかだが、花から花へ(sempre libera)のほうが好きだな。しかしマントヴァ公爵は死なないが、ヴィオレッタは死ぬのであった(と、実は浮かれた唄というのは上辺だけで実際には少しも浮かれていないということを、デッカーの演出はわかりやすく見せている)。

それにつけてもネトレプコの体型の維持と歌唱力は天性のものなのか、努力の賜物か、おそらく両方なんだろうけどすごいなぁ。あと、やたらとヴィヤゾン（ヴィリャゾンという表記を見るが、フランス人なんだから(追記：ここがそもそもの間違いで、メキシコの人なのでヴィリャソンと読むのが正しいようだ。伝聞ってのは当てにならないわけで、実はイヌイットの可能性もあるよな)ヤじゃないか？ 人名は不規則な読み方するのは日本語も同じだからヴィリャなのかも知れないけど）と抱き合って二人で大声で歌うけど、お互いに鼓膜は破れたりしないんだろうかと無駄に心配したり。

_ ベルギー世紀末のしりあがり

文化村でベルギー幻想絵画展。

目当ては中学生の頃の夢だった(大袈裟だが当時は考えられなかった)デルヴォーとアンソール。後者はパルコ出版から出ていたサンボリスムの解説書か何かで見たパレードの画が印象的で勝手にベルギーのムンクと(ムンクで絵文字が登録されていて気勢を削がれた)

……で、大作を期待していたらちっちゃなメモに異様に細かい書き込みでえっと驚くサプライズ。続くユダヤ商人を寺院から追い払うキリストで大爆笑、なんなんだこれは。果物の上に豚天使、だいだらぼう(記憶が正しければ。鬼太郎の妖怪アパートの回に出てくる頭だけの妖怪)がつまみ食い。

……で、アンソールが描いたキリストの生涯がしりあがり寿でびつくりした。

デルヴォーはキリコのような重厚なタッチを想像していたら、軽くてびつくり。

実物はおもしろい。

で、名前忘れたが北の自画像の孤絶さに心が震える。

ブリュージュ

_ るびま

Rubyist Magazine 0027 号

お疲れ様です。

とりあえず巻頭言だけ読んだ。

今号は、Windows関連記事が2本ってのが特徴かな。

_ ベルギー

ベルギーと言えばダイアモンドとチョコレート。

ダイアモンドと言えば中央アフリカ、チョコレートと言っても中央アフリカ。

で、なるほどなぁと、思う(ベルギー幻想美術館の最初のストーリーである、植民地からの収奪によって栄えたブルジョアジーが芸術にお金を使い、芸術家が絶望と不安を表現するという循環)。

で、とりあえずウィキを調べペディア。

コンゴ自由国。

なるほど。自由民主党の自由の由来らしい。自由万歳。

そこから、エドモンド・モレル。

海運会社の主任連絡員としてリバプールからベルギーを往復する間にコンゴ自由国から輸入されるゴムの圧倒的多さに対して、ベルギーからコンゴへ輸出される商品が武器弾薬に限られていることに気付いて調査に乗り出し、

なるほどなぁ。ジャーナリズムというのはこういうことか。社会的疑問→真相調査→事象報告→社会的問題の提起→（それなりの）解消へ向けての世論喚起→漸進的進歩

別のモレルの本しかないな。

アフリカゾウを護る闘い―ケニア野生生物公社総裁日記(リーキー,リチャード)

ケニアだし。

史上最強のリーダー シャクルトン ― 絶望の淵に立っても決してあきらめない(マーゴ モレル)

なんかおもしろそう。

英訳(いや、モレルはイギリス人であってベルギー人ではないから、これが原書か)はあった。

Red Rubber: The Story of the Rubber Slave Trade Flourishing on the Congo on the Year of Grace 1906(Morel, Edmund Dene)

_ とっても遅いページの作り方

trがたくさんあるtableを作って、その中で個々のカラム(idxxxみたいなidをつけてあってxxxが行番号になってたりする)をgetElementByIdでアクセスすると、死よりも遅い。

for (var i = 0; i < document.getElementsByName('tr').length; i++) {
   var col1 = document.getElementById('col1-'+i);
   ...
   var coln = document.getElementById('coln-'+i);
   ...
}

それは当たり前だけど、Javaプログラマとかって、ばかよりも簡単な自明なコードを書け教育みたいなものをへたすりゃ受けているから、あほちん、そんなものはgetElementsByTagNameでtrとってるんだから、tr要素回してその中で子供取れとか、クライアントサイドでぐるぐる回すことがわかっているなら、行番号付きidとか用意するよりもすべてのカラムに同じ名前を付けといてgetElementsByNameで全カラム取ってそれでぐるぐる回せとか言っても、なぜにそんなとりつきいなことするんですか、このとろつきすと、みたいな反応になってもおかしかないなぁ。

しかし、getElementsByNameでがめた場合の並び順というのはHTML上の並び順と同一なんだろうか？ あるいは、foreachで回した場合の出現順はどうなんだろうか? とかは2. Document Object Model HTMLを読んでも出てないな。というか後者はJavaScriptの実装だから出てないのは当然か。

_ Ruby-OCI8でBlobのupdate

require 'ruby-oci8'
c = OCI8.new("scott", "tiger", "//server/dbname") # portは1521ならOKだったが指定したらORA例外となった
c.exec('select id, blob from table for update order by id') do |id, blob|
  b = blob.read
  b.gsub('a', 'b')
  blob.rewind  # これは重要っぽい
  blob.write(b)
  blob.size = b.size # これも重要っぽい
end
c.commit
c.logoff

以上で、table内のblobカラムの'a'は'b'に変わる。

とBlobの扱いで時間を取られたが、やはり圧倒的に楽。

_ Ruby_1_8

--- instruby.rb~        Fri Sep 18 23:00:51 2009
+++ instruby.rb Sat Sep 19 03:37:43 2009
@@ -427,7 +427,7 @@
   if RUBY_PLATFORM =~ /mswin32|mingw|bccwin32/
     win32libdir = File.join(rubyhdrdir, "win32")
     makedirs win32libdir
-    install "win32/win32.h", win32libdir, :mode => $data_mode
+    install "./win32.h", win32libdir, :mode => $data_mode
   end
 end

_ Ruby-1.8dev

うささんのselectが遅過ぎる件がマシになったかも知れない閃きパッケージを作ってみました。9月18日23:00の1.8 trunkからのチェックアウトです。

Fri Sep 18 14:44:13 2009  NAKAMURA Usaku  
	* win32/win32.c (rb_w32_select): wait specified time on select.
Fri Sep 18 14:30:40 2009  NAKAMURA Usaku  
	* win32/win32.c (rb_w32_select): on 1.8, we don't need to poll sockets,
	  because our select is never called from multiple threads.
 -- ChangeLog

僕もまったく、遅過ぎるが確認できないので、確認できる方は試してうささんにフィードバックしていただければと思います。

Ruby-1.8dev.msi
md5checksum b0cdefff54358e27449febbd279c9084
4,596,736バイト

なお、パッケージにはruby-1.8のほかは、コンソールとgzip、readlineなどの必要最低限のものしか含めていません。

_ QWERTY

子供が「なんでタイプライターの配列は……」とクイズを出してきたので、機先を制して、typewriterとかtheaterとかTannhuserとか語尾に「er」が付く言葉は多いけど、左手の中指人差し指の一連の流れで打てるから、キーボードってすごく打ちやすいけど、そう思わない？ とか訊き返しながら、安岡日記を探す。

すると、クイズ雑学王というのが取り上げられていたので、もしかしてクイズ雑学王？ と訊くと「そうだ」という。

考察や傍証なしの知識を得たなと感じたら、必ず反例を考えろよと教えてみたり、一度広まった歴史（あるいは定まった評価）は取り返しはつかないらしいとか、そういったことを話しあったり。

_ オテロ

新国立のオテロ。

にわかベルディなので、当然のように初めて聴く曲で、なかなか掴めなくて苦労する。

全体としては1幕の最後に愛する男女の2重唱、2幕の途中で別々のこと考える2組のカップルの4重唱、3幕で大合唱、4幕で孤独に悶えるモノローグのアリアというベルディパターンなのだが、個々の曲は、口笛で吹けるベルディ（乾杯の歌とか女心の歌とか）、鼻歌で歌えるベルディ（ジプシーの唄とか、アイーダの行進曲とか）がまったくなく、むしろ交響楽的で、とまどう。

帰宅してからプログラム（さすがにわけわからないので買ってしまった）を読んで、どうやら、アイーダで頂点を極めたから、さて、あとはモーツァルトの顰に習ってレクイエム書いて、死ぬまでロッシーニのように遊んで暮らそうと計画していたのに、なんのはずみかワーグナーを聴いてしまったために、このままではおれは歴史に埋没するマイヤベーヤ、と奮起して猛勉強して作った作品だということがわかった。

なるほど、それでなのか。といろいろ納得する。イヤーゴがハーゲンみたいに感じるのもそういった音楽的な性格づくりの結果として同じような形になるからかも知れない。

が、そのような構造的なことはさておき、オペラとしてはとても深く感じるものがあった。

オテロもデズデモーナ（声量でオーケストラに負けるところもあったが、総じて僕には声も姿も美しく、デズデモナとして文句ないように思った）も、イヤーゴも、天下の大名人というわけではないし、オーケストラも指揮も天下の名演奏というわけではないし、演出も驚天動地の新機軸というわけでもなんでもないが、すべて合わせて、実に良い感じだった。ふつうに良いオペラを観られた、ということだ。これまで感じたことがない、成熟感とでも呼ぶべきものを、今日のオテロから、すごく受け取れた。実に良いことだ。

しかし、オテロはテノールなのだな。だが、これは少し不思議だ。テノールでありながら、役がらはバリトンかむしろバスが似つかわしい考えてばかりの役回りで、明るさが必要なわけでもなく、にも関わらずテノールなのだ。ああ、と時々、思い出すのはオテロが英雄だということだ。最初に舞台に姿を見せて、キプロスの人々に勝利を告げるところまでは確かに英雄であったのが、その後は、最後に剣を振り回し、自らを短刀でけりをつけるまでは、ずーっと、英雄ではなく振る舞うのだが、最後にまた英雄として死ぬのだから、この役はテノールでなければならないのだろう。

そこから、オテロ（オセロ）と言えばとにかく思い出すのは、白いハンカチを徹底的に強調した、オーソン・ウェルズの大傑作のことだ。

オーソン・ウェルズのオセロ [VHS](アンティゼ・ブリッツィ)

アテネで観たのか（マクベスはアテネで観たのは間違いないが、オセロはもしかするとシネマテンあたりで観たのかも知れない）、シェークスピアはウェルズに限ると強い印象を受けた作品だが、これもまた、英雄の映画であった。

シェークスピアの4大悲劇の中でオセロは奇妙なポジションにある。ハムレットはデンマークの王子の王権奪取のための艱難辛苦の物語、マクベスは魔女にたぶらかされて力量を無視して僭王となった男の滅亡、リア王は権力の分配に失敗することで破滅する王者の物語、と、いずれも国のレベルの劇なのに、最後のオテロに関してはいささかスケールが小さくて、なぜこれを含めるのか、という気にさせられる。

が、それが英雄の物語であれば、話は異なる。悩みが強調されるもののハムレットは深慮遠謀に長けた英雄だし、マクベスは野望のために命を賭けた英雄だし、リア王は英雄として生きようとして破滅した男だ。オセロは当然のように同列となる（そこが有名ではあるけれどロメオとジュリエットがこれっぽっちも4大悲劇にはかすりもしない理由となる）。

ベルディがオテロを対ワーグナー戦争の駒に選んだのも当然のことなのだな、と納得する。自分の客を満足させられる愛憎劇でありながら、仮想敵国の重量級兵器と対等な英雄譚だからだ。

と、いろいろおもしろかったのだが、おれはワーグナーのほうが好きだなぁ。

_ オテロと神々の黄昏

あれからいろいろ考えてみるに、オテロは音楽（メロディと調とリズム）と台詞詳細はこれっぽっちも思い出せないが、音色と劇の構造についてはいくらでも思い出せるので、さらにいろいろ考察が進む。

抜群におもしろいのだ。

まず、おれが昨日仕入れた知識とこれまで持っている知識から得られる背景として、ワーグナーは、イタリアのベルディのことなどはなから相手にしていない。あいつは、自分のことしか考える必要がない男だ。で、神々の黄昏の上演は1876年8月、つまり明治天皇が7月20日に明治丸で横浜に帰還した翌月で、1874年に日本のフーシェが引き起こした内乱が新風連の乱と萩の乱で終結する年のことだ。まともな構想は1850年代、作曲は1869年（明治維新の翌年から1874年、つまり佐賀の乱が始まるまでのことだ。同じ年に万国郵便連合ができて、国際通信が確立される。

ヴェルディがオテロを本格的に作り始めるのは、1881年で完成させたのは1886年。つまり、オテロは、神々の黄昏より後のことだ。もっとも1876年の初演をベルディ自身は観ていない。歴史としては1871年にボローニャで観たローエングリーンで奮起したことになっている。が、国際情報網が確立する時代のことだ。アルプス山脈の向こう側とは言えバイロイトで行われた初演の様子は確実に伝わっていただろうし、その劇的構成から音楽的分析までリコルディやボイトあたりから情報化されて受け取っていたことは想像できる。

つまり、オテロと神々の黄昏の劇的構造の類似性に注目したい。

神々の黄昏は、英雄としてラインを下りはじめたジークフリートがギュビッヒの河岸に寄港したところで、ハーゲンの奸計に陥り英雄性をはく奪され、ブリュンヒルデを頭から完全に消し去りただの卑怯者として殺される。それをブリュンヒルデが自己犠牲により再度英雄としての死へ高める。

オテロは、英雄としてキプロス島に帰還したところで、イヤーゴの奸計に陥り英雄性をはく奪され、デズデーモナのことだけで頭がいっぱいになりただの嫉妬に狂う異常者として妻を殺す。そこでイヤーゴの妻の告発によりすべてを悟り(だが、それは台詞上であり物語としては妻の死による)英雄として自刃する。

ここに描かれているのは英雄の失墜と昇華の物語で、キーとなるのは奸計と妻の死だ。ただし充満と消去という逆方向でそれが行われる。

この劇的構造の相似は、オテロの原作が他の誰でもなく天下のシェイクスピアだという点で完全に隠蔽される。ワーグナー的なものとは、無限旋律という技術だけに留められる。それにしても、歌の最後に管楽器を唱和させることでそのまま次に続けるという技法が（歌はフェードアウトするのだが、全体的な音量としては元の水準を維持できるので切れ目がないように感じさせる）、異様にわかりやすいのは、イタリアの観客に対する教育的な配慮があるのかも知れないが、ワーグナーのパロディのように感じる瞬間もあったな。

というわけで、より分析的に聴きたくなるのだが、はて、何を買うのが良いのだろうか？

歌手だけで決めるのなら、これしかないのだが。

オテロ*歌劇 [DVD](デル・モナコ(マリオ))

やっぱデルモナコ好きだな。

英国ロイヤル・オペラ ヴェルディ:歌劇《オテロ》全曲 [DVD](ショルティ(サー・ゲオルグ))

ショルティは構造を明らかにできるし良さそうではあるが、ちょっと古いかも。

ヴェルディ:歌劇《オテロ》 [DVD](ミラノ・スカラ座管弦楽団)

ムーティ（最近、スネイプ先生っぽい）はいやかな。

というか、ジュリーニとかは無いんだろうか？

あと、おれはとにかく古臭い服を着たオペラは嫌いなのだよな。むしろ昨日の演出で持ちたいな。NHKでやらないかな？

でもまずは小田嶋訳を読もうかな(歴史がからまないから読んでなかったんだよね)。

オセロー (白水Uブックス (27))(ウィリアム・シェイクスピア)

むむ、ヴォルフガング・ヴィントガッセン（文句なしのワーグナー歌手）のオテロがあるが、その他の情報が読めない……

Verdi: Othello [DVD] [Import](Windgassen)

に惹かれたが、最終的に演出が新し目でランボさん頭のバレンボイムに決定。

Verdi：Otello [DVD] [Import](Daniel Barenboim)

_ ロボトミスト

図書館で借りて3/5ほど読んだ。明日中には全部読み終わるだろうが、もう書いちまえ。

時たま、英米人はとんでもない文字作品を産み出す。丹念な取材と考証、資料収集と解読、そういった地味な作業の末、歴史のある時点の社会とターゲットとした個人（あるいは組織）その歴史的な位置、現在の影響、そういったことを多角的に描くことで、特異現象だろうとは思えることから普遍的なものを産み出し、しかもそこに何がしかの感動まで付け加える。

そういった作品として、たとえばマイケル・ルイスのマネー・ボールというものがあるし、ウェンディ・ムーアのジョン・ハンターもそうだし、レヴィーの一連の作品もそうだ。

これらが単なる評伝では済まないのは、そこに社会的な（横の）広がりと、時代的な（縦の）広がりが含まれる点で、それが可能なのは膨大な考証と取材にあり、さらにそれを支えているのは英語の書籍という巨大マーケットの存在があるだろう。いずれにしろ、日本のノンフィクションライターの最も優れた部分でも、なかなかそこまでは到達できないように思える（たとえば、佐野 眞一とか、大宅壮一とか、これは筆力の問題ではなく経済の問題だろう）。

そして、ジャック・エル=ハイのロボトミストもそういったすごい作品の一つだ。

ロボトミーといえば、もちろん、いくつかの映画でその恐ろしさを知らされている。

女優フランシス [DVD](ジェシカ・ラング)

電気ショックもおっかない。

チェンジリング [Blu-ray](アンジェリーナ・ジョリー)

ロボトミストが追っかけるのは、メイフラワーの子孫にして、アメリカで最初のロボトミー手術の施術者、およびポルトガルの医師が名づけた白質切裁術をロボトミーというキャッチーな名前にした男、全米でも下から数えるほうが早かったワシントン州立医大をおもしろくてためになる授業で優秀な学生を集める学校に変えた男、精神病院に閉じ込められたまま一生を無為に死ぬだけの人々に普通の生活を与えるために奮闘した男、その名もフリーマンだ。

ロボトミストは、社会背景、歴史的背景、当時の医学の状況（アメリカ国内、欧米での状況の2段構え）、を立体的に構造化して、その中で主人公のフリーマンのロボトミーの普及（と、重度精神病患者の社会復帰への手助け、目的と手段が時々入れ替わる）に対する奮闘を見事に描いている。すばらしくおもしろい。

戦争は人手不足をもたらし、したがって、精神病院に閉じ込められたままで終わる人々が社会復帰できればそれは良いことだし、今よりも多少は人間の価格が安かった時代だ。5人に1人が社会復帰できれば、5人とも病院の中で死ぬよりベターという選択は確かに合理的で、その時代にはそれが唯一の方法であったということが理解できる。

その一方でアメリカでは精神分析医という職業が世界で最も発展し、巨大市場を形成することに成功し、そちらからは手術で精神を治療するというロボトミスト（精神外科）は（外科は通常完治を最終目的とする）市場的な脅威であり、それと同時に本当に脳の手術が治療なのかどうかの曖昧さ（健康な肉体に対して、仮に結果オーライとしても損傷を与えるという行為に対する倫理的な疑念）、敵も多い。

20世紀の最初の20年間は第一次世界大戦により医師があらゆる実験（731部隊の意味ではなく、かってないほど大量の負傷者や精神を病むものがあらわれたので、その治療は探求的にならざるを得ない）を行い、次の20年でその成果の刈り取りが行われる、そういった時代背景もある。

マスコミを利用した宣伝。一言も完治できるとも確実であるとも言っていないのに、なぜか読者は完治できるかのように信じ込まされる言葉のマジック、もちろん相対的なものなので次の瞬間には悪魔の技術として糾弾されることになるのではあるが。

著者は実にうまい書き手だ。本来はほとんどの時間をうっとおしくも薄暗い1930年代の精神病院の中で、ひたすら論文をあさっては患者を眺めているだけの人生と、そこに埋没している夢と野心（精神病院で一生を終える人々を社会へ復帰させる。そのことをもって自分の名誉とする）を読み物としても興味深い表現へと変えている。

それは、大学教授としての学生の興味を引き続けるためのさまざまなテクニック（両手で黒板に図を書く（ために朝から練習するとか）とか、生きた患者に体験を語らせるとか、いろいろ）、他の医師との交流（純粋な尊敬から多大な利益を引きだすこともあれば、欲得ずくのものもあったり）、子供への教育とか、ぎこちない恋愛からいきなり子だくさんとか、研究者を目指しながらも、外科手術という技術への憧憬とか（禁止されているはずが、いつの間にか自分で施術していたり）、人間としてのおもしろさを丹念にエピソードを拾うことで具体的に示しているからだ。

あるいはぽつっと一言だけで触れて終わらせているが、野心もあればずいぶん山っ気もある一方で、外科技術のほうを向いているだけのことはある誠実さを伝えるいくつかの事実、たとえばコロンビア特別区医師会の会長に就任したときに、白人以外の医師に医師会の門戸を開く（50年代のことと読めるから、非常に早い時期なのは間違いなさそうだ）ために尽力したこと、などを語ることで人物像の厚みを増すことに成功している。

個人的に、特にこの本が興味深いのは、主人公の指向が、あくまでも技術に向いているところだ。フロイトに始まる精神分析という方法ではなく（現実問題として精神病院に収容されている重症患者には役に立たないということもあっただろうが――というのは、結局は医師と患者の信頼関係の構築によって治癒されるのではないかと判断するところなどは、調べるべきことは調べた上で結論しているように読める）あくまでも外科的な治療で回復を目指すという点と、学生の興味を惹く授業を行うための戦略や、自著をよりよく売るための表紙へのキャッチコピーの掲載とか、学会の展示場での展示方法であるとか、何をやるにも、とにかく徹底している点で、興味深いが見習えそうにもないなぁというあたりとか。

技術史、科学史を描く優れた本として、これはお勧め。

ロボトミスト 3400回ロボトミー手術を行った医師の栄光と失墜(ジャック エル=ハイ)

_ 休みの中央区

片側4車線の道路を自由気儘に横断し放題。

でもカレー屋しか開いてない。

_ ラジオ

昨日昼飯食ってたらラジオがかかっていて、40年ほどのタイムスリップを経験した。

聴者投稿番組。

墓参りとかけてなんと解く?

アケビと解く。

そのこころは?

蚊に食われます。

あまりのばかばかしさに、いまだに脳裏にこだましている。

……つまり、おれは、好きなんだ。良かったな

_ LUST/RUST

_ ラ・バヤデール

上野で東京バレエ団のラ・バヤデール。

どうも、母体のNBSが妙に新国立劇場に含みがあるようで（ときどきチラシに苦言だか文句だか厭味だかが書いてある）、この演目は当てつけのような気がする。というくらいに、舞台から衣裳から力が入った力作だった。

が、元のバレエがそうなのかも知れないが、第1幕がインド（ヒンズー教）、第2幕が中国（道教）でもベッドの上にはインド風の孔雀、第3幕がタイ（小乗仏教）と無茶苦茶なアジア旅行は、せめて第3幕もインドにしておいたほうが良かったとは思う。思うが、たなびく雲、遥かに続く回廊、ハップル望遠鏡の世界のような寺院崩壊後の世界と、舞台美術は相当なもので、えらく見なおした（好みかどうかは別だが）。

2幕の坂道はさすがに初台ほどは奥行きがないので1段だけだったが、緊張感をきちんと維持していて観ていて美しい。というか、東京バレエ団のコールドバレエは観ていてきれいで楽しい（で、そういうものだろうと思っていると、DVDでパリオペラ座のバレエとか観てあまりの揃い方に、いやいやまだまだなんですな、とわかったりするのだが）。

それにしても、ラ・バヤデールは舞台芸術としては破たんしているとしか思えない。1幕と2幕は良いのだが、3幕が無理やり終わらせるための学芸会のようなシナリオとなっているからだ。あるいは、この幕は、婚礼の行進を見せ場とするように作るのが本来なのだろうか。

ドニゼッティのような名前の太守の娘を踊った人が実によかった。

_ セメント

はて、なぜ真剣勝負の意味となるのだろうか?

今では忘れ去られてしまったが、1950年代に第二の力道三と称されたレスラーがいた。森幹次郎である。

彼の長身と鍛え抜かれた分厚い胸板が、まるで鉄筋コンクリートのビルのようだということで、ファンは親しみを込めて彼をセメント?モリと呼んだ。

もっとも60年代になると彼のあだ名はヌリカベに変わる。実際、ぬぼーと突っ立っているだけの彼の姿からは、かっての彼の切れのあるファイティングスタイルを想像することは難しかった。

1957年の暮れのことである。一台の黒い車が彼が住む巣鴨のジムの前に停まった。

後部座席には

_ ベルディとユーゴー

ユーゴーは傑作黒人ボクシング小説のアーム・ジョーで知られたフランスの作家だが、他にもいろいろ作品を書いている。当然だが。

噫無情(ああむじょう)〈前篇〉 (世界名作名訳シリーズ)(ヴィクトル ユゴー)

その中に、ルイ何世だかの女遊びを糾弾する王様は今日もお楽しみという作品があるらしい。

御伽草子にも、天皇から女房を差し出せと言われた大臣が、まったく盗人国の盗人大王が治める最低の国だと嘆く作品があるが（もっとも女房は天女なので一緒に天界へ逃げるわけだが、天皇の「天」とは一体なんなのかという謎かけのようでもあり、実に興味深いというか、室町時代というのはそういう時代だ）、人権という概念が生じる前はいずこも似たようなものだ。

御伽草子 上 (岩波文庫 黄 126-1)(市古貞次)

で、この話がめっぽうおもしろいので、好色なイタリア人（つまり自分である）にはぴったりだと考えたベルディはさっそくオペラ化を開始する。

すると、劇場の支配人やら法王庁やらが待ったをかける。そんな王権をないがしろにする作品は、野蛮なフランス人は認めても、文化的なイタリアでは許しませぬぞ。

そこで、考えた末にベルディは、王様の代わりに遥か昔のマントヴァ公国の公爵を主人公にして、題名も刺激をなくしてリゴレットと変えた。

ヴェルディ:リゴレット 全曲(ジュリーニ(カルロ・マリア))

イタリアのオペラ王が自分の作品をオペラにしていると聴いたフランスの文学王、ユーゴは胸を躍らせる。夢の印税生活が待っているのではなかろうか（文学は大して儲からないが、オペラは儲かるのだ）。

しかし、イタリアでの大成功のニュースは耳に入って来るが、お金の話はまったく入って来ない。

そこで代理人にベルディへ催促の手紙を書かせた。

すると、ベルディが返事を寄越す。「は？ これはリゴレットという作品ですぞ。主人公はマントヴァ公爵ですぞ。ユーゴさんの作品はフランスの王様が主人公の王様は今夜もお楽しみという作品だというではないですか。私はそんなものはまったく知りませんな」

ユーゴがかんかんに怒ったのは当然である。しかし、イタリアは遠い。

リゴレットは成功に次ぐ成功でイタリア全土を制覇した。次には隣国フランスを制覇だ。

意気揚々とベルディたちはパリへ乗り込んでくる。

ユーゴが待ち構えているのは当然である。

が、あっさり無視された。

あのイタリア野郎、おれさまを完全に無視しやがって、とユーゴは怒り狂うが会えないことには話にならない。

ついに、オペラ座の初演の日がやってくる。

ユーゴは過激なブーイングでオペラを台無しにしてやろうと、一族郎党門人弟子たちを引き連れてオペラ座に乗り込んだ。ちゃんとお金を払って。

パリ初演は大成功だった。

終演後、あるジャーナリストがぷんすかぷんぷんしてロビーを匕首を忍ばせてうろうろしているユーゴを見つけた。

「やや、大文豪の先生、この作品は先生の王様は今夜もご機嫌にそっくりでしたな」

と、事情を知らずに声をかける。するとユーゴはぼそぼそ何かを答えた。

「そりゃそうだ。わたしの作品の盗作だからな。ベルディの泥棒野郎は、本当にイタリア野郎だ」

「で、どうでしたか？」

「うむ、あの見事な四重唱は文学では表現できない。ベルディはバラバよりも10000倍悪い盗人野郎だが、あの四重唱に免じて勘弁してやることにした」（もっともこの後も金を払えという手紙は出したらしい。そして当然のようにベルディはすべて読まずに食べた）

恐ろしい話である。

_ ASR-1.8.7.12(exp)

ダウンロードページ

Ruby-1.8.7-p174でwin32.cのみをRevision 25072に差し替えたものです。

うささんによると遅くなる問題は解決したそうです。

_ データフォーマットとアプリケーションからの扱い方

仕事で、ISO-8583っぽいデータを扱っていて、ちょっと考えた。

データフォーマットにはいくつかの種類がある。それぞれ良い点、悪い点がある。ここでは特にAPIに関して考える。

大雑把には、以下の4種類にわかれる。

• 固定長テキスト
• 固定長バイナリ
• 可変長テキスト
• 可変長バイナリ

以下では、次のデータを扱うことを例とする。

データベースのスキーマで示す。

最初の固定長テキストというのは、レコードとそれを構成するフィールドの長さが決まっているものだ。2レコードの例を示す。

static String TEST_DATA = "0000000000000001YAMADA KAKASHI                                                 JPN" 
                        + "0000000000000012BOOTY POOTY POING POING                                        BOB";

メリットは全然ない。というのは嘘で、COBOLで扱うには非常にありがたい。

* うろ覚えなので雰囲気だけ。
 03 record indexed by poyopoyo.
   05 id 9(16) display.
   05 name x(64) display.
   05 nationality x(3) display.

それを除けば、スペース効率は悪いし（したがって圧縮しなければ転送効率も悪い）特に可視性に優れいているわけでもない。致命的なのは拡張（フィールドの追加やフィールド長の変更）に耐えられない点で、そのため、通常は山ほどフィラーを取ることになる。そのため、ますますスペース効率は悪くなる。

もっとも、Cプログラマにも、扱いやすい。

char id[16 + 1]; // 16とかは#define FIELD_ID_LENGTH 16とかするのかも。
char name[64 + 1];
char* record = read_file();
memcpy(id, record, 16);
id[16] = 0;
memcpy(name, record + 16, 64);
...
record += 64 + 16 + 3;

次のバイナリ固定長も基本は同様だ。ただ、多少のスペース効率が得られたりする場合がある。上の例だと、idを2進化10進数にするなどが考えられる。

static String TEST_DATA = "\0\0\0\0\0\0\0\x01YAMADA KAKASHI                                                 JPN" 
                        + "\0\0\0\0\0\0\0\x12BOOTY POOTY POING POING                                        BOB";

固定長に比べて可変長の場合、フォーマットは実にさまざまだ。以下ではテキストに限定して主なものを示す。

CSV（カンマ区切り値形式）

static String TEST_DATA = "1,YAMADA KAKASHI,JPN\r\n" 
                        + "12,BOOTY POOTY POING POING,BOB\r\n";

一気に、スペース効率が良くなった。また、仮に128文字のnameフィールドのサポートが必要となったとしても、バリデーション部分を除けば、修正が不要な点も長所となる。

APIとしてはCOBOLでは突然扱いにくくなるが、Cなら普通に使える（もっとも固定長のほうがやはり楽ではある）。またライブラリが充実しているJavaやC#なら何も考えなくても、正規化されている前提であれば、簡単に利用できる。

String[] records = buffer.split("\r\n");
for (String r : records) {
    String[] fields = r.split(',');
    ...
}

実際には、正規化されていなかったり、nameのようなフィールドが「George, Boochi-the-third "family-man" Washington」だったりするので、エスケープが必要になったりする。たとえば、全体を"で囲み、フィールド内で出現する"は""のように記述するなどだ。

CSVのバリエーションとして、タブ(\t)で区切るというものも最近はある。さすがに制御コードがテキスト内に現れることはないので、上で説明したエスケープが不要になるといったメリットがある。

ここまでを、牧歌時代のフォーマットと考える。というのは、特別なライブラリがなくても、プログラミング言語の機能だけで誰でも処理できるからだ。もっとも、CSVでもありとあらゆる形式をサポートしようとすると格段にハードルが上がるため、ライブラリサポートが欲しくなるかも知れない。

で、書くのが面倒になってしまったが、XMLとBitmapがこの後に続く。

XMLは（無理やり正規表現という方法もあるが）既存パーサを使うことになる。つまりすでにプログラミング言語の機能だけで処理できる範囲を超えた、と考えても良い（実際には、汎用パーサを提供できるということなのだが、アプリケーションからみれば同じことだ）。

で、本題のBitmapだが、パーサというわけにはいかない。というのは、ビットマップを使うという点では共通だとしても、個々のビットの意味がスキーマによってまったく異なるからだ。しかし、正規化されたCSVほど、単純にプログラミング言語の機能だけで処理できるわけでもない。というよりも、そういうところで努力したコードは見たくない。

Bitmapは、たとえば以下のように定義される。

レコードの先頭4バイトをビットマップとする。MSBをビット1とする。ビット1はidフィールドを示す。idフィールドは最大16バイトでASCIIの'0'から'9'までの文字で構成される。先頭2バイトで長さを示す。ビット2はnameフィールドを示す。最大64バイトでASCIIの印字可能文字で構成される。先頭2バイトで長さを示す。ビット3は3バイトでASCIIの'A'から'Z'で構成される。

以下に例を示す。なお、2レコード目はなぜかnameフィールドが欠けたレコードである（Bitampはフィールドの不在を示せるという特徴がある）。

static String TEST_DATA = "\xe0\0\0\0" "01114YAMADA KAKASHIJPN\r\n" 
                        + "\xa0\0\0\0" "012CHN",
                        + "\xe0\0\0\0" "021224BOOTY POOTY POING POINGBOB\r\n";

結論を書くと、こういう形式こそDSLがふさわしい。

正確には、DSLを構成するクラス（群）はライブラリとして提供できるのだが、直接プログラム言語のプロシージャから操作するのではなく、一度、データ定義としてDSLでスキーマを記述できるようにライブラリを構成すべきということだ。

たとえば、固定長フィールドはフィールド名と長さと構成文字種（Nは\dをAは\wを示すとする)、可変長フィールドは長さを示すLの数でフィールドを示すとすると、アプリケーションは以下のように記述する。ビットを引数で示すか、順序で示すかは好みだと思うが、以下では引数で明示している。

BitmapParser fbp = BitmapParserBuilder
   .define(4)                       // Bitmap長を指定
     .FIX(1, "id", 16, 'N')
     .LL(2, "name", 64, 'A')
     .FIX(3, "nationarity", 3, 'N');
   // .endDefine() があったほうが固い。
...
fbp.read(new File(path));
while (fbp.next()) {
    System.out.println("id=" + fbp.bit(1) + ", name=" + fbp.bit(2) + ", natinality=" + fbp.bit(3)); // bitメソッドの型はObjectになる。またはJDBCのように、getString(2)などの型指定の取得メソッドを用意する。
}

実装例はまた来週。

_ JSONとYAML

上の分類だとXMLの仲間。ビットマップの異文化っぷりを楽しむというのがテーマ。