昔の最近の出来事(2014.05)

2014/05/31

AM中に起床。

MinGW gdc。パッチがgitのパッチ形式になっていて、あてるには gccのアーカイブを展開した後、gitに一時コミットしないとダメ そうな感じだったり。git init; git add; git commit; した後、 git patch でパッチを当てようとしたらどうにもうまく当たらず。

パッチがあたらない件はオペミスでした。でも、gitのパッチは gitを使わないと当てられないのは不便です。

gcc-4.8.3をベースにとりあえずビルドできたり。 手持ちのWindowsアプリをコンパイルした所、特に問題無く実行バイナリ は生成できたり。実行してみたところ、一応動作はするようですが 終了時にSegfaultでずっこけるもよう。
心当たりはあるので、libdruntime/gc/gc.d(4.6.xの時はgcx.dでした)を改造。 これで終了時のSegfaultは回避できたり。でも、いくつかある手持ちコードの 一つが実行途中でSegfaultしたり。連想配列アクセスが変な感じみたい。 詳しくは調べられてません。

PS4でtorne(厳密にはnasne)。PS3ではチューナーとソフトのセットが torneとなっていたと思いますが、PS4ではソフト部分だけを 移植した感じでしょうか。nasneは見かけ上、録画機能の付いた DLNAサーバという感じなので、PS4ではtorne(ソフト)を使って nasne(DLNAサーバ)を制御するという感じみたい。 「torne==PS3専用チューナー」と認識されていると、 少し説明がややこしくなる気がします。
そういや素のPS4はDLNA対応されていませんが、torne(ソフト)を 経由して一般的なDLNAクライアントとして動かす事になったりして? と少しだけ思ったり。

