昔の最近の出来事(2012.01)

2012/01/31

少し早めに帰着。

もそもそと調べごと。

早くも無く遅くも無く。

gdcの新しいのが来ていたので、MinGWビルドを試してみたのですが、 状況変わらず。

AM中に起床。

Fedoraの方でgcc-4.7対応のgdcのビルドを試してみたり。 リンカが-lgcc_ehを見つけられないのはMinGWの時と同じなのですが、 手動で対処したところHelloWorldレベルのコードは問題無くコンパイル＆実行できました。 うーむ。MinGWってそんなに違うもんなのだろうか？

そういや、libphobosをコンパイルする際に自動生成されるソースがいくつかあるのですが、 MinGWのビルドではその生成がうまく出来ていなかったので、 gcc-4.6.2で生成したものをそのままコピーして使ってみたり。 でもやっぱり状況変わらず。

起きたら昼過ぎ。寝すぎ。

ひかりTVのビデオに「あさりちゃん」が来てたり。なつかしー。 そういや過去の日記であさりちゃんについて一度も触れた事が無かったらしい (それらしき単語をgrepしても引っかからなかった)というのを今知りました。 大分前に本屋であさりちゃんの新刊が出てたのを見たとき、連載続いていたんだ というのを知りました。と言うのも、読んでいたのは20年以上も前の事で、 このページの 全巻表紙画像でも記憶にあるのは35巻くらいまで。就職したのを境に 新刊を買うことが無くなり読まなくなりました。 Wikipedia によると、てんとう虫コミックスの最長巻数と掲載期間の作品になっているそうな。
現在でも小学[ニ三四]年生で連載されているようなのですが、 小学[三四]年生の休刊に伴い 100巻で連載終了が決定しているそうです。

連載が続いていた事に全く気づくことが無かったのですが、実際に休載期間が あったのだろうか？と思いWebで調べてみたところ、2〜4巻/年 というペース で単行本が出続けており、何気に週間マンガと変わらないくらいの速度で出て いる事が判ったり。ほぼ二人で描いている事を考えると何気にスゴイ事かも。

早めに帰着。

gcc-4.7対応のgdcをMinGWでビルドしてみたり。 以前、gcc-4.7対応されたものを 試した時は、phobosのビルド中にコンパイラがICEズッコケとなって ビルドできませんでした。
ベースとなるgccはgcc-4.7-20120121.tar.bz2というスナップショットを 使用しました。configure、make 実行で順調に進んでいたのですが、 libphobosのビルド途中でエラーが発生。でも、 makeを再実行するとなんとなく進んでビルド完了しました。 make installして手持ちコードをコンパイルしてみたり。 コンパイル自体はエラー無く通ったのですがリンクでエラー。 リンカが-lgcc_ehを見つけられないというものでした。 以前ppcクロスコンパイラを 使ってglibcをビルドしたときに同様のリンクエラーが出ましたが、 libgcc.aをシンボリックリンク(MinGWの場合はコピー)して良いと いうのをそのまま適用してみたり。で、リンクにも成功。
実行してみる訳ですが、Segfaultでずっこけて起動できず。 HelloWorldレベルのコードもダメで、gdbでスタックをトレース してみた所、core/runtime.dでずっこけている事が判ったり。

$ gdb -q ./a.exe
Reading symbols from C:\cygwin\home\tane\develop\dlang\test/./a.exe...done.
(gdb) run
Starting program: C:\cygwin\home\tane\develop\dlang\test/./a.exe
[New Thread 3456.0xcd0]

Program received signal SIGSEGV, Segmentation fault.
unitTest (this=) at ../../../libphobos/object_.d:1664
1664            if (isNew)
(gdb) Cannot access memory at address 0x23

