もそもそとコーディング。 マンデルブロ集合プログラムをウインド表示できるようにしてみたり。
パラメータ変更や色づけ変更を簡単に変えられるようにしたいなぁと 思う訳ですが、どうするのが良いかは考え中。
AM中に起床。
掃除したりTV見たりしながらぐうたら過ごしていたら、日付けの変わる30分前ですよ(汗;
そんな訳で今年を少し振り返ってみたり。今年はまぁまぁコーディングに
時間を使ったような気も。一番大きかったのはgdcがMinGW向けながら
ビルドが可能になり、現在も本家に離される事無く追従されている点でしょうか。
今年は震災の影響があったり、PNSがサイバー攻撃に遭ったりで、ゲームは
あまり消化できなかったかも。
昼過ぎ起床。体調は悪いまま。
コマンドラインでテストしていたマンデルブロクラスをウインドアプリ
に組み込んでみたり。位置指定なんかもmpfで計算しないとダメな感じ
なので、あれこれいじってなんとか組み込み完了。
体裁を整えたり。その中でズームを繰り返していると、何やら模様に
再帰感が無くなったり。閾値判定を繰り返す回数を増やすと模様が
現れる様になったり。
深夜にANIMAXでやってた頭文字Dのアニメの再放送をなんとなく
観てたら面白くて朝まで観てしまったり(^^;
AM中に起床。なんか軽く風邪気味かも。
GMPの関数の一覧を眺めていたらaddmul()とかあったので、これでほんの少しだけ
高速化できるかも？と思ったら、mpf_t 型用のaddmul()関数は用意されて
なかったり。ちぇっ。それにしてもなんでだ？
具合が悪くなって、ちょろっとコーディングしてはぐったりしたりを繰り返し。
早くも無く遅くも無く。
GMP使用の続き。結局GMP関数を直接使って 6時間くらいかかっていたのを
25分くらいに高速化。ただし、元の式が良くわからない感じになったり。
でも、ウインドで操作するには待てないレベルかも。
あまりの眠さに急速停止。
日付け越え。
昨日の例外の件。構造体のデストラクタが関係している気がしたり。
構造体の引数や構造体返しの場合、ポインタ以外は値のコピーが渡されます。
この時、構造体メンバー変数にポインタ変数が含まれていて、デストラクタで
そのポインタをfree()してしまうような仕組みだったとします。
そのような構造体を引数とする関数に渡すとどうなるかと想像すると、
関数呼び出しが終わった時に関数に引数渡しされた構造体インスタンスは
スコープを外れるので消滅する際にデストラクタが実行されます。すると、
ポインタがfree()されてしまう訳ですが、これは関数呼び出し元の
構造体インスタンス内のメンバー変数のポインタが指す領域でもある為、
いつの間にか保持していたハズのメモリが開放されているという事に
なるのではないか？と思った訳です。
簡単なコードで再現例を作ってみようとしたのですがうまくいかず(^^;
ともかく、ダメな事に変わりないので、他の高速化方法が無いか探ってみたり。
すると、ある条件を満たせば クラスでもスタックにインスタンスを割り当られる
のを知ったり。早速試してみた所、確かにスタックにインスタンスが割り当て
られていそうな感じなのですが、速度に関係のある肝心な所がスタックに
割り当てられず。うまくいかないなぁ。
日付け越え。
先日のGMPずっこけ調査を少しだけ。デバッガで少し追いかけてみたのですが、
なんだか意図しない動作になっているような。mpf_tな変数を2つ用意し、
それを比較して、条件を満たせばwritef()でメッセージを出すという
単純なコードなのですが、何故かこのコードの中でデストラクタが
発動していたり。なんだか良くわからないのは、このコードの中では
捨てられるような mpf_t な変数は無いハズなのに、何故かデストラクタ
が発動しているという点。で、何故か捨てられた mpf_t な変数の
内容を表示しようとして、例外が発生している模様。うーむ。
AM中に起床。
GMPを使う応用の続き。なんとなく意図通りになったり。
んー？なんか思い通りにならないなぁ？
ここ数日GMPをいじっている訳ですが、そもそものきっかけは
マンデルブロ集合を6.4e17倍くらいに拡大した時、
浮動小数点の精度限界から絵の解像度が上がらなくなった為、
それをどうにかできないかなぁ？という所から来てました。
で、GMPのD言語ポーティングを使用してみた訳なのですが、
クラスで実装されている所もあってか、1枚の絵を得るのに
6時間くらいかかってます。そこで、クラスによる実装から
構造体による実装に変えてみたのですが、何故か思い通りに
ならない。これが現在の状態。
mpf_tという値を保持する構造体をGMPの演算関数群に渡して
結果を得る仕組みになってます。で、てっきりこの構造体に値が
入っているのかと思っていたのですが、どうやらハンドラという
位置付けで、値の実体をこの構造体に持っている訳では無いようです。
この為、使わなくなったものはmpf_clear()でもって開放しないと、
メモリリークしてしまうようです。ところが、ポーティングをクラスから構造体
に変えた際に、デストラクタについてはクラスで実装されて
いたままmpf_clear()を実行するようにしていたのですが、
何故かそこで死ぬという謎の挙動が起こっていてどうしたもんか
調査中。
朝から休出。早くも無く遅くも無く。
GMPを使う応用の続き。実験コードの消し忘れでバグらかしてたり。
あまりの眠さに急速停止。
朝から休出。
GMPを使う応用の続き。
あまりの眠さに急速停止。
遅めに帰着。
GMPを使う応用。
遅めに帰着。
GMPを使う練習。
遅めに帰着。
GMPを使う練習。
遅めに帰着。
任意精度の数を扱うライブラリについて調べごと。
GMPとかMFPRとかgccのビルドに必要だったのですが、本来の目的で
使う方法を調べたり。
昼ごろ起床。
ぐうたら過ごして終了。
ちょろりコーディング。
ほこたてスペシャル。浄水器と醸造職人の効き水対決。まさか匂いの違いで浄水器を
通した水道水を効き分けて職人の勝ち。文字通り嗅ぎ分けるとは驚きです。
起きたら夕方(汗; 寝すぎ。
gdcのDMD2.057マージ版をビルドしてみたり。un.dのコンパイルでmakeがストップ
して、もう一度make実行すると通るのはいつも通り。それ以外は特にエラー無く
ビルド終了。で、make installして手持ちのコードをコンパイルしてみるのですが、
いくつか具合が悪い所があったり。
遅めに帰着。
gdcのDMD2.057マージが来ていたり.......って今回早っ！！ 昨日一周遅れだ
と書いたばかりなのに(^^;
少し早めに帰着。
DMD2.057がリリースされている模様。gdcは丁度一周遅れという感じかも。
出張。帰着。
眠くて死亡。
出張。
出張。
昼ごろ起床。
もそもそとコーディング。
マンデルブロ集合プログラムをウインド表示できるようにしてみたり。
パラメータ変更や色づけ変更を簡単に変えられるようにしたいなぁと
思う訳ですが、どうするのが良いかは考え中。
昼ごろ起床。
2.056マージされたgdcで手持ちコードのコンパイル確認。
今回はソースをいじって対応する必要のあるエラーは無し。
ところで、2.055から色々変わっているハズなのですが、
本家ページのChangeLogページの2.056に対する変更点が何故か
消えてしまっていて、何がどう変わったかさっぱり判らなくなってます。
もそもそとコーディング。
早くも無く遅くも無く。
gdcのDMD2.056アップデート版をMinGWでビルドしてみたり。
libphobos/core/sys/posix/sys/un.dでコンパイルエラーするのを何も変えずに
再度make実行すると通る件はそのまま。エラー無くビルドできたのですが、
手持ちソースをコンパイルするとリンクでエラー。一つは
__sync_fetch_and_add_4が見つからない件。これはphobosの
コンパイルオプションに-march=i686を指定して再コンパイル＆再インストール。
もう一つはstd/windows/registry.dで色々見つからなくてリンクエラー。
std/internal/windows/advapi32.dがコンパイルされてない予感。
違う直し方で回避してしまったのですが、これはすぐ直される事を期待。
で、マルチスレッドな手持ちコードの一部が起動に失敗する事があるのは
いつも通りだったので、自前パッチを当ててなんとなくこれまで通りに
使える感じになったり。
見てるだけでエラー無くビルドできる感じになってないので、直って
くれると良いなぁという感じ。
遅めに帰着。
gdcのDMD2.056対応が来ていたり。今回もまた大量の差分があって、
Web表示がままなりません(^^; 毎度御苦労様です。
気持ち早めに帰着。
あまりの眠さに急速停止。
気持ち遅めに帰着。
そういえば、MinGWでgdcのビルドを試した時、ビルドは完了するものの、
手持ちコードのコンパイル＆リンクで __sync_fetch_and_add_4 なる
シンボルが見つからなくてリンクに失敗してました。
gdcの掲示板でビルド済みのバイナリを試した人が同様の不具合がある点を
報告していたり。そんな訳ですぐに修正されそうな予感。
それにしても、今まで報告されなかったのは、
みんな64bitマシンを使っているからなのだろうか？
もそもそとコーディング。
遅めに帰着。
もそもそとコーディング。
昼過ぎ起床。
ちょろり日用品の買出し。
おもむろにマンデルブロ集合を描くプログラムについて調べたり。
プログラムソースとなると意外と見つからない(^^;
複素平面上の集合で計算過程でも複素数を使った式となっている
のですが、C言語だと複素数型が無いので、イマイチ式が判りにくい
感じになります。で、D言語の複素数型を使ってみる訳ですが、
見た目が式通りでなんとなく判りやすい気がしたり。
昼頃起床。
PPCクロスのglibcビルド。終わらず。でもエラー無く進んでいる模様。
ちょいとお出かけ。帰りに川崎ヨドバシに寄ったのですが、レイアウトが
大幅に変更されてたり。人が尋常じゃないくらい入ってました。
19時間がかりでglibcのビルド終了。make install。そしてgccの2回目の
ビルド。野良ビルドしていたmsgfmtがいつの間にか動かなくなっていた
のが原因でエラー。パッケージインストールしたmsgfmtを使用する事で
問題無くビルド完了。テストに使用したIJGのツールのビルドも問題無く
ビルド完了＆ppcsimでの実行もOK。予定外に時間がかかってしまいましたが、
ひとまず大丈夫そうです。
ppcsimの方は一応Linux対応完了。ただしグラフィックデバイスは
未サポートです(^^;
そんな訳でプロ遊の下にppcsim-0.98とPPCクロスツールのビルド方法(2011.12.04)
を置いてみました。ただ、ツールビルドの方はglibcのヘッダアーカイブが
まだ置けてません。少々お待ちを......
早くも無く遅くも無く。
PPCクロスのglibcビルド。使用しているファイル拡張子.oSを.ossに変更して
ビルドできないのか試してみる事にしてみたり。
6個のファイルをsedで文字列置き換え。で、Fedoraの方で試してうまく
いったので、Cygwinの方にも投入。終わらず。
遅めに帰着。
PPCクロスのglibcビルド。そもそも、--disable-sharedで共有ライブラリを
ビルドせずにスタティックライブラリだけで構成できれば、.oS問題は解消
できるハズなのですが、--disable-sharedを付けてconfigure実行した後、
makeしても、一部のライブラリが共有ライブラリ使用前提でビルドされて
しまう為、そこでエラーしてしまうのが問題なのです。そこで、共有ライブラリ
を使用するものを外してビルドできないか試してみたり。
結果はダメでした。ぐふっ