|
．寝てた。 ．今週のタモリ倶楽部のネタがジャーマンスープレックスで、ドイツつながりで麹町のパウケでロケをしていたので行きたくなった。 ．パウケは良い店で、麹町の日テレとかがある通りに面した地下にある。戸を開けると通路の両側がコンパートメント風のテーブル席になっていて、奥の鈎の手みたいになったところを抜けると小さなステージがある。ステージの前には大きなテーブルがある。ステージでは何分かおきにドイツ民謡かなんかの生演奏をやる。アイスバインがうまい。 |
|
．ドトールでマターリ。 ．そういえば新しくカレーデニッシュというのがラインナップに入っていて、平たく言えばクロワッサンのカレーパンなのだが、やっぱりカレーの量が少なくてつまらない。こないだ片品で買ったカレーパンは中身がいっぱい入っていてよかったなぁ。 |
|
．「こけら」ネタと敬語ネタ。 ．良く知られているように、「かき」の「柿」と「こけら」の「柿」は良く似た別の字なのだが、JIS X 0208 では同じコードポイントに包摂されている。JIS X 0208:1997 の規格書をみると、1ページ半に亙ってこの二つの字の違いについて解説されていて面白い。この手の似た字が歴史経過の中で如何に混淆するかというのが良く分かる。比較的最近の康煕字典ですら、現在とは異なる。 ．上の規格書ではいろいろ理屈を付けてこの二つを一つの字にまとめてしまっているけど、そしてそれは X 0208 規格のカオス的事情を考えればむべなることなれど、本来なら「どれが正しい字体なのか分かんないけどいずれにしろ別の字である」という認識の方が正しいような気がする。例示されている物の中では区別している文献の方が多いようだし、字音からして「こけら」は「ハイ」だが「かき」は「シ」で、字音というのは概ね旁に由来するから、「かき」が「市」と何らかの関係を持つ字なのに対して「こけら」は「市」とは関係がなさそうだという推測もできる。 ．ところで、国語辞典をひくと「こけら」には「木屑」という字も当てられていて、つまり「柿」は「木のくず」程度の意味なんですな。 ．JIS 補助漢字(X 212)には「こけら」があるので Unicode だと各々別々のコードポイントが与えられている。JIS X 0208 の「柿」は U+67FF で、これは「かき」に対応している。「こけら」は U+676E にある。 ．きょう久々に「よろしかったですか」という言葉を聞いたが、今回はお決まりの「よろしいですか」の誤用というパターンではなくて、本来なら「よろしゅうございましたか」と言うべきところで「よろしかったですか」と言ってしまったパターンなのでちょっと興味深い。そうかこういうパターンもありうるのか。 ．ぐぐってみて初めて気づいたのだが、「よろしかったですか」という言葉を誤りとする者には実は「ロジックとしておかしい」とする派閥と、「そんな慣用句はない」とする派閥があるんだねえ。それにしても、最近めっきり「よろしかったですか」という言葉を聞かなくなったような気がするのはマニュアル改定の成果か。いま日本の国語文化に一番影響を与えているものの一つはチェーン店の接客マニュアルのような気がする。 ．いずれにしても、敬語みたいなもんは、誤りを指摘されたら恥じて頭を垂れるよりない問答無用の世界なのだから楽だ。いい大人が間違った敬語を擁護して「言葉は変化するから云々」なんて追従を言っていてはいかんですね。「敬語をちゃんと使えないなら使わんでいい」って意見の方がまだ筋が通っている。 ．敬語はこれでいいとしても、「ら抜き」みたいに「敬語でもなく、そこそこ理にかなってるけど模範的文法からすれば間違ってる」みたいのが一番始末に困る。あたしは使わんが、望むと望まざると「ら抜き」はあと 50 年もすれば正統な文法になるだろうという予感がする。 ．これとても、擁護するように「言葉は変化するから云々」なんて言うのは好ましいことではないが、しかし結果論としては「やっぱり言葉は変化するものなのだなあ」で済ませるしかない趨勢になりつつある。これは過去にも例のある変化のパターンだし、まああと 50 年もたって足掛け 100 年の実績ができれば認めてやらざるを得ないだろう。大野晋の説によれば、文法が 100 年ほどのスパンで変化すること平安時代から変わらない。そうやって変化した末の文法を現に私たちも使っているんだから、これはそういうものだと思う。まあ、少なくとも漢字制限みたいな「変化」と比べればずっと健全だろうし、なにより、自分が死んだ後のことを心配してもしょうがない。 ．しかし何で戦後になって急に「ら抜き」が使われ出したんだろうな。ちなみに、ら抜き言葉は団塊の世代あたりから興った言葉です。 |
|
．KOF2007 NetBSD - えびぢゅんさんの itojun さん追憶トーク。 ．そろそろ jmcneill-pm ブランチをテストしてみないといかんかねえ。 ．というか、さすがに NetBSD でノート PC を使うのは疲れてきたので、次にノートを新調するときは Win + VMWare にしちまうかもしれん。 ．S4BIOS を使って NetBSD をクラッシュさせる方法をメモしておこう:
|
|
．SONAR6 はモノラルのエフェクトプラグインを正しく扱ってくれない。 ．README には制限事項として「ステレオバスでモノラルエフェクトを使うと左チャネルが Wet で右チャネルが Dry になる」って書いてある。なんて間抜けな。モノラルバスについては何も書いてないけど、やっぱり Dry 音が混入する。これは致命的。 ．バスを 3 つ作って直列につないで、最初の二つをステレオに、最後のをモノラルにしておいて、最初のバスにモノラルプラグインを挿入、パンを左一杯に振ると回避できる。二つで十分そうなもんだけど、真ん中のステレオバスがないとなぜかうまくいかない。いずれにしてもなんかアレ。 ．というわけで VST プラグインを作ったよ。その名も copyleft-vst。2in 2out のステレオプラグインで、単に入力の左チャンネルを出力の左右にコピーするだけ。だから copyleft 。 ．SONAR でモノラルエフェクトを使いたい場合、まずステレオバスを作って（これ重要）、好きなモノラルエフェクト（いくつでもいい）を挿入したあと、最後に copyleft-vst を入れると良い。モノラルエフェクトとステレオエフェクトを混在させたい場合には、モノラル→ステレオの境目に copyleft-vst を入れると良い。 ．まあこれでだいたい困らないのだけれども、完全かといえばそうでもなくて、「元がステレオの音声にモノラルエフェクトを掛けたい場合」にはソースが左チャンネルだけになってしまう。よって、モノラル化プラグインも同梱すると親切かもしれぬ。 ．copyleft-vst にしろモノラル化プラグインにしろ、わざわざ作らなくても他のプラグインで代用できそうな気もするけど、挿入するだけで使えるっていう手軽さは重要だ。 |
|
．天皇陛下のブルーギル持ち込み反省声明……ニッポンの「環境主義者」はスメラミコトの真意を曲解している - 人の「曲解」を嗤う文章で自分も同レベルの「曲解」をしていたら世話がない。 ．「人のアラは良くわかるが自分のアラには気づかないものだよ」という教訓を身を張って示そうとしているのかもしれない。他山の石。 ．人の発言の自分に都合のいいところだけをつまみ食いして気づかないのは人間の悲しい習性の一つであって、他人の悲しい習性はことごとく自分にもあって然るべきということを自覚していれば、たぶんこういう失敗はしない。でも、経験上、これは口でいうほど簡単ではなさそうだ。 |
|
．なぜ Intel Mac のドライバには 64-bit 化の問題が起きなかったのか？ - 「カーネル空間が 32bit だ」とはどこにも書いてないような。たぶん「プロセス」という形でデバドラをカーネル空間から隔離しているから、既存の 32bit のドライバがそのまま動くようになっているという話のように見えるけど、MacOS X のことは知らないので眉唾。 ．少なくとも、物理アドレスとかがハンドルのような形で隠蔽されてないとこういう芸当はできないから（64bit OS なら 4G 超えのメモリを積めてナンボで、デバドラとしてはそういうアドレスにも DMA とかを仕掛ける必要がある）、おそらく MacOS X カーネルの設計の筋は悪くないんだろう。 ．ところで 32bit PCI のバスマスタって、やっぱり 32bit 空間にしか転送できないんかなぁ。懐かしのバウンスバッファを使っていたりするのかしらん。 ．NetBSD の src/sys/arch/x86/pci_machdep.c に「LP64 と PAE では適宜バウンスせよ」と書いてあった。Linux はやっぱりデバドラごとにバウンスバッファ持つのかな :-P ．NetBSD の bus_dma(9) フレームワークは実によくできていて、デバドラからはバウンスバッファがキャッシュの一種として隠されている。ほとんどのアーキテクチャでは DMA の前後で CPU のキャッシュとメインメモリとの間の整合性を取らなければならないから、これをバス非依存な sync という操作で抽象化している。バウンスバッファもここで処理される。当然、バウンスが必要な場合と必要ない場合を自動で判別してくれる。 ．NetBSD の paste -d '\n' ってバグってねえか? |
|
．それにつけても金の欲しさよ - 山崎宗鑑の作と伝えられる由緒正しい下句。 ．なんとなく less で .vsq ファイル覗いてみたら、先頭に MThd とか書いてありますよ。SMF じゃんこれ。 ．VOCALOID の SMF 出力ではボーカロイド MIDI という NRPN ベースのプロトコルを使っているけれど、.vsq はこれに加えて SMF メタイベントで歌詞とかを埋め込んである。単なるテキストファイルを 255 バイトずつ切ってテキストイベントの形で埋め込んだ感じ。 |
|
．ドトールでマターリ。 ．vsqdump - 単に .vsq ファイルの中のメタテキストを標準出力にダンプするだけのプログラム。どっちかというと、最近書いた SMF パーサのテストみたいなもん。ライセンスファイル付け忘れたけど、vsqdump-0.1 は BSD ライセンスってことで。NetBSD と VS8 でコンパイルできる。他は知らん。Windows 版は exe も入ってる。 ．DirectShow は、おまかせでできることをやるのならば、すごく簡単に高機能なことができるのだが、おまかせでできないことをやろうとすると、すごく単純なことをやるにも少々複雑なコードを書く必要がある。何よりドキュメントの中をたらい回しにされる。 ．素朴な AVI ファイルを吐かせるくらいのことだったら、むしろ Video for Windows のほうが簡単なので、32bit DIB な無圧縮 AVI を吐くコードを書いて、VideoStudio で読み込ませてみたら、ちゃんと最上位 8 ビットをアルファチャネルとして認識していることを確認。 |
|
．原因調査に数時間かかった挙げ句、一ヶ所 TRUE を FALSE に書き換えるだけという類のバグ修正。こういうバグは無くならない。 ．バグを減らすための一番の方法は、コードを書かないことだ。上のバグとは関係ないけど、たとえば「正常なら false を、エラーなら true を返す関数」を考えてみよう。これをうっかり次のように書いてしまったとする: こういうことになってしまうのは一体何が悪いんでしょう。 ．「正常か異常か」ということに対する意味付けが弱い bool 型を返すのも悪いんだけど、それ以前の問題として「正常なら〜を返す」という動作が余計なのであって、C++ なら次のように書いた方が良いに決まっている:
void
foo()
{
...
if (...)
throw Error(); // エラーは知らせないとね。
...
// 正常に終わった
// 他に何か必要?
}
そういうことです。
．もっとも、えてしてあたしたちは throw が使えない環境でプログラムを組まなければならなかったりするわけだけど。それでお給料を貰っているのだからしょうがない。 ．ここまで書いて、ふと別のことに思い当たって自信がなくなってきた。throw は例外安全保障を忘れると大変なことになる。忘れられることは必ず忘れるのが人間の大切な機能の一つで、そして、異常系のバグは正常系のバグより厄介だというのが通り相場。どうすりゃいいんだ俺たちは。 ．バグを減らすための一番の方法は、コードを書かないことだ。こんな商売からはさっさと足を洗った方がいいのかもしれない。 |