日記みたいな何か

T42にMTVX2006USBをつないでみたんですが，音は出るものの画面がまったく出ず．あれこれ試してみたところ，2005モードにすると出ることが判明．FAQから察するに，どうやら2005モードだとDirectDrawのオーバーレイで表示するようになるらしく，2006モードのDirect3Dでの表示だとT42のビデオチップ (確かRadeon Mobility 7500) ではうまくいかないということか？・・・ってこれじゃあVHScrCapで拾えんぞ (;´Д`)

どうにかならんかとあれこれググってみたら，Omega Driversなんていうドライバを発見．とりあえず Mobility Radeonにも対応していそうだったので，ダウンロードして入れてみたところ・・・2006モードだとウィンドウすら出なくなってしまいましたorz．そしてディスプレイまわりの各種設定を弄っている内に，気づけば2005モードでも何も出ない状態に．dxdiag で確認してみたら，DirectDrawもDirect3Dも無効になっとるし (;´Д`)

どうにもわからん状態になってしまったので，仕切り直しということで，一旦ディスプレイアダプタのドライバをロールバックしてみることに．今まで一回も使ったことなかったんですが，普通に前のドライバに戻ってくれたみたいです．へー．そして，再起動したら2005モードで画面が出るようになりました．ふぅ．

で，この状態で2006モードにするとなんにも出ないわけで・・・って2006モードでも映っているぅ！ い，一体どういうことだ・・・．そのまま VHScrCap で普通に取り込めてUstreamに流し込めました．というわけで，結論としては，なんだかよくわからないけどやぱり T42 で MTVX2006USB は使えるらしい．いやー，何がどう直ったのかさっぱりですが，まああっさり諦めなくて良かったってことで．

昨日ぐらにどっとこむさんの動画を見てたらやりたくなって，サターンをつけてやってみました．・・・クリスタルコアで終了 orz．もうどうしようもなく下手だ ＿|‾|○

いやしかし3ボスで終わってる人が何を言ってやがるって感じですが，今やっても普通に面白いというか，古さをさほど感じないのがすごい．20年前からこの水準のゲームが存在していたんだなぁ．とりあえず1周ぐらいはしたいものです．頑張ろう・・・．

歯医者行って，前に削ったりしてもらったところの型とったりしたんですが，最後に「何か」を対象の歯とその周辺にぎゅうぎゅう練り込まれました．何かキャラメルがひっついてるみたいで超非常に気になる・・・というか，来週半ばまで耐えられるのかこいつは・・・．

Windows版のPidginの oscar (AIMとかICQのプロトコル) では，ユーザの入力したUTF-8な文字列を UTF-16BEに変換する前に，まず ISO-8859-1 に変換できるか試します．これで変換できたら1byte文字で送ったりするわけで，多分常にUTF-8で送るよりは多少は効率的とか，そんな感じなんでしょう (oscarでは非Latin1な文字はUTF-16BEで送るらしいので)．

で，Windowsだと，上記の箇所で，全角記号や全角英数字までもが UTF-8 から ISO-8859-1 へ変換できてしまい，しかもその際勝手に半角に置き換えられてしまう・・・というのが今回の問題．上の方でworkaroundを仕込むのもいいんですが，気持ちが悪いのでどうにかできんかと，yazさんを無理矢理巻き込みつつ原因を追ってみました．以下，わかったことと推測されることの要点．

• g_convertを呼んで UTF-8 の全角アルファベットをISO-8859-1に変換するだけのコードを書いてテストしたところ，Linuxでは g_convert に失敗するが，Windows上でPidginについてきた Glib とリンクさせると成功して半角アルファベットになった．Pidginが変なことをしているわけではない模様．
• GNU libiconvには，変換先の文字コードに「ISO-8859-1//TRANSLIT」のように「//TRANSLIT」をつけると，前述のような挙動になる機能があった (libiconvのソースのlib/translit.defを見てみよう)．
• Windows版のPidginと一緒に入るGTKのGlibは，なんと GNU libiconvを使っておらず，代わりに win_iconvというのを利用している模様 (libglib-2.0-0.dll を objdump -d して確認)．glib-2.16.1 のソースを落として中を見てみたら，普通に win_iconv 入ってるのね．
• win_iconv は，Windows のAPIを呼び出してlibiconv互換のAPIを実現しているっぽい．多分 UTF-8 から ISO-8859-1 に変換する際には，WideCharToMultiByte が呼ばれることになる．
• WideCharToMultiByte は，デフォルトで「TRANSLIT」的な動作をするようで，2個目の引数に「WC_NO_BEST_FIT_CHARS」というフラグをつけるとこれを防げるらしい (ここに書いてある「WC_NO_BEST_FIT_CHARS」の説明だと逆なように見えるのでいまいち確証が持てませんが)．
• Glib内蔵の win_iconv のソースを見ると，2個目の引数に0が突っ込まれていた．外からいじれないっぽい (´・ω・｀)

