昔の最近の出来事(2004.12)

2004/12/31

昼過ぎ起床。寒っと思ったら思いっきり雪が降っていたり。

DでWindowsアプリを書く方法を調べてみたり。D言語のマニュアルにサンプルがあるのですが、gdcでコンパイルするとそのままではコンパイル(正確にはリンク) できませんでした。そんな訳で調べてみることに。
一つは_Dmain()が見つからないというもの。アセンブラソースを出力したりして見たところ、Dでのmain()関数はコンパイラが_Dmain()という名前に置きかえるようで、それが見つからないという感じ。サンプルではWinMain()関数の有無でコンパイラが呼び出し開始関数を切りかえるような事が書かれているのですが、 gdcではそうはなっていない感じ。なので、WinMain()とは別にmain()関数を書く(実際には通らないのでいきなりreturnする空関数で良い)必要があるようです。
もうひとつ、サンプルでは_minit()関数を呼び出しているのですが、これはどこにも見つからないようで、単純に削除してしまって良い感じです。
で、実際にリンクに成功したのですが、実行してみるとMessageBoxを実行しているにも関わらず、そのコードを通りません。空関数にしたmain()関数の方を通っているようなので、WinMain()関数が実行されていないという感じです。gdcの-vオプションで見てみると、ライブラリのリンク順番が -lphobos -lgcc -lcygwin .....となってました。これを-lgcc -lcygwin -lphobos -lgcc -lcygwin という様に、 cygwinライブラリの方を先にリンクする事でWinMain()の方が呼ばれる様になりました。 gdcのphobosがWinMain()呼び出しに対応していないという感じなのかも知れませんが、リンク順序の問題で解決できるならそれで良いという感じかも。

windows% cat wintest.d
import std.c.windows.windows;

extern (C) void gc_init();
extern (C) void gc_term();
extern (C) void _moduleCtor();
extern (C) void _moduleUnitTests();

extern (Windows)
     int WinMain(HINSTANCE hInstance,
		 HINSTANCE hPrevInstance,
		 LPSTR lpCmdLine,
		 int nCmdShow)
{
  int result;
  
  gc_init();			// ガベージコレクタ初期化
  try
    {
      _moduleCtor();		// モジュールコンストラクタ呼び出し
      result = myWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);
    }
  catch (Object o)		// キャッチされていない例外を全てキャッチ
    {
      MessageBoxA(null, cast(char *)o.toString(), "Error", MB_OK | MB_ICONEXCLAMATION);
      result = 0;		// failed
    }
  gc_term();			// ファイナライザの実行、ガベージコレクタ終了
  return result;
}

int myWinMain(HINSTANCE hInstance,
	      HINSTANCE hPrevInstance,
	      LPSTR lpCmdLine,
	      int nCmdShow)
{
  MessageBoxA(null,
	     "TestMessage",
	     "TestMessage",
	     MB_YESNO | MB_ICONQUESTION);
  return 0 ;
}

int main()
{
  return(0) ;
}

windows% gdc -mwindows wintest.d -e_mainCRTStartup -lgcc -lcygwin -lphobos

こんな感じ。元のサンプルの通り、実際のコードはmyWinMain()内に書くという感じ。
とりあえずメッセージボックスは出せるけど他も大丈夫か？というのはまだよく判らず。