(gdb) where
#0  unitTest (this=) at ../../../libphobos/object_.d:1664
#1  0x00419335 in core.runtime.runModuleUnitTests.__foreachbody6 (this=0x7c95741c, __applyArg0=0x23) at ../../../libphobos/core/runtime.d:360
#2  0x004052ac in object.ModuleInfo.opApply (dg=...) at ../../../libphobos/object_.d:1799
#3  0x00419410 in core.runtime.runModuleUnitTests () at ../../../libphobos/core/runtime.d:358
#4  0x00402250 in rt.dmain2.main.runAll (this=0x51d) at ../../../libphobos/rt/dmain2.d:583
#5  0x004021ac in rt.dmain2.main.tryExec (this=0x22ff2c, dg=...) at ../../../libphobos/rt/dmain2.d:543
#6  0x0040292d in rt.dmain2.main (argc=1, argv=0x3e2dc0) at ../../../libphobos/rt/dmain2.d:594
(gdb) Cannot access memory at address 0x23

気持ち遅めに帰着。

gdcでのstd/socketsteram.dのコンパイル後のアセンブラソースが変な件。 大分新しい11ae589b9a71はNGなのですが、大丈夫な 00b19ad7e81f を元に手でパッチを戻す事を試みてみたり。 全部戻すと00b19ad7e81fより後に入った修正まで戻ってしまうので、 必要と思われる部分だけを戻す必要があります。
な訳ですが、かなり雑な戻し方をしてどうにか大丈夫な感じに。 戻したのは、d-decls.ccのFuncDeclaration::toThunkSymbol() 内のコードと、d-objfile.ccのmake_alias_for_thunk ()と、 ObjectFile::outputThunk()内のコードです。戻しすぎている 気がしなくもありませんが、ひとまず結果オーライという事で。

あ、でも、-O1または-O2にバグがありそうな件(-O0だと大丈夫) は直ってないのが微妙。

早くも無く遅くも無く。

gdcのロードマップなる ものが示されているようです。これによると、今年の3月上旬には gcc-4.6.xのサポートを停止してgccの開発バージョンへの同期を始めるようです。 gcc-4.7.0のリリースは3月くらいかな？と予想しているのですが、 それに入れるには同期を始めるのが遅すぎる気も。4月だとすれば少し時間は ありそうですが、それでもリグレッションテストなどを考慮に入れると やっぱり4.7.0には入れられないような。

遅めに帰着。

std/socketstream.dが変なシンボルを要求してリンクに失敗する件を調査。 またコミットを遡ってみました。その結果、e060d079e138で壊れているという 事が判明。

e060d079e138以降の版とそれより前の版とで、それぞれ libphobos/std/socketstream.d を gdc -O2 -S socketstream.d てな感じでコンパイルしてアセンブラソースを 生成すると、全く異なるコードが生成されている事が判ります。 壊れている方は本来生成されるべきコードが存在していない感じになっている為、 その部分に対して リンク時に外部シンボルとして存在する事が期待される訳ですが、 そんなものはそもそも存在しない為、undefined symbols になってしまうという流れです。

e060d079e138での変更を外せばいけるんだろうと思うのですが、変更点が多すぎて 手で戻す事が困難な気が。

早くも無く遅くも無く。

std/socketstream.dが変なシンボルを要求してリンクに失敗する件を調べたり。 ver030とver031のそれぞれのgdcを使って、std/socketstream.dのアセンブラソース を出して比べてみたり。すると、ver030のアセンブラソースはシンボルの先が ジャンプテーブルになっていて参照先が存在するのですが、 件のver031のアセンブラソースでは参照先が存在しないという感じになっていました。 Linuxの方ではどうなんだろ？と思い、少し前のver031のgdcで同じく std/socketstream.dのアセンブラソースを見てみたところ、やはりジャンプテーブル になっていて参照先が存在している模様。MinGWの方で変なコードを出す gdcと同じ版のをビルドして確認してみる事に。