というわけで，アプリの側からどうこうできるような問題じゃないっぽいというのが結論でございます．これだけ書くとすごくあっさりここにたどり着いたように見えますが，どこで問題が起きているのかなかなか見抜けず，半日ずっとこればっかやってました ＿|‾|○

で，既存のコードを尊重するなら，以下のようなパッチが良さそうです．ISO-8859-1に変換できたとしてもすぐに結果を信じずに，再変換してサイズが同じだったら初めて信じる，みたいな．

--- /home/compile/pidgin-2.4.0/libpurple/protocols/oscar/oscar.c.old
+++ /home/compile/pidgin-2.4.0/libpurple/protocols/oscar/oscar.c
@@ -551,7 +551,19 @@
 	 * XXX - We need a way to only attempt to convert if we KNOW "from"
 	 * can be converted to "charsetstr"
 	 */
-	*msg = g_convert(from, -1, charsetstr, "UTF-8", NULL, &msglen, NULL);
+	*msg = g_convert(from, strlen(from), charsetstr, "UTF-8", NULL, &msglen, NULL);
+#ifdef _WIN32
+	if (*msg != NULL) {
+		gchar *msgr;
+		msgr = g_convert(*msg, strlen(*msg), "UTF-8", charsetstr, NULL, NULL, NULL);
+		if (msgr == NULL || strcmp(msgr, from) != 0) {
+			g_free(*msg);
+			*msg = NULL;
+		}
+		if (msgr != NULL)
+			g_free(msgr);
+	}
+#endif
 	if (*msg != NULL) {
 		*charset = AIM_CHARSET_CUSTOM;
 		*charsubset = 0x0000;

古いクライアントなんてクソ喰らえなら，こんな数byteをケチるためのコードとはとっととお別れしてUTF-16BEで統一すべきですね(笑)．って，ICQはそれで平気なんだっけ？

最新のyazさんパッチを当ててWindows版をビルドしてみました．大体よさそうかと思いきや，Windows版のPidginから「～」のみを送ると，送り出す時点で「~」に置換されちゃうという問題が．「あ～」のように，非Latin1文字と混ぜて送ると平気だったりします．何だこりゃ．

調べてみたら，どうも「～」単体だと，oscar.c の purple_plugin_oscar_convert_to_best_encoding の中で，

*msg = g_convert(from, strlen(from), charsetstr, "UTF-8", NULL, &msglen, NULL);

で UTF-8 から ISO-8859-1 に変換できてしまう模様・・・．なんでー？Linuxだと発生しないので，Windows固有の現象なんですかね．もしやと思って全角アルファベットや全角数字を突っ込んでみたら，こちらも半角に変換されて送り届けられました．うわー・・・ナニコレ・・・．

とりあえずこんなことして回避してみましたが，なんだかなぁ．

@@ -551,8 +552,10 @@
         * XXX - We need a way to only attempt to convert if we KNOW "from"
         * can be converted to "charsetstr"
         */
-       *msg = g_convert(from, -1, charsetstr, "UTF-8", NULL, &msglen, NULL);
-       if (*msg != NULL) {
+       *msg = g_convert(from, strlen(from), charsetstr, "UTF-8", NULL, &msglen, NULL);
+       if (*msg != NULL && !(strcmp(charsetstr, "ISO-8859-1") == 0
+                              && strlen(*msg) != strlen(from))) {
                *charset = AIM_CHARSET_CUSTOM;
                *charsubset = 0x0000;
                *msglen_int = msglen;

今日も飲んできました．結構遅くまで飲んでても帰れるのはいいんですが，やっぱ遠いね・・・．帰りの電車は割と空いてて助かりました．

川崎の方に泊まってたりしたんですが，戻るついでに割と突発的に秋葉原に寄ってきました．今日はそこそこ明るい時間に着けたので，まずDIN8ピン オーディオタイプを探してラジオセンターの中をうろうろ．が，1Fと2Fを何件か回ってみたものの，どこにも置いていないっぽい (´・ω・｀)．まあ，でも，3.96mmピッチの56ピンエッジコネクタとか売ってそうなところを見つけたのでよしとしよう．

次にラジオデパートに移動．何か久々に来た気がする・・・．さっそく1Fをぐるりと見てみたものの，やっぱり見当たらず (´・ω・｀)．2Fも何かダメそうな雰囲気．「あー，昔ここでオシレータいっぱい買ったなぁ(笑)」などと思いつつ半分くらい回ったところで「DIN8ピン」と書かれた札に「(a)」と「(b)」と書いて置いてあるお店を発見！ 「こ，これ，何が違うんですか！？」と聞いてみたところ，端っこの2ピンが違うということで，まさにオーディオタイプでした．というわけで，DIN8ピン オーディオタイプの中継コネクタ(メス) のゲット成功です．

売ってた場所は，東京ラジオデパートの2Fにある瀬田無線というお店です．オーディオタイプのオスのプラグやパネル用のメスコネクタも売っていたので，メガドライブ用の何かを作っている人とかは，要チェック．とりあえずこれでXMD-2のプラグを普通のDIN8ピンに変換できるはず．

その後は千石へ．全然計画立てて行かなかったので，パーツを手に色々長々と悩んだ挙句，結局大して買わずに終了 (;´Д`)．まあ，ノギスとかはんだ吸い取り線とか買ったりしたけど．

千石電商を出たところで，今日の本当の目的はMVS買うことだったということを思い出しました(笑)．というわけで，ネットで在庫があることを確認していたG-Frontへ行って，MV-1Fを購入してみましたよ．また一つ，長年の夢が．

帰ってみたら，試しに買ってみた(^^; ワーヒー2JETも届いてたので，早速動かしてみることに．まずは自作のコントロールボックスみたいなものとハーネスみたいなものに4ボタン目の配線を追加．内部配線を追加でハンダ付けするのはかなり面倒じゃのう．

まずカートリッジをさしていない状態で，いざスイッチON・・・よし，とりあえずテスト画面が出たぞ．ボタンの配線もOKっぽい．

ではカートリッジをさしてみよう・・・って，これ，どっちが上なんだ？ うーん，MVSの画像を検索してみると，普通にラベルが読める向きでさせばいいみたいなんですが，そもそもこのラベルの向きは信じていいものなのか・・・？ ・・・ええーい，とりあえずスイッチON！

キタ━━━━(゜∀゜)━━━━ッ!! というわけで，ラベルの通りであっていたみたいです．カートリッジの「△」マークのついた面を下側にすれば確実なんですかね？

ところで，音が出てないな・・・．うーん，やっぱあの微妙な方法でスピーカ出力の＋から取り出してるのがまずいのか？ というわけで，ひとまずステレオに切り換えてヘッドホン端子の方から暫定的に取り出してみたところ，無事鳴ってくれました．わーい．

ていうか，何気にJETって初めてやったんですが，自分の知っているワーヒーとずいぶん違う感じで衝撃を受けました (笑)．あと，ワーヒー2JETは4ボタン使わないんですよね．頑張って今日配線する必要なかったなぁ (´・ω・)

いわたさんから，uim-apl がuim.elで動かないという報告が．あれー？ とりあえず，これがダメなら国際音声記号の入力もちゃんとできないに違いないと考え，早速試そうと思ったら，そもそも uim-im-switch 自体がちゃんと動かないことが発覚・・・(;´Д`)

色々試してみたところ，どうもエンコードの違うIMを切り換えようとするとおかしくなる感じ．うーん．

uim-el-agent側で，CHANGEコマンドで呼ばれる処理を追ってみたところ，エンコードの変更を行った後にIMを切り換えるのを忘れていることが発覚．ぐはぁ．1行足してきちんとIMも切り換えるようにしたところ，直りました．うーん，多分，これからだなぁ・・・(´・ω・｀)

あと，ついでに国際音声記号を使ってみたところ，文字が全然入らないことが発覚．Emacsで表示できるはずの文字なのに一体なぜ・・・あ，よく考えたら uim.el側がUTF-8非対応だった．ついにその時が来ってことか．

実用的に使えるのかどうかわかりませんが，とりあえずGNU Emacs21以上限定でUTF-8を許可するようにしてcommitしてみました．XEmacsも「(require 'un-define)」とかすりゃいけるのかな？

寝る前にyazさんの助言に従ってoscar.cの「UCS-2BE」を「UTF-16BE」に置換してコンパイルしたら日本語は正常に通るようになりました．これとは別に，Latin1な文字 (要するに半角アルファベットとか数字とか) のみのメッセージをPidginから送っても相手に無視されるという問題もあったんですが，こちらもyazさんの助言で一応解決．わーい．

で，起きて飲みに行って帰ってきたら，色々整理されてパッチになってました．速い(笑)．そんなわけで，現在2.4.0にバックポートしてみてLinuxでテスト中．特に問題がなければ後でWindows版を・・・．

今日はよみさんとかと飲んできました．まだまだお酒を飲む機会は続く．