早くも無く遅くも無く。
GT5。もうちょいを繰り返すとやっぱり時間が吸われている罠。
そういや、レース中などはコースにライン取りのガイド表示が行われてます。
減速表示もリアルタイムに行われるのですが、何気にその指示通りに
操作すると意外とうまく走れる感じになってるようで、なかなかの優れものだと
思ったり。
早くも無く遅くも無く。
GT5。ライセンスとか、数十秒で終わるけどなかなかゴールドトロフィー
が取れないのを何度となくやってるといつの間にか時間が吸われています。
そういえば、先日 HDDをBDのキャッシュに使って徐々にHDDにコピーを....と
いうような事を書いたのですが、コースデータや車データなどはそのような
方法でHDDをキャッシュにしているようです。というのは、新しいコースを
走るような場合、右下に「インストール」という表示が行われています。
この辺が用事のあるデータを徐々にインストールしている感じになって
いるんじゃないかと推測しています。本当の所はどうなのか定かではありませんが。
仮にそうだとして、それでも最初に30分以上かけて初期インストールしなくては
ならない要素があるという事なのか？
AM中に起床。
アパート契約の更新手続き。事前に書類を用意してたのでスムーズに終了。
何気にGT5を買ってみたり。HDDインストールを最初に促されたのですが、
30分くらいかかったり。8〜10GB分をコピーするとの事だったので、
流石にそれくらいかかるのはいたしかた無いのですが、
一気にインストールする方式ではなくて、HDDをBDのキャッシュに使用する
形で、ゲームを進めて行く過程で徐々にHDDにコピーしていくって感じに
できなかったのかなぁ？と思ったりも。
で、ゲームで遊ぶのはHDコンセプト以来なのですが、絵の方はHDゲーム慣れしている
せいか改めてスゴイと感じる点はあまりなかったかも。パッケージ版としてはGT3以来
なのですが(何故か奇数ナンバリングしてやってないのに気づいた(^^;)、
レースゲームという特性上、オフラインでのゲームには極端に新しい要素は
無いように思いました。まだ触りの部分しか遊べていないので全体を語る
事はできませんが、なんとなくいつも通りのGTシリーズという感じがします。
そういや、フォトモードの絵は何気にスゴイと思いました。もうちょい性能が
あれば、あのレベルの絵で動かせたのかもなぁと思ったりもする訳ですが、
次世代機以降に持ち越しといった所でしょうか。
AM中に起床。
新作パックマン。ひとまずトロフィー全部ゲット。何気にタイムトライアル
をやってると一回のプレイ時間は凄く短いのに、あとちょっとと繰り返して
いると意外と長い時間やってたり。ちょっと遊ぶには丁度良い感じでした。
気持ち早めに帰着。
あまりの眠さに死亡。
早くも無く遅くも無く。
新作パックマン。ボチボチ進めたり。
早めに帰着。
「パックマン チャンピオンシップエディションDX」を買ってみたり。
ナミュー.commのパックマンではちっとも上達しなかったのですが、
以前にも書いたように、
「敵の動きを誘導できない/動きのパターンがイマイチ読めない」という点が
どうにもやりようが無いという感じでした。で、新作パックマンな訳ですが、
どうにもやりようが無い点をうまく克服できるようなフィーチャーにより、
なかなか遊べる感じになっていると思いました。ランキングはスコアアタックや
タイムアタックがメインとなっているようで、これが5分や10分と程よい時間で競うのも
個人的に良い感じです。気になるのは、何故Full-HDじゃないんだろう？
という点でしょうか。
昼頃起床。
先日のgdcビルド。Fedoraの方ではエラー無く終了。cygwinの方はcc1dのリンクに
失敗するので手動でごちゃごちゃと対応。終わらず。
homeで久々にチャット。そういえば先日のアップデートでテキストチャットにいくつか
のモードが付きました。複数のチャンネルに接続できて、例えばクラブのグループ
内の人達と離れた場所でチャットできたりするようです。でも、リモートチャットは
誰がしゃべろうとしているのかよく判らない為、同時発言が頻繁に発生します。
やっぱり普通のフキダシの出るタイプが一番良いって事で落ち着いたり。
cygwinでのgdcビルド。結果から言うとICE落ちする点は解決せず。古いphobosを
使うという手が断たれてしまったので、やっぱりどうにかして新しいphobosを
使えるようにするしかないのかも。
少し遅めに帰着。
2.050マージ版のgdcのビルドを試してみることにしてみたり。終わらず。
VMware上のFedora14でも2.050マージ版のgdcビルドを試してみたり。
ディスクの空きが少なくなっていたので、以前ビルドに使用したファイルを
圧縮したのですが、圧縮後のファイルが200MBオーバー(オリジナルのアーカイブ
はgcc-4.4.5.tar.bz2で 60MBくらい) とやけに大きなファイルになっていたり。
確かにgcc/libbackend.aが50MBを越えていたり、コンパイラ本体が30MBを越えていたり
するので、そういうサイズになるのかなぁ？と思ったりもするのですが、
それにしても大きすぎます。
AM中に起床。
先日のmake installがうまくいかないのは原因がイマイチよく判らなかった
ので、make cleanして再度makeしたり。終わらず。 そういや、stage[1-3]-*
みたいなディレクトリが沢山できてて、何度も同じのをコンパイルしている
ようにも思えたのですが、これって何だ？
無理矢理インストールしてみたのですが、適当なソースを食わせるとICEで
落っこちたり。少し粘ってみましたが、どうにもならなくて終了。
AM中に起床。
libphobosでコンパイルできなかったのが、internal/object.dだった
のですが、どうにも原因不明で結局これだけを前のコンパイラでコンパイル
して、.oファイルだけを作ったり。その後も色々なソースでコンパイルエラー
出まくりだったのですが、どうにかエラーを全て潰してlibgphobos.aを
生成する事ができたり。でも、make installがなんだかできなくて謎。
そういえば、「this」を任意の型のポインタにキャストするような
コードがいくつかあったのですが、どうもthis自身の意味付けが変わっている
模様。例えば、「(*this)[i] = b;」というようなコードではエラーと
なり、「this[i] = b;」とする必要がありました。
thisがポインタ変数と同等の扱いになったように思います。
以前ウインドクラスのインスタンス
へのポインタをキャストするのに、ごちゃごちゃやった記憶があるのですが、
この辺も少し変更しないとダメかも。
とかやってたら、なんとdmdの2.050がマージされていたり！
「それでも町は廻っている」の原作本を読んだり。アニメの感じから、
漠然と4コママンガ的なのを想像していたのですが、ガッツリと普通の
マンガでした。アニメの方は原作の話の並びを少し入れ替えてアレンジが
加わっているという感じみたい。とてつもなくどうでも良い感じの話と、
ちょっとイイ感じの話とが混ざっていて、ギャップが面白いなぁと思ったりも。
飲み会帰りで早くも無く遅くも無く。
先日のビルドは最終的に失敗。やっぱりlibphobosのコンパイル時にICEで
落ちました。直し方を変えればよいのかどうしたものか。
急速に眠くなって死亡。
早くも無く遅くも無く。
先日のビルドは cc1d のリンクでエラー。足りないシンボルを含むソースは
コンパイルされていて.oファイルも存在するのですが、それを手で足すと今度は
足した.oファイル内に含まれるシンボルが大量に見つからない状態に。
仕方無いので足りないシンボルに見えているグローバル変数を追加したソースに
してmakeしたところ、とりあえずcc1dのリンクには成功したり。なんとなくgcc-4.4.5で
ビルドをしてたのですが、それが失敗だったかなぁ？
早めに帰着。
野良ビルドしたgcc-4.5.1で gdcの新しいのをビルドしてみたり。
先日2.014のphobosを修正して使用するビルドってのを
試した時、ICE(Internal Compiler Error)となってました。それがなんとなく
解決できたりしないかな？と思ったり。結果から言うとやっぱりICE。コンパイラ
が悪い訳では無さげ。でも、Cygwinパッケージのgcc-4で仕込みツールの
コンパイルに失敗する問題は発生しないので、ほっぽらかしにするには
野良ビルドしたgcc-4.5.1を使うのが良さげ。
という訳で、gdcの2.049マージ＋いくつか修正版 のビルドを試してみる
事にしたり。phobosは2.014のを修正して使用するって事で。さてどうなりますか....
ところで、gdcの方は2.049でバグを色々直している模様。2.050に並んでしまうと
DMDのバグなのかGDCのバグなのか判りにくくなると想像できる点を考えると、
もしかすると、本家DMDの1版前までで追従を止めて様子を見る事にしているのかも。
Emacsから直接翻訳Webサイトにアクセスできないかと検索してみたところ、
text-translator
なるステキモードが存在してるのを知ったり。ちょっと使ってみたところ
便利すぎです。
早くも無く遅くも無く。
Cygwinパッケージのgcc-4では-mno-cygwinオプションが使えなくなってますが、
クロスコンパイラをビルドするのでもダメなのか？と思い、gcc-4.5.1を
mingw32をターゲットにビルドしてみたり。因みにCygwin用ビルドは
以前なんとなくビルドして使えるなぁ
と思ってそのままほっぽらかし(めっきりC言語で物を作らなくなったので(^^;)にして
ました。
で、少し謎な所はありますが、なんとなくビルドできてみたり。
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc45x_test/libexec/gcc/i686-pc-cygwin/4.5.1/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ../configure --prefix=/usr/local/gcc45x_test --with-gnu-ld --with-gnu-as --enable-threads --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-languages=c,c++
Thread model: posix
gcc version 4.5.1 (GCC)
$ gcc -v -mno-cygwin
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc45x_test/libexec/gcc/i686-pc-mingw32/4.5.1/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../configure --prefix=/usr/local/gcc45x_test --with-gnu-ld --with-gnu-as --enable-threads --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-languages=c,c++
Thread model: posix
gcc version 4.5.1 (GCC)
$ cat hello.c
#include <stdlib.h>
#include <stdio.h>
int main()
{
printf("Hello gcc-4.5.1 -mno-cygwin") ;
}
$ gcc -mno-cygwin -O2 hello.c
$ ./a.exe
Hello gcc-4.5.1 -mno-cygwin
$ ldd ./a.exe
ntdll.dll => /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c940000)
kernel32.dll => /cygdrive/c/WINDOWS/system32/kernel32.dll (0x7c800000)
msvcrt.dll => /cygdrive/c/WINDOWS/system32/msvcrt.dll (0x77bc0000)
早くも無く遅くも無く。
先日の続きで、mingwビルドできないか試してみたり。結果は失敗。でも、
cc1が見つからないとか何やら妙なエラーのような。手動で少し粘ってみたものの
つっかかり所満載で挫けました。
もしかして、phobosはビルドせずに2.014のをそのまま使用して、
コンパイラだけ入れ替えれば使えるか？などと思ってみたり。でも、
importするにしても文法的にエラーするようになっていたりするので
(例えばinoutは使用できなくなってるもよう)、やっぱり新しいgdcで
コンパイルが通らなければダメかも。
そういや、gcc-4.3あたりからビルドの為にGMPやMPFRといった外付けの
ライブラリが必要になってます。でも、これらのライブラリって
何の為に使っているんだ？と思ったり。というのも、例えば cygwin
パッケージのgcc-4を使ってみても、外付けのライブラリに依存したコードを
吐く訳でも無く、ましてやコード生成のアルゴリズムに必要とも思えない
からです。Webで検索しても、無くてはビルドできないことはどのページにも
書かれてますが、何故必要なのか理由を書いたページは見当たらず。
AM中に起床。
先日のインクルードパスが変わる件については、gccのcppのマニュアル(英語)
を勘で読んでみたりしたのですが、オプション無しでパスが変わったりするような
事は無さそうな予感。
gdc本体は2.047のまま phobos2だけをdmd2.014ベースのgdcのに差し替えてビルドできるか
試してみたり(以前試した方法)。
コンパイラ本体の方はエラー無くビルドできるようですが、
phobosの方は色々つっかかり所がある模様。しかし、コンパイルエラーに
なった場合に、もう一度makeを実行すると何故か unix.x3 という下ごしらえ
コマンド(先日gcc-4だとコンパイルできないと書いたのがこれ)を毎回実行するようで、
これが異常に時間がかかる為に修正しようにもちっともはかどりません。
もそもそとphobosのエラーする部分を直していたのですが、internal/object.dを
こうだろうと直したところで 「cc1d: internal compiler error: Segmentation fault」
となり手詰まり。しょぼん。
とかやってるうちに、とうとう2.049までマージされたもよう！ 2.050に到達するのは
もう時間の問題かも。
AM中に起床。
gdcの掲示板(英語)を勘で読んでいると、gcc-3.4と4.0のサポートを
削除するような話が挙がっていたり。確かに、4.0以前と4.1以降だと
GMP/MPFRという外付けライブラリを使用するか否かで大分違うのと、
先日の怪しい修正もgcc-4.0.3をベースにしていたのに起因する点を鑑みても、
サポートを継続するのはそれなりの負荷になるかもなぁと思ったりも。
因みにTANEが4.0.3をベースにし続けているのは、cygwinのgccが4になった
直後、gdcをビルドできなかったなど、色々つっかかり所があった為です。
でも、そろそろgcc-4.3.xをベースにphobos以外のビルドはできる点を
確認しといた方が良さそうかもなぁと思ったりも。以前試したphobosだけ
2.014ベースの古いバージョンにしてビルドできるかな？
Fedoraでgcc-4.3.4をベースにgdcをビルドしてみたところ、全くエラー無く
ビルドできたり。続いてCygwinのを確認。以前
4.3.4をベースに一度試してみたことがあるのですが、結果的にはlibphobosの
ビルドが出来ないという事になってました。ただ、libphobos本体の他に
その前段階のツールのコンパイルに失敗していたのも気になっていたので
その原因を調べたり。
何故かstdlib.hでstddef.hが見つからないとか、そういうエラーになります。
そのソースを適当なディレクトリにコピーしてコンパイルするとstdlib.hでの
エラーは出なくなります。
違いを見る為に-vオプションを付けてみてみると、何故かインクルードパスが違っているようです。
エラーするとき ------- $ gcc -v -g -O2 -g -Wall -c -o config/x3main.o ../../../libphobos/config/x3main.c : #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/include /usr/lib/../include/w32api End of search list. : In file included from ../../../libphobos/config/x3main.c:1: /usr/include/stdlib.h:15:20: error: stddef.h: No such file or directory : ------- エラーしないとき ------- $ gcc -v x3main.c : #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/lib/gcc/i686-pc-cygwin/4.3.4/include /usr/lib/gcc/i686-pc-cygwin/4.3.4/include-fixed /usr/include /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../include/w32api End of search list. : -------
早めに帰着。
Fedora14を入れてみたり。
gdcが2.047までマージされたようなので、VMware上のFedora14のコンパイル環境を
揃えるテストも兼ねてビルドしてみたり。一箇所だけ少々怪しい修正を加えて
コンパイルを通しましたが、それ以外はこれまで通り。インストールして、
簡単なソースをコンパイルしてみましたがひとまずOKそう。
そういや、MeadowからTramp+plink経由でVMware上のFedoraのソースファイルを
リモート編集したのですが、相変わらずサイズの大きなファイルだと
書き込みに失敗する罠。Webを検索しても、未だ同じような問題に当たっている人は
居ないようで(こんな使い方をする奴ぁ居ないって事か？)、なんだか不便な思いを
しています。
home 1.40。今まで見慣れた感じの画面から思いっきり模様替えされてたり(^^;
こころなしかラウンジ間の移動がシャキシャキ行われるようになった気がします。
今回の目玉機能として アイテムを倉庫と呼ばれる場所に移すことができるようになりました。
倉庫に移したアイテムはロード時の情報取得を行わないようです。これのおかげで
全体的にシャキシャキ動くように感じるかは定かではありませんが。
でも、一部アイテムが表示されないなどの不具合があるようです。大型アップデートを
バグ無しで提供ってのはなかなか難しいのかなぁ？すぐに直るなら別に良いですけどね。
Fedoraでパッケージの一覧を眺めていたら、OpenJPEG
なるものの存在を知ったり。JPEG2000のencode/decodeの実装みたいです。
JPEG2000と言えばJasPerなんか
がありますが、OpenJPEGがそれらに対してどうなのかまでは良くわからず。
他にも、libjpeg-turboなる
IJGのjpegライブラリをSIMD対応したものに、Fedoraのパッケージは置き換わっている模様。
そういや前に、日本人でSIMD対応してる人の
ページを
知ったなぁ？と思ったところ、どうやらlibjpeg-turboはそれをベースに拡張した
みたいです。
libjpeg-turboをcygwinでビルドしてみたり。configure ＆ makeで特にエラー無くビルド
できました。なにやら殆どのコードをアセンブラで置き換えているようです(^^;
そんな訳でjpeg-8bもビルドしてみて、実行速度を比べてみたり。手元にあった
80個のjpgファイルを次のようなtcshスクリプトでdjpeg実行してみたり。
#!/bin/tcsh -f set JPGFILES=`ls -1 *.jpg` set djorg="../jpeg-8b/djpeg.exe" set djtrb="../libjpeg-turbo-1.0.1/.libs/djpeg.exe" echo "ORG djpeg test start `date`" foreach fname ( $JPGFILES ) $djorg -pnm -outfile xxx.ppm $fname end echo "ORG djpeg test end `date`" echo "TURBO djpeg test start `date`" foreach fname ( $JPGFILES ) $djtrb -pnm -outfile xxx.ppm $fname end echo "TURBO djpeg test end `date`"
$ ./test.sh ORG djpeg test start Sat Nov 13 00:58:29 2010 ORG djpeg test end Sat Nov 13 00:58:49 2010 TURBO djpeg test start Sat Nov 13 00:58:49 2010 TURBO djpeg test end Sat Nov 13 00:58:58 2010
早くも無く遅くも無く。
PShomeの1.40というのが来ているようなのですが、サーバーのメンテナンスの方が
終わってない模様。毎度メンテナンスにはかなりの時間を要するようなのですが、
これって何に時間がかかっているものなのか気になる。
早めに帰着。
眠くて死亡。
早くも無く遅くも無く。
新しいgdcだとgdbの対応に何かしら反応があるかな？と思い、少し新しいgdcをVMware上の
Fedoraで試してみたり。でも、特に違いは無い模様。色々試してて判った事もいくつか
あったり。
先日、クラスのフィールドに置かれた変数を表示できないと書きましたが
指定の仕方がまずかった模様。例えば、
class Foo{
int x,y ;
this(){
x=10 ;
y=20 ;
}
void print(){
writef("x=%d y=%d\n",x,y) ;
}
}
早くも無く遅くも無く。
gdbの7.2でD言語がサポートされているというのを知ったり。
Cygwinパッケージのgdbは6.8で、それとなくD言語でも使えます。しかし、
例えば変数表示を行う場合、メソッド内で宣言された変数は
printコマンドで表示できるのですが、クラスのフィールドに置かれた
変数はブロックの中に無いみたいな感じのエラーで見る事ができません。
ここんところがイイ感じになってないかなぁ？と思ったり。
そんな訳で、ビルドしてみたり。最初、gdcを含んだ野良ビルドgcc-4.0.3を
使用していたのですが、gdb下のソースのコンパイルでコンパイラがInternal
エラーでずっこけたり。仕方なく、パッケージインストールされている
gcc-4(4.3.4)を使ってビルドしてみたり.......終わらず。
ひとまずエラー無くビルドできたり。「show language」で表示してみると
「The current source language is "auto; currently d".」と
出るので、Dソースという事は認識している予感。でも、あんまり
使い勝手は変わらない気が。クラスのフィールド変数はやっぱり表示
する事ができなかったり。うーむ。
昼過ぎ起床。
もそもそとコーディング。
フジテレビでやってた「流浪の冒険野郎 犬侍がゆく！」。
犬侍と書いて「ドッグざむらい」と読むらしい。
全くかわいげの無い犬の着ぐるみを着て、ガチャピン並みにフィギュアスケートを
したりBMXを乗り回したり海に潜ったり。着ぐるみを着て
あれだけ動けるのがスゲーです(^^; 因みに、犬侍と書いて「いぬざむらい」と読む
単語があるというのも同時に知ったのですが、これは
「武士の道をわきまえない侍をののしっていう語」だそうです。
gdc。つい先日dmdの2.037に追従したと思っていたのですが、いきなり2.046まで
マージされてて驚きました(^^; 2.04x台はphobosの大きな変更が無かったから
かなぁ？と思ったりも。
「ONEPIECE(60)」。号泣、そしてネタ振りの行方が物凄く気になる。
昼過ぎ起床。
週トロ。Blu-ray化投票の結果発表。週トロの他にアニメージュなどでも
リストの中からBlu-ray化して欲しいものを投票してもらった結果、
総合1位になったものをBlu-ray化してもらえるようにお願いする(この時点
ではBlu-ray化されると決定されてる訳ではない)というもの。
過去2回の投票では、クロが推していた「とらドラ」のアニメは1位になれず、
しまいにはキングレコードに直談判する
という暴挙に出たりしてました(^^; で、今回の投票では見事「とらドラ」が
1位になりました。キングレコードに直談判した経緯もある事から、
製品化されるまでの間にもう一話題あるかも？
「バブルへGO!! タイムマシンはドラム式」。今までも何度か放送されていたようなの
ですが観る事ができず今回初めて観ました。面白かったです。
当時のファッションとか、あの時は普通に思えてたのも、今見ると「古っ」て感じる
不思議。今のファッションも15年後に見ると、やっぱり古って感じるんだろうか？
エンディングロールを見ていて、原作がホイチョイだというのを知って、
なるほどと思う所があったかも。
早くも無く遅くも無く。
ちょろりコーディング。結局、先日の件は有効桁数を適当に決めて切り捨てる事に
しました。
早くも無く遅くも無く。
なんか動きが変なので調べていたら少々困った事に。困った部分をクローズアップしたコードが
以下です。
import std.stdio ;
import std.math ;
struct vec3d{
double x,y,z ;
double dot(vec3d v){
return (x*v.x + y*v.y + z*v.z) ;
}
double normalize(){
double d=sqrt( x*x + y*y + z*z ) ;
if( d==0.0 ){
x=0.0 ; y=0.0 ; z=0.0 ;
}else{
x=x/d ; y=y/d ; z=z/d ;
}
return( d ) ;
}
} ;
void main(string[] args)
{
double res ;
vec3d v1 ; v1.x=0.7071068 ; v1.y=0.0 ; v1.z=0.7071068 ; v1.normalize() ;
vec3d v2 ; v2.x=0.7071068 ; v2.y=0.0 ; v2.z=0.7071068 ; v2.normalize() ;
res=v1.dot(v2) ;
writef("res=%e\n",res) ;
res=acos(res) ;
writef("res=%e\n",res) ;
}
$ ./a.exe res=1.000000e+00 res=nan
_Dmain (args={length = 1, ptr = 0x5349f0}) at mathtest.d:29
(gdb) print res
$3 = 1.0000000000000002
昼過ぎ起床。寝すぎ。
Webを眺めていたら、emacsの起動時に生成されるスクラッチバッファで、C-jを押すと
カーソル位置より手前のLisp式を実行できるというのを知ったり。知りませんでした(^^;
電卓として使うのはポーランド記法慣れしてないと厳しいのですが、
.emacsなどでちょっとした条件分岐などを入れる場合の事前確認とかには使えるかなと
思いました。
gdc。スゴイ勢いでアップデートされています。つい先日2.037のアップデートが行われました。
2〜3日毎に0.001ずつ上がっているので、この調子で上がってけば12月上旬には追いつく
感じかも。追いついた後はcygwin/mingw対応してくれないかなぁ？と思ったりも。
ちょっと寄り道気味でしたが、もそもそとコーディング。
早くも無く遅くも無く。
先日の怪しいところを追いかけてみるも、追いかけきれずに良くわからず。
LexerやParserでマッチしない文字列やtokenを検出するのに、例外を使ったアカデミックな方法を
用いている為か、あっちこっち飛びまくりで流れがイマイチ掴めません。
早くも無く遅くも無く。
ANTLRDのずっこけをデバッガで追いかけてみたり。最初、gdbをコマンドラインで
使用していたのですが、あっちこっちメソッドを渡り歩くような動きになってて、
ソースの1行分と行番号だけではどう動いているかさっぱり判らなかったり。
で、Cygwinのemacsのgdbモードを何気に起動してみたら、Dのソースなのですが
ちゃんとソースファイルを開いてポインタ表示できるいわゆる普通のemacsの
gdbモードが使えたり。でも、emacs -nwで使うのはイマイチだったので、
どうにかMeadowで使えないものかと、emacsと同じくgdbのオプションを
「gdb --annotate=3 a.exe」の様に指定してみたところ、ちゃんと使えてみたり。
長いこと使えないものだと思い込んでいたので、これはラッキーと思ったり。
ついでに、-mno-cygwinコンパイルしたものでもいけるか？と試してみたところ、
これもOKな模様。でも、printコマンドで変数の値を表示するのに、構造体は
表示できなかったり。普通の整数や文字列はなんとなく大丈夫そう。んー、残念。
でも、Segfaultずっこけなどは追いかけやすくなるかも。
さておき、追いかけてみたところ、tokenを得るLexerのメソッドがあるのですが、
それがnullになってる模様。途中のtoken解読は行っているようなのですが、
何故か最後の最後でその結果がどっか行ってしまっているという予感。