PS4の「TRIALS FUSION」を買ってみたり。TRIALS-HDは最初PS3でも 出る予定だったように思うのですが、なぜかXBOX360だけに出てました。 さておき、「リトライが止まらない」というコピー通り、うまくいかないと 思わず何度もリトライしてしまいます(^^; まだ序盤なので、 何度かやればゴールド(メダル)が取れますが、後半はどうなることやら。 スピードを出しすぎてもダメ、遅すぎてもダメで、丁度良いところで コースの角度にピタっと決まるととても気持ちが良いです。

2014/05/30

早めに帰着。

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

2014/05/29

気持ち早めに帰着。

MinGW gdc。buildスクリプトを実行するも、色々つっかかり所が あったり。一番のハマりは、なぜかgdc本体のビルドがコメントアウト されていたところ。えー。

2014/05/28

気持ち早めに帰着。

venix1氏のメンテしているMinGW対応gdcパッチがアップデートされていたり。 ベースgccバージョンは4.8.xですが、先日リリースされた4.8.3をベースに 動くようなら、gcc-4.9.0との違いを比べられるかしら?

2014/05/27

気持ち早めに帰着。

MinGWのgdcで生成した実行ファイルがずっこける件。 ちょっと調べてみてますが原因判らず。

2014/05/26

気持ち早めに帰着。

ちょろり調べ事。

2014/05/25

昼頃起床。

掃除したり洗濯したり。

銀ムツという魚。随分前にセブンイレブンの弁当に、銀ムツ弁当と いうのが一瞬だけあり、とても美味しかったのですが、その後二度 と見る事がありませんでした。その後、銀むつ==メロ(銀だらの代用魚) という事を知って、そうなんだと思ったり。 マジェランアイナメのWikipedia によると、銀ムツという名前での販売は禁止されているらしい。 だから「銀ムツ弁当」として売れなくなったという事なのかしら? メロという呼び方に魚感が無いのがダメなのだと思いますが、 「銀ムツ(メロ)弁当」でも良いので復活希望。

2014/05/24

昼頃起床。寝すぎ。

ドンスタ。順調に100日越えた所で、蜘蛛を相手にしていたら死亡。 それは良いのですが、復活ポイントに半魚人が居たせいで復活後に 直ぐに殺されてしまい、育て上げたセーブデータが上書きされて終了orz 心が折れた。

ちょろりお出かけ。風が微妙に強くて自転車の進む速度がなんだか少し 遅い感じだったり。

ドンスタ。今度は、犬無し、冬無しでスタート。ひとまず探索していると、 豚の王様とかが居て面白そうなフィールドになっていたのですが、 落ちていた収納箱を開けると、いきなり季節が冬になってしまったり。 何の準備もできていないものですから3日程度で凍死。なんてこった。
再度スタートするも、今度はあまり面白そうなフィールドで無さそう な予感。ひとまず続けてみることに。

そういやDCONF2014は 終わったようだ。ビデオが来るのはもう少し先かな?

ドンスタ。一通り世界を回ったつもりで拠点を配置したのですが、そういや 復活装置(死んだときの復活ポイント)を見つけてない事に気づいたり。 それに気づかず、半魚人の倒し方を探すなど 死ぬかも知れない事を 試していたのにあせったり。で、復活装置は拠点から随分と離れた所に 発見。でも、途中で豚小屋も結構沢山あったりして、思ったよりも面白そうな 世界だという事が判明。そんな訳で拠点を二つ持つようにしてみたり。

2014/05/23

早くも無く遅くも無く。

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

2014/05/22

早くも無く遅くも無く。

ドンスタ。豚は再生する模様。今の世界は蜘蛛がやたら居るのですが、 どれも三段階目で巨大蜘蛛だらけです。巨大蜘蛛は一度目を付けられると 振り切れなくて死ぬの確定になるのでできるだけ近づかない感じに しているのですが、そのせいで若干世界が狭くなっている気も。
そういやフリープレイは今日までだと思うのですが、いつ遊べなくなる のだろう?日付が変わった1時間後は大丈夫だったのですが....?

ちょっと勘違いしてました。どうやらフリープレイの期限は「配信期間」 であって、遊べる期間ではないという事。期間内にダウンロードすれば、 事実上 無料で購入(変な言い方ですが)しているのと同じようです。 PSPlus利用権がある限り遊べて、利用期限が切れても再度利用権を得れば (その間に削除していなければ?)再び遊べるようです。 もしPS4でのオンラインマルチプレイ目的でPSPlusを永続的に利用する予定 であれば、フリープレイソフトはすぐにやるか否かは別にして、とりあえず インストールしておけば暇な時にでも遊べば良いという感じらしい。 しまった。ならばPS3のフリープレイソフトもダウンロードしておけば 良かったかも。

2014/05/21

気持ち早めに帰着。

Emacsでseconds-to-time関数内の round関数がエラーする件。 CygwinのMailingListに「emacs oddity」というタイトルで同様の不具合が 報告されていたり。原因究明されるといいなぁ。

ドンスタ。豚を仲間にしてみたのですが、蜘蛛と戦っていたらやられてしまったり。 で、マップ上に豚小屋が1つしか無いのに気づいたのですが、もしかして あれが最後の一匹でこの世界から絶滅した?! 復活するのか様子見。 虫取り網を作ったり養蜂したり。これ、犬が居たらこんなに順調にはいかない 気がしたりも。

2014/05/20

早めに帰着。

ドンスタ。冬でもスループット的にはウサギを狩る方が食べるよりも 多いようで、少しずつウサギの備蓄が進んでいたり。冬は草も育たない ので、ちょっと燃料を確保したり、花を摘みに行ったりするくらいで 耐える感じだったり。

なにやらTVが突然映らなくなったり。どの局もアンテナレベルが0になって いたり。TVの主電源をOFF→ONしてもダメだったのでしばらく 消していたら復活したり。なんだったんだろう?と思ったら、 また映らなくなったりすぐ復活したりを繰り返したり。アンテナが 変になってるのか?

2014/05/19

早めに帰着。

ルービックキューブ40周年という事で、Googleのトップページが ルービックキューブで遊べるようになっていたり。 こうやれば良いハズ....の途中の手番をすっかり忘れてしまって いたので、Webに頼って揃えてみたり。

ルービックキューブ揃えた

回し過ぎです(^^; そういや、2010年7月に 最短手番が 20手と いうのが証明されている事を知ったり。27だか26だかというのが TANEの最後の記憶だったのですが、そこから続けられていたとは。

ドンスタ。ひたすら次の冬に備えてウサギを狩っては箱に詰めたり。 一日5匹くらいのウサギを食料にして20日過ごせれば良いという計算 をすれば100匹を備蓄できれば食料問題は無くなるハズという事で 集めていましたが、到達する前に二度目の冬到来。
そういや雨が降ると雷が落ちるのですが、草やベリーを集めた場所に 落ちると火事になってしまう場合があります。そこで避雷針を立てて おこうとしたのですが、どうにもメニューに見当たらず。 Webで調べてみると、「光る棒」ってのがそれの事らしいのですが、 「lightning rod」を直訳した結果こうなってしまったようです(^^; そりゃないよ〜。

2014/05/18

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

先日のMinGW64でのgdcビルドはコンパイラのビルドに失敗。 __strtod()がリンク時に見つからないというエラーなのですが、 MinGW32の方はlibphobosのビルドで似たようなのが出て、なんだこりゃ? という感じ。ランタイムが変なのか?ヘッダを弄ったりしてみたのですが、 ビルド通らず。

ドンスタ。蜘蛛の巣を駆除しようとしたところ、3段階目の巨大蜘蛛 が現れたので、ちょっと戦っていたところうっかり死んでしまったり。 ところが、復活ポイントを起動していなかった為(蜘蛛の巣の中にあって 起動できていなかった)、ゲームオーバー。なんてこったorz。
そしてまた再開。今度はできるだけ野営で行けるところまで行って、 バッファローの近くで農業ができて、ウサギの巣が大量に近くにあって、 石切場も近くにありそうな場所を選んで拠点を設置したり。 恐らく世界の果てを見る事ができたと思うのですが、実は意外と 広くなくて、例えばバッファローがなんか少ない配牌だと、それは そういう世界という事になるようです。前回と同じく、犬無し、冬無し にしたつもりが、犬無しだけになっていて、世界の果てを見ている 間に冬が来てしまったものですから、準備が間に合わなくて死にそう になっているのが今の状況(^^;

なんとか越冬成功。夏の間に蓄えを行えばかなり長い時間生きていける ハズ?

2014/05/17

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

ドンスタ。続きから始めたところ、いきなり野犬に襲われて死亡。 再開箇所からの復帰を試みるも、荷物を拾う前に再び野犬に襲われて 死亡。そしてゲームオーバー。なんてこと。

再スタート。ゲーム開始前に世界設定ができるのですが、 野犬無し、季節は夏のみ、というへっぽこ設定で再スタートしてみました。 なかなか岩が見つからなかったのですが、しばらく歩いていると バッファローが居たり、農場の跡が残っていたり、岩も近所にあり、 森も近くにあるというベストロケーションを拠点にしてみたり。 近くに蜘蛛の巣があるのがイマイチですが、そのうち駆除する方向で。 で、しばらくやってみたり。

それにしてもローカライズの訳が直訳過ぎて、たまに何のことやら 判らない場合があります。例えば、農場に種をまくとき、「植物」 って選択が出てくるのですが、「plant」が「植える」ではなく「植物」 と翻訳された結果だったりするようです(^^; 折角ゲームが良くできている ので、もう少しなんとかならないものかなぁ?と思ったり。

しばらくやっていると、いきなりアプリの異常終了で落ちたり。 えーー!? 調子に乗っていたので全然セーブしてなかったため 大分戻るハメに。トホホ。アプリ異常終了時、Windowsのように それを報告できるような仕組みになってました。PS4ではプレイ 動画を常に記録しているので、落ちるまでの動画を付けて報告できる ようです。折角なので送ってみたのですが、これだけでは原因に 辿り着けるとはあまり思えませんけれども。

MinGW gdc。MinGW64でのビルドを試してみる事にしたり。終らず。

2014/05/16

早めに帰着。

MinGW gdcの調査。どうやらデストラクタの中でメソッド呼び出し を行うコードで、メソッドがアクセス不可能なメモリ域になって いそうな事が判ったり。少しずつコードを絞っていった所、 比較的小さなコードで再現できたり。
そもそもMinGW gdcの問題なのか否かを切り分ける為に VMware上のFedoraでビルドして、再現コードがどのように動く のかを調べてみることにしてみたり。結果は特に問題無し。

で、MinGW gdcでずっこけるのは以下のようなコード。

$ cat -n gdc_gcc490_test2.d
     1  import std.stdio;
     2  import std.string ;
     3
     4  class TestBuf{
     5    int a ;
     6
     7    this(){
     8      a=1 ;
     9      writef("construct\n") ;
    10    }
    11
    12    ~this(){
    13      close() ;
    14      writef("destruct\n") ;
    15    }
    16
    17    int close(){
    18      a=0 ;
    19      return(0) ;
    20    }
    21
    22  }
    23
    24  int main()
    25  {
    26    TestBuf tb = new TestBuf() ;
    27    return(0) ;
    28  }

$ gdc -g -v gdc_gcc490_test2.d
Using built-in specs.
COLLECT_GCC=C:\MinGW\gdc031_2062_490\bin\gdc.exe
COLLECT_LTO_WRAPPER=c:/mingw/gdc031_2062_490/bin/../libexec/gcc/mingw32/4.9.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.9.0/configure --build=mingw32 --with-arch=i686 --enable-languages=c,c++,d,lto --prefix=/mingw/gdc031_2062_490 --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap
Thread model: win32
gcc version 4.9.0 (GCC)
COLLECT_GCC_OPTIONS='-g' '-v' '-shared-libgcc' '-mtune=generic' '-march=i686'
 c:/mingw/gdc031_2062_490/bin/../libexec/gcc/mingw32/4.9.0/cc1d.exe gdc_gcc490_test2.d -quiet -dumpbase gdc_gcc490_test2.d -mtune=generic -march=i686 -auxbase gdc_gcc490_test2 -g -version -iprefix c:\mingw\gdc031_2062_490\bin\../lib/gcc/mingw32/4.9.0/ -o C:\cygwin\tmp\cc2rQGoK.s
GNU D (GCC) version 4.9.0 (mingw32)
        compiled by GNU C version 4.8.0, GMP version 5.0.5, MPFR version 3.1.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU D (GCC) version 4.9.0 (mingw32)
        compiled by GNU C version 4.8.0, GMP version 5.0.5, MPFR version 3.1.0, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
COLLECT_GCC_OPTIONS='-g' '-v' '-shared-libgcc' '-mtune=generic' '-march=i686'
 c:/mingw/gdc031_2062_490/bin/../lib/gcc/mingw32/4.9.0/../../../../mingw32/bin/as.exe -v -o C:\cygwin\tmp\cc4u2IiN.o C:\cygwin\tmp\cc2rQGoK.s
GNU assembler version 2.23.1 (mingw32) using BFD version (GNU Binutils) 2.23.1
COMPILER_PATH=c:/mingw/gdc031_2062_490/bin/../libexec/gcc/mingw32/4.9.0/;c:/mingw/gdc031_2062_490/bin/../libexec/gcc/;c:/mingw/gdc031_2062_490/bin/../lib/gcc/mingw32/4.9.0/../../../../mingw32/bin/
LIBRARY_PATH=c:/mingw/gdc031_2062_490/bin/../lib/gcc/mingw32/4.9.0/;c:/mingw/gdc031_2062_490/bin/../lib/gcc/;c:/mingw/gdc031_2062_490/bin/../lib/gcc/mingw32/4.9.0/../../../../mingw32/lib/;c:/mingw/gdc031_2062_490/bin/../lib/gcc/mingw32/4.9.0/../../../;/mingw/lib/
COLLECT_GCC_OPTIONS='-g' '-v' '-shared-libgcc' '-mtune=generic' '-march=i686'
 c:/mingw/gdc031_2062_490/bin/../libexec/gcc/mingw32/4.9.0/collect2.exe -plugin c:/mingw/gdc031_2062_490/bin/../libexec/gcc/mingw32/4.9.0/liblto_plugin-0.dll -plugin-opt=c:/mingw/gdc031_2062_490/bin/../libexec/gcc/mingw32/4.9.0/lto-wrapper.exe -plugin-opt=-fresolution=C:\cygwin\tmp\ccu0aJ4S.res -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -plugin-opt=-pass-through=-ladvapi32 -plugin-opt=-pass-through=-lshell32 -plugin-opt=-pass-through=-luser32 -plugin-opt=-pass-through=-lkernel32 -plugin-opt=-pass-through=-lmingw32 -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lmoldname -plugin-opt=-pass-through=-lmingwex -plugin-opt=-pass-through=-lmsvcrt -Bdynamic c:/mingw/gdc031_2062_490/bin/../lib/gcc/mingw32/4.9.0/../../../crt2.o c:/mingw/gdc031_2062_490/bin/../lib/gcc/mingw32/4.9.0/crtbegin.o -Lc:/mingw/gdc031_2062_490/bin/../lib/gcc/mingw32/4.9.0 -Lc:/mingw/gdc031_2062_490/bin/../lib/gcc -Lc:/mingw/gdc031_2062_490/bin/../lib/gcc/mingw32/4.9.0/../../../../mingw32/lib -Lc:/mingw/gdc031_2062_490/bin/../lib/gcc/mingw32/4.9.0/../../.. -L/mingw/lib C:\cygwin\tmp\cc4u2IiN.o -lgphobos2 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt c:/mingw/gdc031_2062_490/bin/../lib/gcc/mingw32/4.9.0/crtend.o

$ 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 3936.0x1cbc]

Program received signal SIGTRAP, Trace/breakpoint trap.
0x77d59f46 in ntdll!RtlpNtSetValueKey () from C:\windows\system32\ntdll.dll
(gdb) where
#0  0x77d59f46 in ntdll!RtlpNtSetValueKey ()
   from C:\windows\system32\ntdll.dll
#1  0x00401394 in gdc_gcc490_test2.TestBuf.__dtor() (this=...)
    at gdc_gcc490_test2.d:13
#2  0x0041311c in rt_finalize2 (p=p@entry=0xdf1fe0, det=det@entry=false,
    resetMemory=resetMemory@entry=false)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/rt/lifetime.d:1204
#3  0x0043c7b4 in gc.gc.Gcx.fullcollect() (this=...)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/gc/gc.d:2629
#4  0x0043da18 in gc.gc.GC.fullCollectNoStack() (this=...)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/gc/gc.d:1192
#5  0x0042ac7e in gc_term ()
    at ../../../../gcc-4.9.0/libphobos/libdruntime/gc/proxy.d:138
#6  0x00411031 in rt_term ()
    at ../../../../gcc-4.9.0/libphobos/libdruntime/rt/dmain2.d:209
#7  0x004114eb in runAll (this=this@entry=0x28fed8)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/rt/dmain2.d:426
#8  0x00411161 in rt.dmain2._d_run_main() (this=this@entry=0x28fed8, dg=...)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/rt/dmain2.d:397
#9  0x0041146d in _d_run_main (argc=1, argv=0xef4ec8,
    mainFunc=0x401415 <D main>)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/rt/dmain2.d:430
#10 0x00401348 in main (argc=1, argv=0xef4ec8)
    at c:/mingw/gdc031_2062_490/include/d/4.9.0/__entrypoint.di:59

スタックダンプの#1の「at gdc_gcc490_test2.d:13」はclose()メソッドを 呼ぼうとした所です。ここにブレークポイントを置いてみるも、ステップ実行 した瞬間にSIGTRAPとなります。

$ gdb -q ./a.exe
Reading symbols from C:\cygwin\home\TANE\develop\dlang\test\a.exe...done.
(gdb) b gdc_gcc490_test2.d:13
Breakpoint 1 at 0x401383: file gdc_gcc490_test2.d, line 13.
(gdb) run
Starting program: C:\cygwin\home\TANE\develop\dlang\test\a.exe
[New Thread 6520.0x1d30]

Breakpoint 1, gdc_gcc490_test2.TestBuf.__dtor() (this=...)
    at gdc_gcc490_test2.d:13
13          close() ;
(gdb) s

Program received signal SIGTRAP, Trace/breakpoint trap.
0x77d59f46 in ntdll!RtlpNtSetValueKey () from C:\windows\system32\ntdll.dll

すでに壊れた現場って感じなので、壊した箇所を探す必要がありそう.....

2014/05/15

早めに帰着。

MinGW gdcの調査。ずっこけ方が大きく二つあり、ひとつは 自分のコード内でのメモリ割り当てがおかしくなって SegfaultやIllInstでずっこけるもの、もう一つは_Dmainを終わった後 でSegfaultになるものがあるもよう。後者の方が比較的 小さなコマンドライン実行のコードで再現したので、それで少し 追いかけてみる事にしてみたり。

どうやら、newであるインスタンスを割り当てた後、そのインスタンス に何もする事無く(コンストラクタもメンバー変数を初期化しているだけ) 、_Dmainを抜けただけでSegfaultになったり。

int main(string[] args)
{
  Image img = new Image() ;
  return(0) ;
}

幸い、スタックダンプが表示できたので見てみたところ、gcに 関係あるコードの中でずっこけています。

Program received signal SIGSEGV, Segmentation fault.
0x78746341 in ?? ()
(gdb) where
#0  0x78746341 in ?? ()
#1  0x00401419 in Image.Image.__dtor() (this=...) at Image.d:74
#2  0x00442dcc in rt_finalize2 (p=p@entry=0x1142fc0, det=det@entry=false,
    resetMemory=resetMemory@entry=false)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/rt/lifetime.d:1204
#3  0x0048db74 in gc.gc.Gcx.fullcollect() (this=...)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/gc/gc.d:2629
#4  0x0048edd8 in gc.gc.GC.fullCollectNoStack() (this=...)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/gc/gc.d:1192
#5  0x0046782e in gc_term ()
    at ../../../../gcc-4.9.0/libphobos/libdruntime/gc/proxy.d:138
#6  0x004416d1 in rt_term ()
    at ../../../../gcc-4.9.0/libphobos/libdruntime/rt/dmain2.d:209
#7  0x00441b8b in runAll (this=this@entry=0x28fed8)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/rt/dmain2.d:426
#8  0x00441801 in rt.dmain2._d_run_main() (this=this@entry=0x28fed8, dg=...)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/rt/dmain2.d:397
#9  0x00441b0d in _d_run_main (argc=1, argv=0x1284f78,
    mainFunc=0x4022a5 <D main>)
    at ../../../../gcc-4.9.0/libphobos/libdruntime/rt/dmain2.d:430