ビルドはエラー無く終了。で、アセンブラソースを出してみたのですが、 MinGWのそれと同じ感じになったり。
3dc024965ff2ではジャンプテーブルのコードが生成されているのですが、 11ae589b9a71だと壊れている感じ。うーむ、間に色々ありすぎて、どこで 壊れているのか判らない......(^^;

そういや、gcc-4.7.xに向けたgdcのコミットが行われています。 RC(Release Candidate)と付いているのですが、まだgccに取り込まれる感じでは なく、gcc-4.[56].xと同じ感じみたい。でも、gcc-4.7.0がリリースされる (多分今年の3月くらいになると思われる)と同時に使える感じではあるのかも。

AM中に起床。

そういや、少し前は DMD2.057対応がされていなかった Bindings for the Windows API ですが、今日見たら対応済みになってました。D1にも対応が必要なので、 TANEが行ったような単純にtypedef をaliasに文字列置き換えするような 対応方法ではないようです。で、新しいので手持ちコードをいくつか ビルドしてみたのですが特に問題無さげ。

gdcの6f10e575ee76で、手持ちコードを全てビルドテストしたところ、 いくつか不具合があったり。一つは -O1または-O2でとあるソースをコンパイル してそれを含んだバイナリを実行するとSegfaultする。-O0だと大丈夫な事から、 オプティマイズにバグがありそうな予感。 もう一つはリンク時に socketstream.dが「___t.0」とか変なシンボルを要求していて リンクに失敗する。これは何が関係しているのか見当が付かず。

Webを眺めていると、Gdc Hacking なる文章が置かれていたり。

DMDの本家ページの Changelogページ を見てみると、DMD2.058の変更点が書かれていたり。upcoming Feb 13, 2012 と なっているので、2/13に2.058がリリースされる予定という事なのかしら？

AM中に起床。

DMD2.057ベースのgdcで、std.regexを使用するとずっこける手持ちコード があるのですが、それを少し調べてみたり。ずっこけっぷりは以前 調べたのと同じ感じ。
std/regex.dが大幅に変更されていて、それがトリガとなっているのは 事実なのですが、実際にずっこけるのはrt/aaA.d内のコードなので、 rt/aaA.dのバグの線も無くはないという気が。で、デバッガで追いかけて みるのですが原因究明に至らず。

    obj_reg_tbl["mtllib"] = regex( "^mtllib\\s+(\\S+)","") ;

早めに帰着。

あまりの眠さに急速停止。

飲み会。早くも無く遅くも無く。

ちょろっと調べごとをして終了。

早めに帰着。

ここ数日、gdcが頻繁にアップデートされているのは何故だろう？

いつの間にか寝てたり。

早めに帰着。

gdcの新しいのをビルドする件。昨日ダメだったのは以前 遭遇したstd/regex.dのバグっていた件でした。

そんな訳で手持ちコードをビルドして確認。なんとなくOKそう。

で、gdcのCommitsを 見てみると、24時間以内に何やら大量に変更が加えられていたり。 その中の 2120e0cbde30 で件のmultiple definition の修正が加えられてました(^^;; なんてタイムリー。 そんな感じなので結局必要になりそうなのは、「マルチスレッド関連の不具合を改善する自前パッチ」と、 「std.regex を古いのに戻す」の2点だけかも(^^;

今日時点の gdc最新版である 6f10e575ee76 のビルドを試してみました。 まずは自前パッチ無しで試してみたところ、ビルドは一発OK。makeの二度打ちも 不要になってました。make installして使ってみたところ、 gcc/atomics.d内コードで_sync_bool_compare_and_swap_4が見つからなくてリンクでエラー。 libphobosのビルドに -march=i686を足す必要があるみたい。 x86_64対応に関連するのだろうとは思うのですが、毎度何かしら同種(要 -march=i686)の レベルダウンをしている気も。

ひとまずphobosの自前パッチを当てて、std/regex.dを古いのに戻して phobosを再ビルド して、手持ちコードをコンパイルしてみた所、ひとまず問題無さそうな感じに。 これでしばらく使ってみます。

早めに帰着。

新しいgdcでマルチスレッドな手持ちコードをコンパイル＆実行したら 起動でずっこける件を調べたり。 デバッガで少し追いかけたところ、lifetime.d:rt_processGCMarks()内で ずっこけている事が判り、例の奴だという感じだったり。

rt_processGCMarks()内で使用するBlkInfoという構造体型の cacheが不当という感じなのですが、直接の原因はcacheのメンバー変数 であるポインタbaseが、アクセスできない領域を指しているというもの。 以前調べたのと違って、明らかにアクセス不能と思われるアドレスでは なく、それっぽい感じの場所を指しているようにも思えるのですが、 デバッガでその領域をダンプしようとするとアクセスできない領域に なっているようです。結局前も判らなかったのですが、この領域を 最初にどこで割り当てているのかが不明。また、中身をどこで入れている のかも不明。この辺を突き止める必要がありそう。

ちょっと直し方を変えてみたところ、なんとなく大丈夫そうになったり。 でもまだダメな感じの奴がいてまだ調べる必要がありそう。

AM中に起床。

gdcのバージョン遡り中。少し模様が見えてきたり。ざっくり言うと phobos2のconfigureが再構築されたのを機に変になっている模様。

  :
goshawk-gdc-4dfa4c11ccd7 → OK
goshawk-gdc-b3200b086277 → NG  phobosのconfigure実行に失敗
goshawk-gdc-63647d6f2b87 → NG  phobosのconfigure実行に失敗
  :
goshawk-gdc-d71656e55ad8 → --  ビルドは試して無いが phobos2/configureが再生成されている
  :
goshawk-gdc-e8ae51578e54 → NG  multiple definition
  :

  :
goshawk-gdc-4dfa4c11ccd7 → OK
goshawk-gdc-b3200b086277 → NG  phobosのconfigure実行に失敗  #configureとMakefile.inが変更されただけ
goshawk-gdc-63647d6f2b87 → △  phobosのconfigure実行に失敗→configureを直せばOK
goshawk-gdc-bd1f89846e93 → NG  ★configureを直したが multiple definition
            7470a20b2900
            bedf43669633        # D1のphobosのconfigreが変更されただけ
goshawk-gdc-d71656e55ad8 → NG  multiple definition   #ここでconfigureが 4dfa4c11ccd7と同じに戻った
  :
goshawk-gdc-e8ae51578e54 → NG  multiple definition
  :

朝から休出。気持ち早めに帰着。

gdcのバージョン遡り中。

いつの間にか寝ていたり。

早くも無く遅くも無く。

gdcのバージョン遡り中。

あまりの眠さに急速停止。

遅めに帰着。

gdcの新しいのがリンク時にmultiple definitionでエラーして使えない件。 結局何が悪いのか見当が付かないので、ビルドできたバージョンに向かって 順に遡ってみる事にしたり。

早くも無く遅くも無く。

昨日のconfigureオプションを変えてのgdc再ビルドはひとまず完了。 make installして使ってみるも、やっぱりリンクで大量の multiple definition でエラー。 んー、うちの環境の問題なのか？？

Wings3Dのスナップショット版の更新ノートを見ていると、日本語対応という のが取り込まれているというのを知ったり。で、インストールしてみたり。 MSVCR100.dllが見つからないというエラーが出たのですが、 Microsoftのダウンロードサイトで拾ってインストールすることで、 無事起動できたり。Edit→PreferencesのUserInterface内のLanguageを Japaneseにして再起動するとメニューなどが日本語で表示されるように なりました。でも、下手に日本語になっている方が何の事だかよく判らなかったりも(^^; そんな訳で英語表示に戻しました(^^;; 英語が得意な訳では全然無い(むしろダメな方) のですが、Wings3Dは海外の方が参考になるサイトが多いので、メニュー表示は 英語のままの方が都合が良いです。
そういや、Inkscapeもメニューなどが日本語になっているのですが、このせいで本家の 参考操作の手順がメニューのどこにあるのかさっぱり探せなかった事があります(^^;

気持ち遅めに帰着。

gdcのMinGWのバイナリが有志によって 置かれている のですが、割と最近のバージョンのバイナリが置かれていたり。 手持ちソースのリンクができない問題が解決されているのだろうか？と思い ビルドしてみるのですがやっぱりダメ。そんな訳で、configureオプションに 違いが無いか確認してみたり。ほぼ同じなのですが、--disable-sharedオプションを 付けてないという差があったり。以前は --disable-shared が必須 だったと思うのですが、最近は外しても良くなったのか？そんな訳で もう一度ビルドし直してみたり。

終わらないのでほっぽらかし。

朝から休出。そして気持ち早めに帰着。

あまりの眠さに急速停止。

朝から休出。そして早くも無く遅くも無く。

ちょろっと調べ事をして終了。

起きたら午後もいい時間。寝すぎ。

最近はコンスタントにgdcの変更が加えられています。先日ver0.31に なったのですが、その後、サポートgccを gcc-4.5.x 以降に絞る変更が加えられた ようです。確かに、ビルドのエラー報告なんかを傍から見ていて、 新たにビルドしてるのに何故gcc-4.4.xを使うの？と思う事がありました。 これで本家のDMDとのマージも早くなったりするかな？

そういえば、GMPを使うのにクラスで実装していたのを構造体にすると うまく動かなかった話がありましたが、それの再現を試みたり。 以下のコードでそれと同じ話が再現できていると思います。

     1  import std.stdio ;
     2  import std.string ;
     3  
     4  struct Buffer
     5  {
     6    int  *p ;
     7    
     8    void alloc(int n){
     9      p=cast(int*)(core.memory.GC.malloc(int.sizeof*n)) ;
    10    }
    11    
    12    ~this(){
    13      writef("destruct\n") ;
    14      core.memory.GC.free(p) ;
    15      print() ;
    16    }
    17    
    18    void print(){
    19      writef("p=%08x\n",p) ;
    20    }
    21  }
    22  
    23  void foo(Buffer buf)
    24  {
    25    buf.print() ;
    26    return ;
    27  }
    28  
    29  void main()
    30  {
    31    Buffer buf ;
    32    buf.alloc(10) ;
    33    foo(buf) ;
    34    buf.print() ;
    35  }

1. 32行目のbuf.alloc()でbuf.pにmalloc()で割り当てたメモリ領域のポインタが格納されます。
2. 33行目のfoo(buf)により、構造体渡しでbufが渡されます。参照渡しではありませんので、 foo()内のbufは31-34行目で使用しているbufのコピーになります。
3. foo()関数を抜ける時にfoo()内bufのデストラクタが実行されます。ここで順番1のmalloc()で 割り当てた領域が開放されます。これは意図しない開放だと言えます。
4. 34行目を実行した後、main()関数を抜ける所でbufのデストラクタが実行されます。ここで もう一度free()が実行されます。

早くも無く遅くも無く。

あまりの眠さに急速停止。

日付け越え前に帰着。

先日のビルドはun.dのコンパイルでエラーするのでmake二度打ちで エラー無くビルドできたり。で、make installして手持ちコードのコンパイル を行ってみたのですが、やっぱりmultiple definition が大量に出て リンクできず。

Fedoraの方でビルドを試してみたり。こちらはエラー無くmakeできました。 で、make installして使ってみるのですが、リンクも特に問題無いようです。 そんな訳でMinGW向けにだけ壊れているという謎な状況の様です。

気持ち遅めに帰着。

gdcがver0.31になった模様。先日、ビルドはできたものの手持ちコードを コンパイルすると大量に multiple definition でリンクがエラーしてましたが、 その後も少し手が入って0.31になっている模様。しかし、件のリンクエラーが 直っているのかは不明。

そんな訳でgdc 0.31のMinGWビルドを試してみたり。見ていられないので makeを仕掛けて寝たり。

AM中に目が覚め、もにゃもにゃしてたら昼前に。

随分前に録画したまま見る暇の無かった けいおんの映画特番を見たり。 監督の 山田尚子氏がVTRで出てて、なんか若っ！と思わず声に出てしまいました(^^;;

ぐうたら過ごして終了。明日から仕事始めですが復帰できて無いなぁ(^^;;;;;

何気にFirefoxのアップデートをしたら、いきなり9.0.1になって驚いた。 2ヶ月くらい前に8.0になったと思ったのですが、こんなに早くメジャーバージョンが 上がるもんでしたっけ？

AM中に起床。

昨日の1.0e+100倍くらいの拡大は仮数部のビット数を512bitにするくらいで 大丈夫そうでした。でも、640x480のサイズで3時間くらいかかりました(^^;

色付けの方法とかマルチスレッド化とか色々いじり所はありますが、 プロ遊の下に置いてみました。 御参考まで。

Webを散策していたら、3Dでフラクタルを描けるフリーソフトウェアを 見つけたり(Mandelbulber)。 サイトの動画を見たりちょろっと触ってみたり。これ、凄すぎる(^^;;

何気にgdcの新しいのをビルドしてみたり。un.dのコンパイルでエラーするので makeを二度実行するのは変わりませんが、それ以外はエラー無くビルド完了したり。 で、make installして、手持ちコードをコンパイルしてみたところ、 リンクで大量にエラー。何故か multiple definition が 大量に出たのですが原因が全く判らず。

来週始まるらしい「アクエリオンEVOL」の特番をやってたのをなんとなく 観たり。番組中に監督である河森正治氏が出演していました。 初めて御顔を拝見したのですが、思ったよりも若い感じだったので、 何歳なんだっけ？とWikipediaを漁ったところ51歳だと判りへー。 でも、マクロスの劇場版とかで監督やってた人だよなぁ？と思うと、 改めてスゴイ人なんだなぁと思ったりも。

明けましておめでとうございますm(_'_)m 今年もよろしくお願いします。

そういや、TVの番組表を見ていると、「日常(あらゐけいいち)」のアニメが Eテレで放送される事になっていて驚いたり。こんな事ってあるんだ。

PNGセーブを行うのに、Laymanのコードを引っ張ってきたのですが、 PNGの1.0.x時代のコードなもんだから、1.5.xだと全然様子が違ってて死亡。 で、色々説明書などを漁ったのですが、PNGファイルを示すシグネチャ (ファイルの先頭8byte)が書き込まれなくて、ローダでPNGファイル判定されなかったり。 適当なPNGファイルを参考にfputc()で書き込んでから png_write_info()、データ本体 の順で書き込んだらPNGファイル判定もされ、 画像展開も大丈夫だったり。つまり、シグネチャ以外はちゃんと書き込めている模様。 で、png.hを眺めていたらpng_write_sig()なる関数があり、これを使えば シグネチャを書けそうな感じなのですがやっぱりダメ。なんてこった。

寝て起きたら昼過ぎ。

もそもそとコーディング。マンデルブロ集合のビュア。一気に 1.0e+100倍 まで拡大を 試みたのですが、演算解像度が足りなくてモザイク模様になったり。仮数部のビット数 を256にしていたのですが768にしてみたり。このせいで仮数部の桁表示が230桁を越えて しまった為、ウインドを思いっきり広げないと値が全体表示できなくなったり(^^;;

仮数部の桁を増やしたのに何故か変化が無くてなんでだ？と思っていたら、もう一箇所 変えなくてはならないのが抜けていたり。凡ミス過ぎる(^^;