https://mitsuki.engawa.org 生温い技術屋がぼんやりする日々 mitsuki https://mitsuki.engawa.org/TalesWeaver/20060816_viewer.html 　お盆は車検があったり実家帰省したりで、忙しいようでそうでもなく、のんびりしてました。ただ、実家にいるとネット見たくない病を発病してしまうので、自宅に帰ってくると未読の各種ログ（メール、2ch、bloglines）の山に呆然としてしまうのが困りもの。　そんなこんなでログを処理していたら、なにやら某Lさんがおもしろそうなことしてるのを発見。すごいすごいGoodJob。韓国鯖時代にCapterの翻訳やってた頃、せめてテキストだけでも抽出できないものかなーと覗いて見たものの、案外面倒そうだったので途中で放り出した過去を思い出します。当時コレがあったら作業も楽だっただろうなあ（なにしろ、画面見ながらハングルをテキストファイル化→機械翻訳→日本語として調整、なんてことをしてたので）。　ちなみにTWのシナリオ系のファイルは確か、テキスト・画像・サウンド・その他コマンド（キャラ移動とかアニメとか）がアーカイブ内外のいろんなファイルにちらばってて、それをシナリオファイルで統合してるような、意外に凝った作りになってたはず（簡易データベースか、あるいはXMLだったのかな？）。　そういえば、クライアントをデバッグモードで起こせばCapter見るような機能があった記憶があるけど、あれはもう潰されちゃったのかな。　ちなみにわたしもCapter1しか見たことないです(ﾟ∀ﾟ)。 TalesWeaver|Diary mitsuki 2006-08-16T21:36+09:00 https://mitsuki.engawa.org/Programming/20060804_tag.html 　今更blosxom？　とか言われそうですが（笑）、久しぶりにいじってみました。テーマは「タグ化」。　blosxomは標準ではディレクトリ＝カテゴリーなわけですが、はてなブックマーク等に慣れてくると、なにかと自由の利くタグを使いたくなってきます。タグ対応pluginは探せば既存でもいくつかあるようですが、やり方を思いついたので自分でも実装してみました。　ソースはこちら。　おおざっぱな仕組みは、filter()でエントリーファイルの1行目（タイトル行）からタグ（[]で囲った文字列）を収集エントリーファイルの存在するパスもタグとして収集リクエストのパスをターゲットのタグとし、対象となるファイル以外をファイル一覧(%files)から削除あとは通常のシーケンスでエントリーが表示されるので、story()で表示用のタグリンクを作成、というシンプルもの。　ただし、通常はカテゴリー（ディレクトリ）内のエントリー以外は表示をスキップする処理が走るので、blosxom.cgiを修正してカテゴリー機能自体を無効にする必要があります。sub generate {（中略） # Only stories in the right hierarchy# $path =~ /^$currentdir/ \ or $path_file eq "$datadir/$currentdir" \ or next; #←コメントアウト（実際は1行）　また、recentwritebacks_treeのような、エントリーファイルからタイトルを拾ってくるpluginは、タイトルからタグ部分を除去するように改造する必要があります。sub gettitle {（中略） if($fh->open($file)) { $ret = ; $fh->close; $ret =~ s!(\[[^]]+\])*!!g; #←追加 } chomp($ret);　他にもタグリストのキャッシュ機能なんかも実装してありますが、細かい話なので省略。　この仕組みので面白いのは、エントリーファイルのパスも自動的にタグ扱いしてくれる点。つまり、既にカテゴリー分けされてる既存のエントリーは、何もしなくても最初から自動的にそのカテゴリー（ディレクトリ）名のタグが付いてくれます。　また、カテゴリーを2階層以上掘ってある場合、エントリーが属する上位のカテゴリーも全てタグとして付いてきます。例えば「/NetGame/RagnarokOnline/sample.txt」というエントリーの場合、「NetGame」と「RagnarokOnline」のタグが一気に付くわけです。「NetGame」直下に置けば「NetGame」だけに属し、「RagnarokOnline」の下に置けば「NetGame」「RagnarokOnline」両方に属する、つまり「RagnarokOnline」は「NetGame」をも含むという、タグ同士の包含関係のようなことが実現できるわけですね。　というわけで、かなり久しぶりにperlをいじりましたが……やっぱり自分で書くならrubyの方が好きだなあ（ぉぃ）。 Programming|WebDev mitsuki 2006-08-05T00:55+09:00 https://mitsuki.engawa.org/Programming/20051203_vaargs.html 　そういえば、今日（既に昨日）はBinary 2.0カンファレンスの日でしたか。どんな内容だったか気になるなあ……。　というわけで、せっかくなので(?)バイナリっぽいネタを少し。　諸事情で、以下のような機能を実現する必要があるとします：printf()と同じフォーマットが使えるデバッグログ記録関数を作る。ただし、vsprintf()は使えない。sprintf()は使える。独自のログ書き出し関数log_puts()は、固定引数で文字列へのポインタを1つだけ受け付ける。　vsprintf()が使えれば一発で終了ですが、それが使えないとなるとどうしたものか。sprintf()が使えるのはいいけど、可変長で渡ってくる引数をどうやって渡せばいい？方法1：auto変数を利用する　Cの関数呼び出しの実装を理解してる人であれば、要はスタック操作だなーというところは見当が付くと思います。わたしが最初に思いついたのはこんなコードでした：char workbuf[BUFSIZE];int log_printf(char *format, ...){ char argcopy[ARGSIZE]; memcpy(argcopy, &format + 1, ARGSIZE); sprintf(workbuf, format); log_puts(workbuf);}　memcpy()でスタック上の引数部分をauto変数argcopy[]に複製します。auto変数はスタック上に取られますから、それがそのままsprintf()の引数として使われる……というカラクリです。sprintf()呼び出し時のスタックイメージはこんな感じ：（ここから上は呼び出し元のスタックフレーム）引数n……引数2引数1戻りアドレス呼び出し元スタックフレームレジスタ待避（現スタックフレームレジスタはここを指す）レジスタ待避auto変数領域：argcopy[](*1)formatworkbuf　ただ、少し難点があります。(1)処理系に依存するレジスタ待避がauto変数領域の確保の後（上の(*1)の部分）に来る処理系が存在し、その場合はformatとargcoptyが連続しないので、sprintf()の呼び出しがうまくいかない。(2)argcopyにコピーするサイズが固定(2-1)main()で呼び出した場合、スタックの消費状態によってはスタックそのものの先頭を越えてコピーが発生するため、そこがアクセス保護されている場合に例外が発生する。(2-2)引数の数が多い場合、argcopyに収まらない場合がある　(2)はともかく、(1)は駄目な環境ではとことん駄目なので、別の方法の方がよさそうです。方法2：構造体を利用する　次に思いついたのがコレ：char workbuf[BUFSIZE];struct _argcopy_t{ char buf[ARGSIZE];} argcopy;int log_printf(char *format, ...){ memcpy(argcopy.buf, &format + 1, ARGSIZE); sprintf(workbuf, format, argcopy); log_puts(workbuf);}　構造体の値渡しは、構造体のイメージそのものをスタックにコピーして渡してしまう実装が多いので、実に素直に引数のコピーが実現できます。方法3：スタックフレームを追いかける　次に問題点(2)ですが、Cの関数は引数の数やサイズを取得できないので、どうしたものか（printf()ではformat文字列を解析して数とサイズを決定しています。C++なら変形後の関数名をデコードする手も）。　悩んだ結果がコレ：char workbuf[BUFSIZE];struct _argcopy_t{ char buf[ARGSIZE];} argcopy;typedef void (*funcptr)(void);int getframesize(unsigned long arg){ unsigned int pre, now, len; pre = *(unsigned int*)(arg - sizeof(funcptr) - sizeof(int)); now = (unsigned int)(arg + sizeof(char*)); len = pre - now; if (len > ARGSIZE){ len = ARGSIZE; } return len;}int log_printf(char *format, ...){ memcpy(argcopy.buf, &format + 1, getframesize((unsigned long)&format)); sprintf(workbuf, format, argcopy); log_puts(workbuf);}　getframesize()は、スタックフレームを追いかけることで、呼び出し元関数のスタックフレームのアドレスを割り出し、そこと第一引数のポインタとの間のサイズを算出します。引数のサイズそのものではないですが、少なくともこれで安全にアクセスできる領域は判断できますので、この範囲で引数をコピーすれば(2-1)は解決します（フレームサイズがARGSIZEよりも大きい場合は単純に切り捨てる）。問題点　問題は(2-2)ですが……構造体のサイズを動的に変更するわけにもいかないので、どうしたものか。これについては、ちょっといい方法が思いつきません。まあ、1引数でせいぜいsizeof(int)しか消費しないので、そこそこ確保しておけば実用上は問題ないとは思いますけど。 Programming mitsuki 2006-08-04T23:32+09:00 https://mitsuki.engawa.org/Programming/20051207_calltrace.html 　謎現象のデバッグ時や、挙動のよくわからないソースをおいかけている時など、どういう順番で関数が呼ばれているのがを可視化（ログ化）できればなーと思うことがよくあるのですが、ちょっとした方法を思いついたので試してみようかな……とおもったら、gccなら-finstrument-functionsというオプションでそういう仕組みが実装可能らしいです。流石gcc。　VCでもBoundCheckerを使えば可能らしいですけど。……そんなもん個人で買えるかっ。　ちなみに上で書いた「ちょっとした方法」というのは、「.o(.obj)のFixUp情報を書き換えて、関数コールの前後で指定関数を呼ぶproxyコードを呼ぶようにしてから、リンクする」という激しく力業な方法。gccやBoundCheckerも多分似たようなことをしているのでしょうけど（勘）、libbfdが使える環境なら自前でも楽勝で書けそう？ただし、わたしのターゲットは16bit OMFですが……orz Programming mitsuki 2006-08-04T23:32+09:00 https://mitsuki.engawa.org/Programming/20051126_gc_vs_malloc.html 　一部で話題の長文コメントのあたりで触れられてる「Javaの理論と実践: パフォーマンスに関する都市伝説を再検証する」の記事。以前ブックマークしたまますっかり忘れてたので、いい機会なので読んでみました。　字義通りに受け取りすぎてしまう人いるみたいですけど、結論から言えば、速いケースは十分あるでしょうね。　記事ではメモリアロケーション処理について論じていますが、「malloc()でヒープメモリ確保」と「（最適化された結果）レジスタやスタックに割付け」を比較すれば、後者のほうが速いのは当然です。こういった差を積み重ねられれば、Cなどでべた書きするよりも、JavaなどのVM系環境の方が速くなる……というのが、動的最適化による高速化の思想でしょうか。　もちろん、最適化ゲインが動的最適化のための統計・分析コストを上回る範囲内にあることが前提です。逆に言えば、全コスト内で占める動的処理コストの割合が、ソフトウェアの巨大化と計算機パワーの増大によって相対的に低下したことで可能になった高速化手法であるとも言えるでしょう（機能ではなく、高速化のための動的化ってのは今まで考えたことなかったな……）。　もちろん、目的に比べて過剰な動的処理を行えば、当然最適化ゲインを食いつぶすだけで高速化にはなりませんし、とりうる挙動が限定されるシチュエーションでは、一般的・汎用的シチュエーション向けにチューニングされた最適化よりも、そのシチュエーションに特化した手作業の静的なコードの方がより効率的に動作するでしょう（静的処理の最後の砦？）。　初期のJavaなどは後者の悪い部分が目立っていたわけですが、計算機パワーの増大と最適化手法の進歩の相乗効果で、最近では前者に転んできたといったところでしょうか。　一方、現在でも後者のシチュエーションを積極的に利用してるのが、いわゆる「組み込み系」ですね。シチュエーションを限定すれば、現在の半導体技術の成果でより小型に、より広範囲にコンピューティングを提供することができるという「イノベーション」の一典型です。　この分野でも、ICチップと無線の融合という形で次のイノベーションが登場しつつありますけど。 Programming mitsuki 2006-08-04T23:32+09:00 https://mitsuki.engawa.org/Programming/20051109_bin20.html 　higeponさんが作られてたので、なんとなく参加してみました。16進ダンプと逆アセンブラをこよなく愛する（やや誇張）身としては、web2.0とかよりこちらの方が面白そうなので:)　でも週末まで身動きできなさげ（しくしく）。 Programming mitsuki 2006-08-04T23:32+09:00 https://mitsuki.engawa.org/Programming/20051027_dync.html 　このへんの話。やりかた思いついたので、VCでやってみました。ソースはこちら。VC6のコンソール環境で確認。　オリジナルとの違いは、define()の第4引数以降をまとめて括弧で囲む必要があること。これは、VC6は（あたりまえですが）C99対応しておらず可変長関数マクロが使えないので、第4引数以降を1つの引数として扱っているためです。これを関数本体の文字列にしているのが asprintf_like() ですが、別段言及するほど特別なことはしていません。　オリジナル同様、単なる力業ですねえ。 Programming mitsuki 2006-08-04T23:32+09:00 https://mitsuki.engawa.org/Programming/20050923_hbatom.html 　某#techでPerl話をしていたところ微妙にPerlが書きたくなったので、久しぶりにごそごそ書いてみました。右上にある「Recent bookmarks」がその成果。　やってることはというと、単に「はてなブックマーク」のatom feed拾ってきて、XML::Parserで抜き出して成形しているだけです。ソースはこちら。blosxom 2.0用です。　……そういえばblosxom3.0ってどうなったんだろう。2005.9.25 追記：　負荷軽減のため、Atomそのままではなく、パースしてHTMLにしたものキャッシュするようにした。毎回XML::Parserしていたのが、Atom取得時だけになったので、大分軽くなったはず。　まあ自宅サーバ（Non MMX Pentinum200MHz）は素のCGI起動が遅いので、あんまり効果ないですが……。 Programming|WebDev mitsuki 2006-08-04T23:32+09:00