そんなこんなで今年ももう終りですよ。という訳で一応回想モード。今年はかなり3Dづいていたようなそんな感じだったように思います。 OpenGL(HairMaker,M-Design,他),Winアプリ,PostgreSQL,Java,D言語という感じ。ちょいちょいCygwinのバグにひっかかったりしてましたが、とりとめの無いのは毎度の事という感じですが(^^; 出張ばかりでまとまった時間が取れないというのはありましたが、来年はもう少しマシになると良いなぁと思います。

そんな所で今年の更新はここまで。それでは良い御年を。

2004/12/30

朝わりと普通に起きて銀行行ったり買い物したり。

phobosのppcクロスコンパイルを少し粘ってみたり。Cygwin用にビルドできる状態にしてから、コンパイラをppcクロスツールに変えて再コンパイルしてみるという事を行なってみました。どうしてもコンパイルできないthreadを使用しているソースはコード自体を潰して、無理矢理libphobosを生成してみたのですが、やっぱり潰した所に含まれるコードをリンクしようとしてしまう為、リンカでエラーしたり。因みに、threadの使用をdisableにするconfigureオプションがあるようですが、それを実際に使うと、それとは全然関係が無いと思われる CLOCKS_PER_SECのチェックで何故かfailするという謎があったりで、世の中うまく行かないなぁと思ったり思わなかったり。

寒くて横になってたらいつの間にか寝倒してしまったり(汗;

2004/12/29

さむっと起きたら雪が降っていたり。暖冬になると言われながらも雪は降るのか。そんな感じ。

先日のgdc-0.8のビルドは終了していたのでインストールして、phobosをビルドしてみたり。とりあえず問題無くビルドできる模様。gdc-0.8を使用してgdc-0.9の phobosをビルドしてみたり。これでもやっぱりエラーする模様。という訳で、 phobosのMakefileを比較してみた所、0.9のMakefileでは以下の様になってました。

#GC_OBJS += gcc/gcgcc.o
GC_OBJS += internal/gc/win32.o

で、0.8のMakefileを見てみると、0.9ではコメントアウトされているgcc/gcgcc.o をコンパイルしているらしく、internal/gc/win32.oはビルドには含まれていませんでした。そこか。で、0.8と同じようにgcc/gcgcc.oをコンパイルするように Makefileを書き換えた所、phobosのビルドは成功しました。

手持ちのソースをいくつかコンパイルしてみた所、簡単なものは特に問題無く再コンパイルできましたが、一つだけリンク時にエラーになるものがあったり。 Cygwinパッケージに含まれているgdcではコンパイル＆リンク＆実行できるバイナリが生成できるので、何か仕様が変わったみたい。

確認してみた所、グローバル変数に「extern int foo」とか書いても通っていたのが通らなくなっただけみたい。具体的には以下のような感じ。

extern_test% cat main.d          
import std.stream ;
import Subfunc;

int main()
{
  _subfuncint=1 ;
  
  stdout.printf("%d\n",_subfuncint) ;

  OpSub opsub = new OpSub() ;

  stdout.printf("%d\n",_subfuncint) ;
  
  return(0) ;
}

extern_test% cat Subfunc.d
extern int _subfuncint ;

class OpSub{
  
  this(){
    _subfuncint=0 ;
  }
}

extern_test% gdc main.d Subfunc.d
/cygdrive/c/windows/TEMP/ccPRZ1wo.o(.text+0x8):main.d: undefined reference to `__D7Subfunc11_subfuncinti'
/cygdrive/c/windows/TEMP/ccPRZ1wo.o(.text+0x1e):main.d: undefined reference to `__D7Subfunc11_subfuncinti'
/cygdrive/c/windows/TEMP/ccPRZ1wo.o(.text+0x7c):main.d: undefined reference to `__D7Subfunc11_subfuncinti'
/cygdrive/c/windows/TEMP/ccEw73ub.o(.text+0xf):Subfunc.d: undefined reference to `__D7Subfunc11_subfuncinti'
collect2: ld returned 1 exit status

extern で_subfuncint というグローバル変数の宣言が行なわれているだけで実体が無いというC言語と同じような解釈と振るまいを行なうみたい。 Subfunc.dのexternを削ってやれば、main.d:main()での参照はimportなどから自動的にグローバル変数_subfuncintを探し出すという振るまいを行なうようで、これは前からそうだったみたいです。恐らく、Cで書かれたコード内で定義されたグローバル変数を、別のDコードから参照する場合はexternが必要で、そういう所で externを端折ると、シンボルがダブっているというリンクエラーになるものと思われます。因みに、TANEがグローバル変数を使用している個所としては、C言語で書かれたモジュール(主にbisonで生成した部分)との接合部分とか、OpenGLなどのイベント駆動で動作する関数が参照するデータなどに使ってたりします。

以前、関数の末尾再帰呼び出しを行なう実験プログラムをgdc-0.9でコンパイルした所、stdinのopen部分でエラーしたり (第１引数にint型が指定されているがchar[]では？という感じ)。どうやら、「stdin.open(0,fmd.In) ;」は無くても良いみたいで、それを削ると正しくstdinが使用できました。で、それをCygwinパッケージに含まれるgdcでコンパイルしてみると、コンパイルは通るのですが、実際にstdinを使用すると実行時にエラーになるようです。

catn% ./a.exe < foo.txt
Error: AssertError Failure /gcc/gcc-3.3.3-3/gcc/d/phobos/std/stream.d(1117)

でも、問題がやっぱりあるようで、0.9でコンパイルした実行ファイルでも、パイプで標準入力を食わせるとそれはダメらしい。

catn% cat foo.txt | ./a.exe
catn%

てな感じで何も反応を見せず。「<」とパイプで食わすのと何が違うのかイマイチよく判りませんが、微妙にダメはダメらしい。
末尾再帰を繰り返すと赤○白×になる点は変わりありませんでした(^^;

ふと思い付きでgdcのPPCクロスコンパイラをビルドしてみたり。 gdc本体はPPCクロスビルドの言語選択にdを追加すれば良いだけで、(多分)問題無くビルドできたのですが、ライブラリであるphobosがビルドできませんでした。 configureが通らないのと、無理矢理通してもクロスgdcでコンパイルするとエラーするDのソース多数。そんな感じで惨敗。
クロスビルドしてて気づいたのですが、Dでは機種依存コードの使い分けやデバッグコードを活かすか殺すかを決めるのに、version()文やdebug()文というのが使用できます。version(linux){statement}とかやれば、Linuxシステムの時だけstatementが活きるという、Cの#ifdef のような働きを行なわせる事ができます。ところが、このversion()文中に指定できるIDが、一体どこで定義されているのか(コンパイラ内部なのか、moduleヘッダなのか、 etc....)が全く判らず、色々みた限りコンパイラオプションなどでそれを知る術が見当たりませんでした。 Windowsでもlinuxでもdarwinでも無い時に活きるコードをコンパイルするときにエラーしているのですが、クロスビルドしたgdcは一体何システム用？という感じになってたり。あと、このversion()文で、OR条件を取る事ができない事にも気づいたり。例えばlinuxとBSDの二つのシステムは共通ソースで、それ以外は違うソースとした場合、version(linux || BSD)みたいなのはダメらしい。勿論両方に同じコードを書けば良いのですが、それは無いだろうと思ったり。

因みに、Cygwin用のmduleヘッダを食わせて、手持ちの適当なDのソースを PPCクロスgdcを使って-Sでアセンブラ出力指定でコンパイルすると、ちゃんと PPCオペコード出力されたので、コンパイラ自体は良い感じになっているような。てゆーか、gdcスゲー。そんな感じ。

2004/12/28

少し早めに帰着。

先日仕掛けたgdcのビルドはエラー無く終了してました。で、make installして、 phobosライブラリのビルドを行なったのですが、エラーしてビルドできず。エラーは以下のような感じ。

phobos% gdc -o internal/gc/win32.o -O2 -g -frelease  -nostdinc -I ../../gcc/d/phobos -I ../../gcc/d/phobos/internal/gc -c ../../gcc/d/phobos/internal/gc/win32.d
../../gcc/d/phobos/internal/gc/win32.d:75: function win32.os_query_stackBottom function expected to return a value of type void*

戻り値を期待しているが、returnが無いみたいな感じの内容なのですが、実際のコードは次の様にインラインアセンブラで書かれていました。

/**********************************************
 * Determine "bottom" of stack (actually the top on Win32 systems).
 */

void *os_query_stackBottom()
{
    asm
    {
        naked                   ;
        mov     EAX,FS:4        ;
        ret                     ;
    }
}

return文は無いのですが、これで値を返してるのと同じ事を行なっているようです。0.8の同じソースと比べてみたのですが、ファイル自体が全く同じな為、コンパイルできない事自体が問題のような気が......
0.8のビルドソースは消してしまっていたので、0.8のgdcを再ビルドしてみる事に。最悪0.8でコンパイルできるなら、このソースだけは 0.8でビルドしてみるという感じかも。

TVをつけていたらWACOMのTVCMが流れてたり。

2004/12/27

日付け越え少し前に帰着。

久しぶりにチェックしたらgdcの0.9が公開されていたのでダウンロードしてみたり。んー、しばらく終りそうにないなぁという事でほったらかしで眠くて死亡。

2004/12/26

昼過ぎ起床。寒くて死亡。我が家は何故かエアコンが入っているのに外気よりも寒い気のする時があったりして謎。

先日のテストはやっぱりダメっぽい。ハング状態に陥る場合もあるようで、 20041224よりも少し悪くなっているような気が。少しソースをいじってみたのですが、あまり反応を見せず。むーん。

M1グランプリ。今年はやっぱりアンタッチャブルが来ましたか。笑飯は去年の準決勝のネタで死ぬほど笑った記憶があるのですが、今年は今一つパワーが感じられなかったように思います。アンタッチャブルは去年と変わらずテンション上がりっぱなしで持っていった所があったように思いました。

2004/12/25

昼過ぎ起床。

Cygwinスナップショットの新しいので、プロセス管理周りのソースがいじられていたので、ダウンロードしてみました。ビルドしてテストした結果では、ハング状態に陥る事は無くなったようですが、defunct状態のプロセスが残ったままになる問題は解決されていない模様。もうひといきという感じ？

20041225版が出ていたので、そちらの方もビルドしてテストしてみたり。終りそうにないのでほったらかしで眠くて死亡。

2004/12/24

日付け越え。

微妙に穴が空いてそうな所を塞いでみたつもりだったけど、やっぱりダメでした。

SAIの新版が出た模様。

2004/12/23

AM起床。でも具合が悪くなって一日中寝てたり。

ゾンビになる瞬間の部分にデバッグプリントを仕込んで通過するのかどうか確認してみました。一応、どのプロセスでも、一度は必ずそこを通過するようで、psコマンドでdefunct状態がなかなか見えないのはほんの一瞬でゾンビステートが終了してしまうからの様に思われます。ただ、先日試したdefunct状態を作り出す方法で何故defunct状態が見えないのかは謎のままですが。という訳で、defunct状態のまま残り続ける条件を想像してみたり。

本当は親プロセスの方でwait()による待ちは成功し、子プロセスの終了を確認しているが、なんらかの原因により子プロセス削除がうまくできない。
子プロセスのステートを変更している間のクリティカルな瞬間に、プロセスリストからその子プロセスを参照できない事があり、親プロセスの終了時に参照できない子プロセスが残ったままとなる。

感じとしては後者っぽい事が起こっていそうな予感。これまでの実験から、

子プロセスよりも先に親プロセスがexit()した時、親の居なくなった子プロセスは PPID=1を親プロセスに切りかえる。なのでゾンビで残ったままになる理由が無い。
親プロセスがwait()で子プロセス終了待ちになる前に、wait()待ちされる予定の子プロセスが終了した場合でも、psコマンドによるプロセス一覧には終了した子プロセスがdefunct状態で表示される事が無い。

という事が判っています。defunct状態がpsコマンドで見られるのは、大量のプロセスがパイプなどにより生成された場合が多い様で、そこん所に何か秘密があるのかも知れません。因みに、「gawk 'BEGIN{for(i=0;i<100000;i++){printf("%d\n",i);}}' | grep '^' | grep '^' ....30回くらい繰り返し..... | grep '^'」みたいな事をやれば、最後のgrepを通ってターミナルの文字列が出てくるまでの間に比較的簡単にdefunctをpsコマンドで見る事ができるようです。ただし、これくらいでは不具合再現しないようですが。

ゾンビステートをチェックしている部分を探ってみたり。sigproc.cc内でプロセスリストから削除する際のチェック時に参照されているのがそれの様で、他では使われていないという感じ。で、checkstate()という関数で、子プロセスが終了しているか止まっている場合をチェックし、いずれかの場合にはプロセスリストから削除するという動作を行なっているようです。なんとなくここん所に秘密があるような気が。仮にcheck中に子プロセスが終了していない場合、プロセスリストから削除はされません。check後、親プロセスが消える前に子プロセスに制御が移って(本当は移ってはダメなのでしょうが)、ここで子プロセスがdefunctになったとすると、親プロセスは子プロセスが終了していないと思っており、且つ子プロセスは自分はゾンビ状態で親プロセスがまだ居ると思っているという状態が生じます。しかし、この後、親プロセスは死んでしまう為、子プロセスは親が死んだことを知らないままwait()で回収されることを待ちつづけるような状態が生じるのではないかと。
どうやら、プロセスが死ぬときしか子プロセスの削除処理が行なわれないようなので、これと前述のような矛盾がもし生じたとすると、exec状態時に親が居なくなる場合は PPID=1に遷移する事は可能だとして、defunct状態だとそれができないとすれば、 defunct状態で残り続けることになるのでは？と。あくまで想像の範囲内ですが(^^;
定期的にプロセス状態をチェックするような機構を設けて、親が居なくて且つdefunctなプロセスを完全に埋葬してやるようにすれば、大丈夫な気がしなくはありませんが、動作矛盾が生じること自体が問題だとすると、そこんところを修正する必要がありそうです。

2004/12/22

日付け越え。

fork()した時の子プロセスの親プロセスIDの挙動を調べてみたり。 fork()でいくつかの子プロセスを生成した後、wait()を実行せずにそのままexit()した時、psコマンドでプロセス一覧を見てみると、親の居なくなった子プロセスのPPIDは 1 に切り替わるようです。 UNIXで言う所のプロセス「init」の配下に切り替わるという動きを模しているようです。うーむ、ますますdefunctになるきっかけというのがどういう事なのかよく判らなくなってきましたよ。

2004/12/21

日付け越え。

defunct状態で死ぬのを再現させる為、ちょこちょこ試してみたのですが、うまく再現させる事ができず。psコマンドに仕込みを入れて、 PID_ZOMBIEとPID_EXITEDのいずれかを区別できる様にして、今の所再現性が高いcygwinのconfigure実行を行なってみたのですが、何故か捕まえる気マンマンの時に限り再現せず....... とか書いていたら再現。どうやらゾンビ状態でつっかかっている模様.....

      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
I 1766595       1 1766595 4293200701  con  500 00:53:47 /usr/bin/BASH
  1709923 1766595 1709923 4293257301  con  500 00:55:33 /cygdrive/c/TANE/BIN/RXVT
  1783259 1709923 1783259 4293185533    0  500 00:55:33 /usr/bin/BASH
  1730631 1783259 1730631 4293127093    0  500 01:29:11 /usr/bin/MAKE
  86552687 1730631 1730631 4208427889    0  500 01:29:14 /usr/bin/sh
  1435159 1575647 1730631 4293532137    0  500 01:33:51 <defunctZ>
  86229391 1575647 1730631 4208737905    0  500 01:38:58 <defunctZ>

defunctZはゾンビ状態を示しています。defunctZとなっている二つのプロセスの親プロセスIDは 1575647なのですが、そのプロセスは存在しない為、親プロセスが先に無くなっているという状態に陥っています。PID=1766595のBASHから PID=86552687の/usr/bin/sh までは親子関係が繋がっているようなので、 PID=86552687の/usr/bin/shの生成した子プロセスでどうにかなったという感じかも。この状態で、PGIDの親となるPID=1730631の/usr/bin/MAKEをkillしてみると、 /usr/bin/MAKEとその下の/usr/bin/shは消えたのですが、ゾンビはそのままになりました。
再現を狙ったプログラムは、親とその一代下の子の二代目までの関係しか作らなかったのですが、三代目、四代目まで家系を増やすと何か起こるのかしら？

2004/12/20

日付け越え。

Webで調べもの。fork()とwait()とdefunctの関係について。 defunct==既に死んでいるの意味だというのに先日まで気づいていなかったというのがあまりにも恥ずかし過ぎるというのは置いといて(汗; wait()で子プロセスの状態が回収されなかった場合にdefunct状態となるのは先日書いた通りなのですが、調べてみると親プロセスが死ぬとその状態を受け取る人が居なくなるので、自動的にdefunct状態となるプロセスは無くなるという事が書かれてるページがありました。まぁ、これはinitに引き取られるという事のような気がしなくはありませんが、それは一般的なUNIXでの話だとして、ゾンビプロセスを作る方法というのがあったので、それを使って様子を見ると何か判るかもという事でサンプルプログラムをコンパイルしてみたり。

やっている事は簡単で、

fork()する。
子プロセスはすぐに終了。
親プロセスはsleep()で数秒寝た後、wait()を実行。

この時、2と3の間に、子プロセスがゾンビとなる期間が存在する為、 psコマンドで見るとdefunct状態が見れるハズというものです。所が、何故かpsコマンドでプロセスを見てもdefunct状態が表示されず、見かけ上、子プロセスは終了と同時にプロセスリストから削除されているように見えました。でも、wait()で子プロセスの終了コードは正しく取得できるようなので、Cygwinではdefunct状態になる事自体がハマりパターンなのか？とも思ったり。しかしながら、configure実行時にはつっかかったままではない正しい defunct状態を見る事ができたので、何かしらの再現方法はあるハズなのですが.......はて.........

2004/12/19

起きたら午後もいい時間になっててびっくり。

APPLESEEDのコメンタリーを観たり。先日１回目を観た時、オープニングの OLYMPUSの背景絵を見て、えらく細かく描かれていたのに驚いたのですが、とにかく背景モデルの物量がものすごいと感じてました。実際コメンタリーでもここまで作り込んだのは凄いという事が語られてました。他、モーションキャプチャで取りこんだ動きも、実際にはそのまま使えるものは無くて相当動きを調節しているだとか、アニメと違って役者が居るので、実写映画の製作手法に沿ったとか、へぇへぇ言いまくりという感じでした。個人的に、「モーションキャプチャ＋トゥーン」つまりリアルとデフォルメの両立ってうまくできるの？しかも長編の映画で？って所に眉をひそめている所があったのですが、キャラクタの微妙な感情を表すような表情(眉の動きとか口元の上がり下がりとか)が(TANEの主観ですが) 良く描けている為、モーションキャプチャーによる動き付けに負けていなかった結果、トータルとしてうまくマッチしている様に思いました。

Cygwinの新しいSnapshotが出る度にビルドしてみているのですが、 configureのようなプロセスを生成しまくるような動作でCygwinのそのシェル自身がハング状態に陥る現象が解消される気配が見られず。ハング状態に陥った時に他のCygwinウインドからpsコマンドで見てみると、

     PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
 1427479 1472379 1472379 4293539817    0  500 23:58:07 <defunct>

てな感じでdefunctという状態のままつっかかるケースが多い様です。 configureが動いている最中にpsコマンドで見ていると、この defunct状態というのは結構出てくるようで、プロセスが生成された直後の状態だとかそういうのを示していそうな予感。因みに、この状態だとkillコマンドで殺す事ができず、Windowsのプログラムの強制終了の一覧にも出てこない為、Windowsの終了がうまくできない状態になっています。

Cygwinのソースより、defunctという文字列をgrepしてみると、 fhandler_process.ccにその文字列が含まれており、その辺を見てみると、プロセス状態が PID_ZOMBIEかPID_EXITED の時、defunctになるらしい。 psコマンドだと、ZOMBIEなのかEXITEDなのかは区別が付きません。で、PID_EXITEDを入れているところを見てみると、 pinfo.ccの_pinfo::exitってメソッドの中で行なわれているようで、そこん所に、

      /* FIXME:  There is a potential race between an execed process and its
         parent here.  I hated to add a mutex just for this, though.  */

てな感じの怪しげなメッセージが。まずはZOMBIEなのかEXITEDなのかを調べてみるところから始めるのかしら。
ところで、ZOMBIE状態というのは子プロセスが消滅する際、親プロセスが子プロセスの死を受け止めるまでの子プロセスの死体状態の事を指します。いきなり無くならずにゾンビ状態という変な状態になるのは、親プロセスが、死んだその子プロセスのPIDやexitステータスを取得する(wait()システムコールを実行する)前に勝手に消滅すると、それらの情報が取り出せなくなるという理由があるのでしょう。また、シグナルのようなもので割り込みをかける方法で、子プロセスの死を通知するような方法も考えられますが、いつ何個のプロセスが同時に死を通知するとも限りませんので、割り込み処理中に割り込みがかかった時とか、考え始めるとユーザープログラムのシグナル処理の方が難しくなる事も考えられるでしょう。で、例えば、子プロセスよりも親プロセスが先に死に、子プロセスの死を受け止める事ができない場合に、その子プロセスはゾンビプロセスとして残ったままになります。一般的なUNIXシステムでは、このゾンビプロセスの埋葬は全プロセスの産みの親であるinitプロセスに託され、定期的に埋葬が行なわれることになっているようなのですが、Cygwinでゾンビプロセスが残るような状態になった時は、一体どうなるのかしら？

2004/12/18

割と普通に起きて休出(T_T)。日付け越え前に帰着。

バーンアウトの高速ラップイベントにハマり中。要は単にミスらずにゴールすれば良いだけ。でも、対向車線を走ってブーストを稼ぐなんて事を考えるとすぐにクラッシュ(^^; ルールは単純ですが簡単では無いので、思わず何度もリトライしてしまう所が、麻薬です。

モンキーターンＶ最終回。いやー、面白かったぁそんな感じ。新番組「ギャラリーフェイク」って......えぇっ！マジっすか！？

買って積んだままになっていた「APPLESEED」のDVDを観たり。原作は士郎正宗のマンガなのですが、実は原作は一度も読んだ事無いというモグリなもんですから、全く前知識無しという状態で観ました。一回観た感想としては、「全然普通に面白かった」という感じです。難解な感じは一切ありませんでしたし、ストーリーのテンポも良く、見せ場もしっかりしていて、アニメ映画というよりは普通の実写映画のような、非常に良くまとまった作品に感じました。

2004/12/17

日付け越え。

ゲームをちょろっとやって死亡。

2004/12/16

日付け越え少し前に帰着。

眠くて死亡。

2004/12/15

日付け越え。

ちょろっとゲームやったら眠くて死亡。

2004/12/14

日付け越え。

ども、地上波デジタルを考慮に入れると確かにその通りですね(^^; 地上波デジタルチューナー内蔵のものも少し考えてはいたのですが、買う段になってすっかりその事を忘れていた次第です(^^; 「液晶だから立て置きも.....」は私も考えたり(^^;;; 固定する手段が ......も同じ事を思ったり。そんな感じです。電源切っても静かにならないというのは私も同感。あれ、何故なんでしょうね？

2004/12/13

大幅に日付け越え。

「爆笑問題のススメ」に渡辺浩弐氏が出てました。中野系なんて初めて聞きましたよ。そういや昔、渡辺氏が D's garage21という番組に出ていたのを思い出したのですが、その番組に桃井はるこという生業が良くわからない娘が出てました。今日の「ススメ」の方でも「萌え」という言葉が頻繁に出ていたのですが、TANEの知る限り、この桃井はるこ嬢が「萌え」を発音して公共の電波に乗せた最初の人類(＜大げさ)だと記憶しています。最近では、なにやらギャルアニメだかギャルゲーだかの歌を歌っているだかなんだかで、その筋では有名になっているらしい。

2004/12/12

昼頃起床。

バーンアウトのクラッシュイベントにはまってみたり。繰り返す度にディスクロードが発生するのが少し辛いところなのですが、イイ感じにクラッシュできると爽快です。

そんな感じでサイヴァリア２の方も見てみたり。攻略DVD付きで、そちらの方から見たのですが、BUZZチェインを繰り返して弾を撃たずに進む感じがサイヴァリアという感じ。そうは言ってもやっぱスゲー感じのプレイで、死角や隙間にぴったり位置付けしているので、全くマネできる代物ではありませんが(^^;
で、ゲームの方をちょろっとやってみたのですが、BUZZチェインがうまくできない素人には、あんま面白い感じになってないです。絵は綺麗だし、弾幕もカラフルで良いのですが、序盤から結構厳しい感じになっていてちっとも先に進める気配がしません(^^;そんな感じです。

とかやっているうちに眠くなって横になったらそのまま爆睡こいて一日終了。ダメだこりゃ。

2004/12/11

昼前起床。

Cygwinスナップショットの新しいのが出ていたのでダウンロード＆ビルドしてみたり。先日の様に、makeで死ぬような事は無くなりましたが、 Cygwinスナップショット自身のビルドを行なうと、configure実行で無反応ハング状態に陥る模様。結局、まだ直ってないのかも。それよりも、 fork.ccはちょっといじられるとすぐに不具合が出るようなのですが、 Win98だとNGだけどそれ以外だと大丈夫だったりするような直し方をされる場合がある為、大多数で動くとしばらく直らないという事があるのが不安なところ。

Webをぐるぐるしていると、以前試して表示がうまくなかった PoseRay の新しいのが出ているのを知り、ダウンロードしてみたり。以前のはOpenGLの表示に不具合があり、プリビューがうまくできませんでした。今回のはそれが直っていたので、ちょっとだけ使ってみました。様々なレンダリングオプションを設定できるようなのですが、何故かカメラ位置の自由度が非常に低く、注目点を移動できないので、目的の位置をアップにできないとか、微妙な点で使いにくさがあるようです。カメラアングルの点を除けば、テクスチャを差し替えたり、オブジェクト毎にSubdivision分割設定を変えたり、色々な事ができるようなので、毎回形状以外の環境も上書きされるWingsでの出力よりは、オブジェクトの配置設定などが簡単になりそうなのですが......

そういえば、.OBJという3D形状ファイルのフォーマットがあるのですが、今までテキスト形式という事に気づいてなかった為、気にかけていなかったのですが、POV形式を読むよりもこちらの方が良いかもと一瞬思ったり。でも、

カメラの設定は無さげ。あくまで形状ファイルという位置付け。
WingsでExportすると多角形ポリゴンがそのまま出力される。

という点がちょっとだけ微妙。でも、後者はWingsのプラグインをいじる事でどうにかなるかもという予感。というのは、三角形ポリゴン分割するサービス関数があり、RIBやPOV出力はそれを利用しているようなので、その関数を一発はさんでやれば良いかも。
そんな訳でWingsのソースを眺めてみたり。どうやら.OBJ形式への出力コードの本体はe3d/e3d_obj.erlに書かれているようで、pluginは単純な関数呼び出しだけしか入っていませんでした。で、形状出力の始めの方に e3d_mesh:triangulate()という関数を一発挟んで終了。でも、それだとあまりにもなので、ダイアログの表示具合や文字列を参考に、三角形分割の OFF/ONを切りかえるチェックボタンを追加してみたり。

DVDを買いにいくついでにゲーム屋に寄ってみたり。以前から少し気になっていた「バーンアウトテイクダウン３」を手に取り、ウロウロしていたら「サイヴァリア２」のPS2版が出てたりして、「もう出てるんだっけ？.....あぁ、12月発売だったか」とか思いながら買ってみたり。
で、バーンアウトの方。車ゲームなのですが、クラッシュだとかの破壊に重点を置いたゲームです。ゲーム中のモードは二つあって、一つはレース中にライバル車を押し当ててクラッシュさせたりしながら順位を競うもの、もう一つは交差点などを走っている車列の中に突っ込んで、クラッシュの派手さ(被害額)を競うものがあります。洋ゲーっぽい大味なバカっぽさがあるのですが、とにかくゲーム中のクラッシュシーンの絵がよく出来ていて、自車がベコベコになるのは勿論の事ながら、ノンプレーヤーの車が玉突き衝突を起こしたり、トレーラーの荷台の荷物が崩れたり、力に応じて横転したり、外れたタイヤが転がっていたりと、今までのドライブシミュレーターなどでは無視されていた部分が細かく描かれている所がスゲーです。背景なども GTや先日書いたENTHUSIAなどのような上品さはありませんが、細かな書き込みで、かなりごちゃごちゃしている(停車している車も背景オブジェクトの一つで、それにクラッシュ判定があると考えると相当複雑)にも関わらず60fpsで回っており、かなり気持ち良い絵になっていると感じました。そんな訳でしばらく遊んで眠くて死亡。

2004/12/10

飲み会から帰ってきたら3:00で即死。

2004/12/09

日付け少し前に帰着。

先日仕掛けたCygwinビルドは途中でfork()のエラーが出て止まっていたり。再度makeを実行し直して取りあえずDLLはできたり。で、入れ替えて使ってみたのですが、なんでもないソースをmakeでビルドすると、どうもプロセスのハング状態を検出するようで、まともに動かず。fork.ccに大量に変更が入っていたので、それで壊してしまっているらしい。ただし、Win98での話なので、XPとかだと大丈夫なのかも知れませんが。

2004/12/08

日付け越え。

Cygwinスナップショットのビルドを仕掛けて死亡。

2004/12/07

日付け越え。

ちょろっとWingsのソースを眺めて終了。

2004/12/06

日付け越え。

少しErlangが読めるようになった気がするので、Subdivision(Smooth)をどの様に行なっているか眺めてみました。でも、まだ読み足りないようで、イマイチやっている事がよく判らず。そこで、６面体を簡易スムージング表示にして辺や頂点の分割位置や頂点の移動を観察してみたり。辺は全ての辺を半分にする位置に新しい頂点を生成しているのが判るのですが、その位置の決定方法はどうも良く判らず。

2004/12/05

普通に朝起床。そしてTV待ち。

TV待ちの間にPixieでシェーダーを書いてみたり。先日の髪の毛のアルファを抜く為にテクスチャのアルファチャンネルをアクセスする方法を調べてみたり、色を調節してみたり色々。他プラグインもちょいちょいいじってみたり。プラグインの出力するReadArchive文にファイルが絶対パスで指定されているのを変更してみたり(ファイルを動かすとエラーするから)。細かい変更を加えていると、だんだんオレプラグインになってきている予感がしなくもありませんが、気のせいでしょう(^^;
そんな感じで、いくら待っても到着の気配無し。時間指定できないとこういう状況に陥るのがイヤなのですが、うっかり出かけてすれ違いになるのもイヤだしという事でぐにゃぐにゃ過ごしたり。途中寒さで布団にこもったら眠くて死亡。でもこの間に来たらまずいというので、必死で我慢。
そんな感じで次のような感じ

Pixieレンダリングテスト４

ライトが強過ぎて色が飛び気味な感じ。後、目玉のハイライトを出したかったのですが、どうもうまく出す事ができず。POVとかだとライトの反射でむしろ消すのが難しいくらいなのですが、何かうまい方法があるのかしら？
ファイル出力のみで、画像ビュアーで結果を見ていたので全く気づきませんでしたが、裏向きポリゴンの透明抜きがあまりうまくない感じになってます(^^;　しまったそんな感じ。

待つこと12時間。やっと来ましたよ！って言うか、すっかり夜ですよ！！そんな訳で、X68kモニターとはここでお別れ。引きとってもらう事にしました。で、一週間ぶりのTVですよ！家の部屋の広さではやっぱ20インチくらいが収まりが良いです。そして液晶だから薄い！場所取らない！これで少しは掃除がやりやすくなるかもそんな感じです(大して綺麗にしてる訳でもないですが)。思っていた以上に表示が明るく、色も変では無いので満足です。そんな感じ。

やっとこTVもDVDも観られるようになった所でファミ通WaveDVDを見たり。今月はこれって感じのはあまりありませんでしたが、Konamiのドライブシミュレータ「ENTHUSIA」のデモで、実車と同じような走り方をしたときの挙動の比較というのが面白かったかも。うまいところだけを切っているのかも知れませんが、実写映像とゲーム映像とほとんど同じ感じになってます。免許の無いTANEが言うのはなんですが、非常に良くできているように感じました。

遅くなってしまいましたが、SAIの６版を触ってみました。全レイヤーの合成値から領域選択が行なえるようになっていたり、細かいところで使い勝手が良くなっていると思います。今回も絵無しでスマソ。
そういや一度だけスペースキーがセンスされない現象が再現しました。突然の事だったので、手順とか全く覚えて無いのですが、何かしらのタイミングに依存しているのかも。

2004/12/04

昼前起床。

ちょっこりErlangいじり。思いつくものを色々試してみたのですが、速くはならず。ギブアップ気味。

余談ですが、Erlangではリストの先頭の事をHead、その後ろ全てをTailと呼ぶようで、サンプルでも「[H|T]=List」というような取りだし例が書かれています。同じ関数型言語のLISPでは、リストの先頭をcar(カー)、その後ろ全てをcdr(クダー)と呼ぶような事を聞いていたので、この日記でも「[CAR|CDR]」などと書かれています。この呼び方を知ったのは、大昔に、EmacsLISPでオレテキストモードを作る必要に迫られたとき(＜迫られた時は大抵本物お仕事用)です。LISPの本にはそれが書かれていなかったのと、その本ではEmacsLISP特有の書き方が判らなかったので、 WebでEmacsLISPの日本語訳マニュアルを探し当てたのですが、その中に書いてありました。因みに、当時参考にしたLISPの本を今見てみると、再帰で1～nまでの合計を求める方法とか書かれていましたが、「forとか使えるのに何故再帰で表現する必要があるのか？」というような理由(だと思う)からか、すっかり脳味噌内から消去されてました(^^;

TVを購入しに近所の量販店に。その場にあるのを色々見た結果、 AQUOSに大決定ですよ。20インチの4:3って所が庶民派なのですが、値段はあまり安くも無い(むしろ高い)という感じ。おおよそ 10万円という買い物だったのですが、後で計算してみると、10年使えるとして、「10,000円/年==約274円/日」って計算になり、「やっぱ思ったより高いわ。」と思う反面、PCやエアコンの方がまだ高いよという気もするので、あれ？やっぱり安いのかなぁと思ったり思わなかったり。因みに、プラズマの50インチクラスで現行機種だと500,000円が相場みたいなので、10年使って約1,370円/日となり、「毎日少し安値の映画を見ている」と思うと高いなぁと思ったりもするのですが、毎月何かしら買っている、ちゃんと読んでるんだかどうだか怪しい高額書籍の総金額はもっと上だったりする辺りに、ダメ金銭感覚っぷりを自覚してみたり。
帰りにゲーセンに寄ると、「鉄拳５」と「虫姫さま」が置いてあったり。鉄拳の方は、ちょっと見た感じ、これは！といった目新しい絵は特にありませんでした。虫姫の方は、ゲームレベルが選べる辺りに、間口の広さを感じてみたり。そういやこんなの今までありそうで(練習モードと称した死にまくりOKだけど進める所は限定されているというのはありましたが)無かったなぁと。一回だけやってみましたがTANEにはかなり厳しい感じ(@マニアックモード)です。結構インカム高めな感じだったので、ちょいちょい見に行くとそのうちスゲーのが見られるかもという事で少し楽しみ。

2004/12/03

日付け越え。

Erlangいじり。
もしやこれがという遅くなりそうな要素を色々変更してみました。

ListをTuple化してみる。
→[CAR|CDR]=LIST 記述で先頭とその後ろを切り出していたのですが、「もしやリスト操作が凄い遅いとか？」という点でTupleにしてインデックスアクセスする様にしてみました。でも実行速度は全く変わらず(T_T)
予め全頂点インデックスをRIBのそれと同じ様に展開して保持しておき、 foreach()を使って回すようにしてみる。
→foreach()に特別なチューニングが入っていれば速くなるかと思ったのですが、やっぱり速度は変わらず(T_T)

そんな訳で、どこで時間を食うのかを見てみることにしました。
ファイル出力をコメントアウトしてみたのですが、実行速度はそのままでした。従って、io:format()出力が異常に遅いとかそういうのではなさげ。で、色々削っていくと、最終的にfaceの頂点インデックスをバラすループを入れるか外すかで、速度が変わる点になっている事が判りました。って、そこ一番重要な部分なんですが(^^; そんな訳で、基本的な書き方で遅いとなると、これぁ一体どうすりゃ良いのやらという感じ。なんとなく「我慢する」に一票という所か？

眠くて死亡。

2004/12/02

日付け越え前に帰着。

Erlangいじり。
先日の時点でインデックスを引くところまでの実験コードが書けていたので、RIBのフォーマットに合う様に出力を整理したり。頂点、法線、テクスチャと、一瞬同じコードで入力を変えて出力可能な感じに思ったのですが、頂点と法線は何故か元データがそれぞれlistとtupleという感じで違っており、また、テクスチャは座標が二次元という事もあって、ちょっと違う同じようなコードを並べるハメになったり(^^;

そんな訳でどうにか法線付きのRIBを出力できるようになりました。

Pixieレンダリングテスト３

でも、出来あがるRIBファイルは大したサイズでもない(せいぜい7MB程度) のに、出力にかかる時間が異常に長いです。既にあるデータをインデックスを引きながらテキスト出力するだけなのに、数分を要するというのは一体どういう事なのか？という訳で、パフォーマンスチューニングの方法が課題かも。そういや、POV出力もSubdiv分割数を増やすといきなり出力に時間が猛烈にかかるようになったのも、改善の仕方が無いのかなぁと思ったり。

2004/12/01

日付け越え。

BBSにて色々御教授いただきありがとうございます(＞たぼさん)m(_'_)m TANEの脳味噌の処理が追いついてないので、返事が遅れます。

Erlangいじり。
メモ２。

データ構造にlist([...]で記述する)とtuple({...}で記述する)の２種類があり、listはシーケンシャルにしかデータを取り出す事ができないが、 tupleはelement()関数を使用してインデックスアクセスを行なう事ができる。
tupleは追加や削除はできないらしいが、setelement()で内容を書きかえる事はできるらしい。
list_to_tuple()関数を使用すると、listをtupleに変換できる。 listになった頂点テーブルをインデックスアクセスしたいときに有効。

そんなこんなでなんとかデータの取り出し方が判ってきた感じ。
エラーした際、Erlangのコンソールウインドにエラーメッセージが出てくるのですが、実際にエラーしている個所を指している訳ではない場合があり、非常にややこしいです。例えば、element()関数に誤ってリストを食わせてしまった時、「badarg」というエラーが出るのですが、element()関数を使用している関数名までしか出ず、「element()の引数がよろしくない」という点が出てこない為、そういうものだと判るまで、何がどう悪いのかさっぱり判りませんでした。先日のif文の条件抜けのエラーもメッセージ自体が意味が判らず、色々書き換えて反応を見て、こうらしいという事が判ったという感じで、全体的にエラーメッセージが不親切な感じがします。

TOP PREV