#10 0x00401348 in main (argc=1, argv=0x1284f78)
    at c:/mingw/gdc031_2062_490/include/d/4.9.0/__entrypoint.di:59

さて、どう調べたもんか。

2014/05/14

早めに帰着。

MinGW gdcの調査。どうやらメモリ割り当ての中でずっこけている 感じだったり。画像保持用に二次元配列を動的メモリ割り当てを 使用して生成いるのですが、以下のようなコードのループの途中で SIGILLシグナルを受けたり。

    ary.length = orgH ;
    for( int y=0 ; y<ary.length ; y++ ){
      ary[y] = new uint[orgW] ;
    }

今まで問題の無かったgcc-4.8.0ベースのgdcでは当然ずっこけ ません。ループの途中なのが面倒臭くて、ずっこけ現場までは 追いかけられず。スタックが壊れる為かSIGILLになった時に スタックダンプを表示できないのが辛いです。 そもそも、このループの中でずっこけるのは結果であって、 壊し始めは別の箇所という可能性もありますからどうしたもんか。

メモリを割り当てたり開放したりする小さなコードでは、ずっこけ 再現せず。

2014/05/13

早めに帰着。

シップを貼って一晩寝たら先日の状態よりは遥かにマシな状態まで回復。 でも高速に腕を上に上げるのは無理(^^;

ちょろっとだけgcc-4.9.0をベースのMinGW gdcでビルドした手持ちの WindowsアプリがSegfaultしたりIllegalInstruction実行になったり する件を調べたり。gdbでSegfaultする場合でも何やらシンボルの無い どこかをアクセスしている感じだったので、ステップ実行でどこで ずっこけるかを追いかけてみる事にしたり。でもまだずっこける 瞬間まで追いかけられず。

2014/05/12

昨日の夜から急に左腕が上がらなくなり、朝の時点で痛くて全く 動かせそうになかった為、急遽休みに。

いわゆる四十肩だと思われますが、どうにもやりようが無いものらしいので しばらく安静。それにしても、どの腕をどんな位置にしても痛いと いうのはかなりの重症。

午後になるとなんとか痛みが引いて来たので、ゴソゴソと起きては 録画消化したりドンスタやったり。

ドンスタ。オートセーブを切って、自分で適当なタイミングでセーブするように したり。ただし、ゲームをセーブせずに終了する方法が無いので、 死んだ場合は アプリを終了させる方法で強制終了させる感じで。 また、セーブだけをする方法は無いので、セーブ後は一旦メニューに戻って、 プレイ再開するという感じになります。また、あるセーブデータから プレイ再開した後、少し進めて別のセーブデータとしてセーブする事も できません。この為、死ぬ直前の場面でセーブしてしまった....なんて のを防止する事もできません。オートセーブしない場合の手順が 煩雑なのは、そういうやり方を想定していないからなのかも知れませんが、 昔のオートセーブの無いゲームでは普通にできていた事ができないと いうのは不思議です。

しかし、今回のマップは配牌が悪く、金鉱山はかなり離れた場所にあるわ、 バッファローが見つからなくて肥料が作れず農業ができないわで、 かなり厳しい感じになってます。どうにかゲーム内で30日を過ごし、 冬をどうにか越えられそうな所ですが、食料が取れる場所を拠点にしても、 遠出できる限界箇所に再び食料が取れる場所が無いので、行動範囲が 広がらなくなっています。うーむ。

2014/05/11

昼頃起床。

洗濯したり掃除したり。

そういえば、Emacsでseconds-to-time関数内の round関数がエラーする件。 再コンパイルしても出ていたのですが、configure実行からやり直して いなかったなぁ?と思い、そこからビルドし直してみたり。 そうした所、エラーしなくなったような気が。むむ、そういう事なの?
.....と思ったけどそんな事は無かった。再現のきっかけがいまひとつ良くわからない。

「Don't Starve」。ドンスタ。Webで少し検索してみたところ、 こちら のブログサイトを知ったり。なるほど、こんな感じになるのかと 参考になったり。クリア自体は特定のアイテムを全て集めてとある 場所に置けば良いらしい。

という事を踏まえて再プレイ。今回のマップは金が大量に置かれていて、 直ぐに科学機械を設置でき、ウサギも沢山いたので食料を確保しつつ 行動範囲を広げていけました。しかし、順調にプレイしていた所で野犬に 襲われて武器で交戦するも死亡。困った事にこのゲーム、途中セーブしていても 死ぬとオートセーブで死んだ事が記録されてしまう為、結果的に途中セーブの 記録が無くなってしまいます。なんてこった。心が折れる系かも。

PS4を買った時の特典でPSPlusの3ヶ月間お試し権を取得した訳ですが、 そういや、PSPlusってPS4だけに限ってなくて、PS3のフリープレイ も遊べるっていうのに今頃気づいたり(^^;

2014/05/10

昼頃起床。

TVで知った、振った炭酸飲料を噴き出さずに空ける方法。 容器の内側に付いた泡をデコピンで落としてから空ければ 良いらしい。「炭酸飲料 吹き出さない」のキーワードで 検索するといくつか方法はあるようですが、基本的には 同じ。蓋を開けた時に気圧が下がって泡が膨張 する際、液体を巻き込むから吹きこぼれる、というのがその原理。 なので、液中に存在する泡を減らしておけば良いという事みたい。

全然関係無い流れで 「 ガンダムは王蟲の突進を止められるか物理エンジンで検証した。」 なる動画を知ったり。シュールな感じに ぷっ ときた。 この動画を投稿した方は、他にも物理エンジンを使った色々な 動画を投稿しているようです。

PSPlus の今月のフリープレイで「Don't Starve」 が遊べるようになってるのですが、5/20までとなっていたので ちょっと手を付けてみたり。表示される文字のローカライズは かろうじてされているものの割と直訳だったり、OKが×ボタン、 キャンセルが○ボタンと操作系は洋仕様のままになってます。 ほとんど説明無しでいきなりゲームが始まりますが、 しばらく弄っていると、どうすりゃいいのかがなんとなく わかって来る感じです。いきなり野原のようなフィールドに 放たれるのですが、草や石やらを拾って道具を作り、フィールド に居る動物を狩ったり、してとにかく生き延びれば良い ようです。行動範囲を広げながら何日か生きていると、 何やら怪しげな生き物が増えて来るようです。でも、 どうにかなったのはそこまで。死ぬとそこでゲームオーバー になるという感じ。コンティニューは無く、ゲームスタート するとフィールドが自動生成されて最初から始まります。 ゲームタイトル通りDon't starve:餓死するな という事 なので、そういうゲームなのだろうと思われます。 そんな訳で気づくと結構時間が吸われていたり(^^;;

2014/05/09

飲み会で気持ち遅めに帰着。

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

2014/05/08

遅めに帰着。

とある英語の文章があったのですが、Google翻訳だとなんだか 意味が違うような訳になったり。

          原文 : I only sold ten cars, not fifteen.
    Google翻訳 : 私は10の車ではなく、15を販売した。
エキサイト翻訳 : 私は単に15ではなく10台の自動車を売りました。
    Yahoo!翻訳 : 私は、10台の車(15でない)を売るだけでした。

苦手な文脈があるのかも。

2014/05/07

気持ち早めに帰着。

ちょろり調べ事。

2014/05/06

昼頃起床。

ここ数日、「進撃の巨人」のアニメを観てました。乗り遅れたので 少し落ち着いた所で観てみようと思った次第です。そんな訳で原作も 読んでいません。で、ものの見事にハメられました(^^; 主人公が早々に食われるとか、なかなかな展開に続きが気になって しまう感じでした。概ね原作通りのようで原作はまだ続いています から、どうなるんだろう?といった所でしょうか。 Wikipediaでアニメの少し先の話を読んだ感じでは、これ、話が破綻 しないのだろうか?と思うような流れだったのですが、どう繋がっていくのか 気になります。
それにしても、立体機動で飛び回るアクションだとか、格闘のアクション だとか、こんなに動くアニメってあまり見たこと無いかも。さすが Production I.G(制作は WIT STUDIOっていうProduction I.Gから独立 した子会社のようですが)。

2014/05/05

地震で一瞬起きては寝て、ゴミ出しで一瞬起きては寝て、起きたらお昼(^^;

魔女の宅急便の文庫本を買った時にたまたま目に入ったので 買ってみた「リケジョ!(伊与原 新)」読了。 2011年9月に刊行された単行本「プチ・プロフェスール」を改題して 文庫化されたものらしい。「リケジョ!」の初版は2014年2月25日 なので、関係しているか否かは判りませんが、STAP細胞のそれに 合わせての文庫本化だったのかなぁ?と想像したり。仮に意図が あったとして、まさかあのような事態になるとまでは思わなかった かも知れませんが。
カガクでもって、噂話の解明に始まって、殺人事件の犯人を突き 止めたり、様々な騒動を解決していきます。最後は思わぬ人間関係があったのに やられちゃいました。

2014/05/04

AM中に起床。

ちょろりお出かけ。

そういやEmacsでバッファを全選択してkill-ringに入れるコマンドが あったなぁ?と思うのですが、あまり使わないのでスグに忘れて しまいます。因みに、コマンドはmark-whole-bufferで、デフォルトの バインドは「C-x h」でした。
ところで、Web上にある様々なEmacsのキー操作とバインドを示した ものの中に、コマンド名が付加されていないものを見かけます。 キーバインドは設定で変えられるので、バインドだけを示すよりは、 コマンド名を示してもらった方が都合が良いように思います。 因みに、コマンドがどのキーにバインドされているかは「M-x describe-bindings」 で出てくる一覧から探しています。逆に、キーバインドから割りあたっている コマンドを引くには「M-x describe-key」でキー操作をすれば 調べられます。

2014/05/03

AM中に起床。

homeディレクトリにsshのスタックダンプがあったので、なんだこれ? と思って調べてみたところ、Emacsの起動時に生成されている事が判ったり。 ssh単品で使ってみたところsegfaultしたり。ところが、gdb上で動かすと 普通に使えてしまったり。うーむ。 仕方なく、cygwin本体とsshを再インストールするというトホホ対応 してみた所、segfaultしなくなったり。うーむ。

text-translatorが動かなくなった件はやっぱダメ。普段使っている emacs-w32でダメだったので、emacs-X11を -nwで使ってみたり、 VMware上のFedoraのEmacsで使ってみたりしたのですが、いずれもダメでした。 いつからか使えなくなり(このときはまだMeadow3でしたが)、 その後いつの間にか再び使えるようになっていたのに 気づいたのが1年ちょい前 (このときにはemacs-w32に乗り換えた頃でしたが)で、しばらく 大丈夫だったのですが、何が契機になっているのやら?

seconds-to-time関数内の round関数がエラーする件について、何か 情報が無いかと CygwinのMailingListアーカイブを見てみたり。 関係あるか否かは判りませんが、「Fatal error from Cygwin emacs-w32 every day or so」 というタイトルのスレッドがあり、何かしらの契機で落ちるらしい 旨の報告が挙がってました。タイマーイベントに関係するのか? とか色々と推測が挙がっているようですが、原因までは辿り着いていない もよう。Fatalするとバックトレースが見られないので 原因に到達できていないようですが、タイマーイベントに関係する のであれば、round関数がエラーするのは いくつかある見え方の 一つという可能性も考えられるかも。MLの方は顛末を追いかけて みる事にしよう。

2014/05/02

本日はお休み。AM中に起床。

MinGW対応のgdcビルド。手を入れながら進めてビルド完了した ものの、make installして使ってみるも、TLS関連の関数が 軒並み見つからなくてダメでした。 README-MINGW.mdというドキュメントにパッチがいくつか 必要な旨が書かれているのを適用していなかったのが 原因の一つでした。
パッチを当ててビルドしてみると、 特に手を入れる必要無くビルド完了しました。 しかし、make installして適当なソースをコンパイルして みるも、

..... gcc-4.9.0/libphobos/libdruntime/core/demangle.d:443: undefined reference to `__mingw_strtold'

てな感じで、strtold()という外付けのC言語関数がリンクできず。 でも、この関数って4.8.0でも使っていて、リンクできない ハズは無いのだが?と思ったり。

どうやら、core/stdc/stdlib.dにMinGWの時だけ strtold()の __mingw_strtold()へのaliasが加えられていました。このaliasは 以前のバージョンにはありませんでした。いつ加えられたんだろうと 思い、 こちらのHistoryで見てみたところ 「2013/6/12:Merge D 2.063 front-end.」から 「2013/6/14:Fix most severe new front-end breakages.」 の変更で加わったようです。という訳で変更前と同じように strtold()のaliasを削って再度ビルドしなおしてみたり。で、 簡単な手持ちコードをコンパイルしてみたところ、今度は リンクに成功しました(^o^)/

過去に単体で問題のあった件について確認したり。


HelloWorldレベルのコードは問題無くコンパイル&実行できるようです。

で、手持ちのWindowsアプリのコードをコンパイル&実行してみたの ですが、Segfaultで立ち上がらなかったり、少し操作すると IllegalInstructionで落ちたりで、うまく動かない実行ファイルが生成されたり。 うーむ、残念。 メモリ割り当てかスレッド管理に問題がありそうな予感。 以前、gcc-4.7.xをベースにしていた時は、どうにかコンパイルできたけど 実行可能なバイナリを生成できませんでしたが、それと同じ感じか。

そういえばInternetExplorerの脆弱性の話。ニュースなどで 「メモリを破壊する」という表現を使っていたのですが、これを聞いて 物理的に壊れると思った人はどれだけいるだろう?と思ったり。 コンピュータ用語(の一部)って普通の人に説明するのが難しいよなぁと 思ったりも。

何故かEmacs上で動作するtext-translator (kill-ringに入れたテキストを直接翻訳サイトに流し込んで翻訳結果を得られるELISP) が動かなくなったり。round関数でエラーする時も使えていたので、 Cygwinアップデートした事とは関係無いとは思うのですが....?

2014/05/01

早めに帰着。

MinGW対応gdcのビルドを試したり。結果から言うと途中でコンパイル エラー。少し手を入れてみるも、突っかかりどころがいくつか ある模様。32bitのMinGWでビルドしているのが原因の可能性も あるかも知れませんがそういう事では無いような気も。

少し時間がかかりましたが、「魔女の宅急便(4),(5),(6)」を読了。 結局、原作のキキはショートヘアーでは無さそうですが、ロングヘアー である事をうかがわせる描写は見つけられませんでした。 ジブリのとは色々と違ってますが、原作独特の雰囲気は面白かった と思います。


TOP PREV