2015/01/31
寒さでAM中に起床。
PS4のアーケードアーカイブスに来ていたグラディウスをポチってみたり。
アーケードアーカイブスって事前に何が出るか予告があるように思っていた
のですが、グラディウスはなんだかいきなり来ていたように思います。
30周年と何か関係があるのかしら？さておき、
連射無いと辛いわとか、あれ？コンティニューって無いんでしたっけ？とか
そんな感じ。連射はコントローラ設定でどうにかなるものの、コンティニュー
はどうにもならないので4面が越えられないというヘボさです(^^;X68kのは
クリアできてたような気がするのですが寄る年波には勝てません。
当時はそうでも無かったように思うのですが、近年の弾幕系シューティング
に比べると自機の動きが荒くて やたら激突死するように感じます。
グラディウスのWikipediaの中に、
「キャラクター数オーバーを起こしている時にタイミング良くオプションを付けると、オプションが5つになることがある。」
というのが書かれていて本当か？と思ったり。てかそれ、仮に
5つ付いたとしても、その後ゲームがストップしてしまいそうな
バグのように思ったりも(^^; あと、復活地点設定が当時のハードの
制約から来ていた為というのにも本当？と思ったり。
直感的にはその場復活の方が簡単なように思うのです
(グラディウスの2ヶ月前にアーケード稼動したツインビーではできていた
と思いますし)。
結局、ナンバリングタイトルはVまで、コンソールでの新作はWiiの
ReBirthまで(2008年9月)というのは少し寂しい気がしたりも。
以前、Vが出るちょっと前に
「30年とか50年に渡って出たらそれはそれでスゴいよね」と書いた事が
あったのですが、残念ながらそういう訳にはいかなかったようです。
MinGW-gdc調査。先日、2.066.1では関数呼び出し自体は問題無さそう
と書いたのですが、やっぱり問題あるような気が。
2015/01/30
遅めに帰着。今回の雪は積もる感じではなかったもよう。
Cygwinのパッケージをアップデートしたのですが、アップデート後
Emacsの再ビルドでテストしてみようとした所、configure実行に
異常に時間がかかったり。タスクマネージャで見ていると、
リンカ(ld.exe)が目に見えるくらいの時間動いている、つまり
リンクに時間がかかり過ぎているような気がしたり。
binutilsもアップデートされていたのですが何か関係があるのかしら？
と思いながら見ていたら、何やら途中からやる気を出していつもの
速度で進んだり。再度試してみるも再現せず。なんだったんだろう？
そういえば、ローマ字入力で「ふ」を入れる時、いままで意識して
いなかったのですが、「hu」ではなく「fu」って入れてるのに気づいたり。
「hu」だと右手のみでの入力になるので、両手を使う「fu」よりも
若干入力しづらいというのはありますが、いつから「fu」入力
するようになったのかは全く思い出せず。でも「ふじさん」は
「fujisan」ですよね。英語で「Mt. Fuji」って言うくらいだから。
2015/01/29
遅めに帰着。
DMD2.066.1ベースのMinGW-gdcでずっこける実行ファイルが生成
されるのですが、2.065ベースのそれとずっこけ方が違っている
感じだったり。2.065ベースの時は関数呼び出しをした所で
引数がうまく渡らない感じだったのですが、2.066.1では
そもそもどこかでデータが壊れていて、関数呼び出し自体には
問題が無さそうだったり。うーむ。
2015/01/28
遅めに帰着。
調べ事をして終了。
2015/01/27
遅めに帰着。
WBSでやってた緑のコーラの話。甘味料にステビアを使用している
との事ですが、どっかで聞いた事があるような？と思って
調べてみたら「ポカリスエット ステビア」ってのが出てきて、
あぁこれだと思ったり。
ポカリスエットの
Wikipedia
によると、2007年に販売終了していた事を知ったり。
もし今も売っていたとすると、緑のコーラはあまり話題に
ならなかったかも？
MinGW-gdc調査。掴めず。
2015/01/26
遅めに帰着。
Web巡回して終了。
2015/01/25
昼過ぎ起床。
掃除したり、洗濯したり。
2.066.1ベースのMinGW-gdc。x86_64の方で手持ちコードのビルド確認を
してみたり。いくつかのコードがSegfaultする状況なのですが、
外付けライブラリの中で発生しており、なんだか変な動きをしている予感。
デバッグシンボルを付けてみたところ、連想配列に関連するphobos内
のコードでSegfaultを検出していたり。うーん、なんかバグっているのだろうか？
SAI2の新しいのを試してみたり。パース定規を使って遊んで
いたのですが、描いている間にいつのまにかレイヤーが動いていて
あれぇ？な状態になったり。
円定規と併せて使っていたのですが、定規の移動とレイヤーの移動が
同じ操作なので、定規を動かすつもりがレイヤーを動かしていたのかも。
2015/01/24
昼過ぎ起床。
x86_64ターゲットのMinGW-gdcをCygwinでクロスビルド。
一応ビルドに成功。手持ちのコードのビルドも大丈夫そう。
MinGW-gdc調査。構造体のメンバー関数呼び出しのGIMPLEについて
少し確認。以下のようなD言語コードの場合、
$ cat -n struct_memfunc.d
1 import std.stdio ;
2 import std.string ;
3
4 struct TestStruct{
5 int x ;
6
7 int add(int a){
8 x += a ;
9 return(x) ;
10 }
11
12 }
13
14 void main()
15 {
16 TestStruct ts ;
17 ts.add(10) ;
18 return ;
19 }
「i686-pc-mingw32-gdc.exe -frelease -fdump-tree-all struct_memfunc.d」で
生成したGIMPLEは以下のようになってました。
$ cat -n struct_memfunc.d.004t.gimple
1 main (int argc, unsigned char * * argv)
2 {
3 int D.3138;
4
5 D.3138 = _d_run_main (argc, argv, _Dmain);
6 return D.3138;
7 }
8
9
10 add (struct TestStruct & this, int a)
11 {
12 int D.3141;
13 int D.3142;
14 int D.3143;
15
16 D.3141 = this->x;
17 D.3142 = D.3141 + a;
18 this->x = D.3142;
19 D.3143 = this->x;
20 return D.3143;
21 }
22
23
24 D main ()
25 {
26 int D.3145;
27 struct TestStruct ts.0;
28 struct TestStruct ts;
29
30 try
31 {
32 __builtin_memset (&ts.0, 0, 4);
33 ts = ts.0;
34 add (&ts, 10);
35 D.3145 = 0;
36 return D.3145;
37 D.3145 = 0;
38 return D.3145;
39 }
40 finally
41 {
42 ts.0 = {CLOBBER};
43 ts = {CLOBBER};
44 }
45 }
46
47
48 _D14struct_memfunc9__modinitFZv ()
49 {
50 struct
51 {
52 void * next;
53 struct Object & mod;
54 } * _Dmodule_ref.1;
55
56 _Dmodule_ref.1 = _Dmodule_ref;
57 __mod_ref.3135.next = _Dmodule_ref.1;
58 _Dmodule_ref = &__mod_ref.3135;
59 }
60
61
TestStruct.add()はGIMPLE上(10〜21行目)はただのadd関数となり、
引数として自分自身を指すthisポインタを自動的に挿入しています。
そして呼び出し側は、34行目のように「add (&ts, 10);」てな
感じで、構造体の実体もポインタで渡す感じになってます。
で、件のずっこけコードのGIMPLEを見てみます。dmd2.065ベースの
MinGW-gdc(i686)での呼び出し元は以下の感じ。
libphobos/libdruntime/object_.d
971 override size_t getHash(in void* p) @safe pure nothrow const
972 {
973 assert(p);
974 if (xtoHash)
975 {
976 return (*xtoHash)(p);
977 }
978 else
979 {
980 return hashOf(p, init().length);
981 }
982 }
object_.d.004t.gimple
3316 getHash (struct TypeInfo_Struct & const this, const void * const p)
3317 {
3318 uint (*<T6c6>) (const void * const) D.6106;
3319 uint D.6109;
3320 int (*<T6d>) () * D.6110;
3321 int (*<T6d>) () * D.6111;
3322 struct TypeInfo_Struct::<T6d9> (struct TypeInfo_Struct *) * D.6112;
3323 struct D.6113;
3324 uint D.6114;
3325
3326 {
3327 D.6106 = this->xtoHash;
3328 if (D.6106 != 0B) goto <D.6107>; else goto <D.6108>;
3329 <D.6107>:
3330 {
3331 D.6106 = this->xtoHash;
3332 D.6109 = D.6106 (p);
3333 return D.6109;
3334 }
3335 <D.6108>:
3336 {
3337 D.6110 = this->__vptr;
3338 D.6111 = D.6110 + 44;
3339 D.6112 = MEM[(struct TypeInfo_Struct::<T6d9> (struct TypeInfo_Struct *) * *)D.6111];
3340 D.6113 = D.6112 (this);
3341 D.6114 = D.6113.length;
3342 D.6109 = hashOf (p, D.6114, 0);
3343 return D.6109;
3344 }
3345 }
3346 }
で、呼び出される方は以下のような感じ。
libphobos/src/std/internal/uni.d
408 size_t toHash() const pure nothrow @safe
409 {
410 size_t hash = 5381+7*ivals.length;
411 if(!empty)
412 hash = 31*ivals[0] + 17*ivals[$-1];
413 return hash;
414 }
uni.d.004t.gimple
1499 toHash (const struct CodepointSet & this)
1500 {
1501 uint D.5440;
1502 uint D.5441;
1503 bool D.5442;
1504 signed int D.5443;
1505 bool D.5444;
1506 bool D.5445;
1507 uint * D.5448;
1508 sizetype iftmp.32;
1509 struct D.5452;
1510 const uint * D.5453;
1511 uint D.5454;
1512 uint D.5455;
1513 uint retval.33;
1514 uint iftmp.34;
1515 uint D.5458;
1516 struct D.5462;
1517 uint retval.35;
1518 sizetype D.5464;
1519 const uint * D.5465;
1520 uint D.5466;
1521 uint D.5467;
1522 uint D.5468;
1523 uint hash;
1524
1525 D.5440 = this->ivals.length;
1526 D.5441 = D.5440 * 7;
1527 hash = D.5441 + 5381;
1528 {
1529 D.5442 = empty (this);
呼び出し側のobject_.d:976行目は「(*xtoHash)(p)」となってて、
このコードだけでは分かりませんが pは「CodepointSet」という構造体への
ポインタを指している事になってます。GIMPLEの 3332行目の通り、pだけが引数
となってます。そして、呼び出され側の
toHash()は「CodepointSet」構造体のメンバー関数で、
D言語ソース上は引数無しのように見えますが、GIMPLEでは自分自身を指すthisポインタ
が自動挿入された形になっています。
D言語のコードで見ると引数が合っていないように読めるので変じゃないか？
と以前述べたのですが、
GIMPLEで見てみると実は変では無いらしいというのがなんとなく分かってみたり。
2015/01/23
遅めに帰着。
gdcの2.066.1がmasterブランチに統合されていたり。それに合わせて
gdc-4.9の方も2.066.1ベースになっていたので、CygwinでMinGWターゲット
のクロスコンパイルを行ってみたり。masterに統合される前には、
色々手を入れてMinGWネイティブのビルドには成功したものの、クロス
コンパイルはcc1dがICEでお亡くなりになりビルドに失敗してました。
で、今回はクロスコンパイルは成功。
使用したGDCバージョンは
GDC-b7ec7e2515a2041d9e81139ce504dd140b2b170aです。
$ i686-pc-mingw32-gdc.exe -v
Using built-in specs.
COLLECT_GCC=i686-pc-mingw32-gdc
COLLECT_LTO_WRAPPER=/usr/local/gdc031_20661_492_mingwcross/libexec/gcc/i686-pc-mingw32/4.9.2/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.9.2/configure --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-mingw32 --enable-languages=d,lto --prefix=/usr/local/gdc031_20661_492_mingwcross --with-sysroot=/usr/i686-pc-mingw32/sys-root --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap
Thread model: win32
gcc version 4.9.2 (GCC)
$ i686-pc-mingw32-gdc.exe iam.d
$ ./a.exe
I am GNU
I am Windows
I am MinGW
I am Win32
I am X86
手放しではエラー無くビルドできませんでした。
例えばlibphobos/src/std/stdio.dとかは、コンパイルエラーしないようにしただけの
かなりデタラメな対応を行いました。
きっとMinGW用のバイナリパッケージを作成しようと思うとビルドに失敗
すると思いますので、うまく直してくれる事を期待しよう(^^;;
で、ずっと調べているずっこけは、
以前試した通り、
クロスコンパイラにおいても再現します。
2015/01/22
遅めに帰着。
MinGW-gdc調査。GIMPLEを眺めたり。ちょっと掴みかけたようなそうでも
ないような。
2015/01/21
早めに帰着。
SAI2の新しいのが出ているのに気づいたり。おつかれさまです。
週末にゆっくり試してみよう。
MinGW-gdc調査。mingw用のtlsパッチをあてずにビルドして、関数入り口
のコードが変わるか観察してみたり。結果はパッチ有りの場合と
全く同じコードが生成されました。という事はMinGWの為にやってる事が
悪さをしている訳では無さそう。逆にMinGWの為にやらなくてはならない事が
抜けているという可能性もあるので、フロントエンドが悪いのかバックエンドが
悪いのかは判断できず。
2015/01/20
遅めに帰着。
MinGW-gdc調査。当たりは付かず。
2015/01/19
遅めに帰着。
MinGW-gdc調査。デバッガで観察を試みたのですが、丁度良い所で
止めるにはデータが大きすぎてどうやって止めたものやら。
2015/01/18
昼過ぎ起床。
掃除したり。洗濯したり。
MinGW-gdc調査。「movsi_internal」の文字列を手がかりにソースの中を
grepしたところ、gcc/config/i386/i386.md にネタがありそうだったり。
試しに弄ってみたところ正しく動かない実行ファイルができあがるものの、
件のRTL部分に反応する事が分かってみたり。ただ、*.mdファイルはRTLから
命令コードに変換するテーブルのようなものらしいので、そもそも問題となる
RTLをどこで生成しているのかがまだ分からなかったり。
gcc/cfgexpand.c でGIMPLEからRTLを生成していそうな予感。
いよいよコンパイラ本体をデバッガで追いかけてみるしかないか......？
まぁ、C言語と違ってプリプロセッサが無いので少しやりやすいとは
思いますが。
2015/01/17
AM中に起床。休出。
美の巨人たちで知った「森田藻己(もりたそうこ)」という根付師とその作品
(参考)。
これ、一木造りだというから、すげぇと言わざるを得ません。
MinGW-gdc調査。MinGW(i686)ターゲットのgdcと同じバージョンの Linux(x86)
ターゲットのgdcをビルドしてみたり。-m32のRTLとMinGW-gdc(i686)の
この前のとを比べると、MinGWの方はやっぱり余計な事
をしているように思ったり。以下はLinux-gdc(-m32)のRTL。
001: ;; Function toHash (_D3std8internal3uni12CodepointSet6toHashMxFNaNbNfZk, funcdef_no=18, decl_uid=2626, symbol_order=23)
002:
003: (note# 0 0 NOTE_INSN_DELETED)
004: (note# 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
005: (note# 0 0 NOTE_INSN_FUNCTION_BEG)
006: (insn/f:TI# 0 0 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [ S4 A8])
007: (reg:SI 4 si)) ../../../../../gcc-4.9.2/libphobos/src/std/internal/uni.d:408# {*pushsi2}
008: (expr_list:REG_DEAD (reg:SI 4 si)
009: (nil)))
010: (insn/f# 0 0 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [ S4 A8])
011: (reg:SI 3 bx)) ../../../../../gcc-4.9.2/libphobos/src/std/internal/uni.d:408# {*pushsi2}
012: (expr_list:REG_DEAD (reg:SI 3 bx)
013: (nil)))
014: (insn/f:TI# 0 0 2 (parallel [
015: (set (reg/f:SI 7 sp)
016: (plus:SI (reg/f:SI 7 sp)
017: (const_int -12 [0xfffffffffffffff4])))
018: (clobber (reg:CC 17 flags))
019: (clobber (mem:BLK (scratch) [ A8]))
020: ]) ../../../../../gcc-4.9.2/libphobos/src/std/internal/uni.d:408# {pro_epilogue_adjust_stack_si_add}
021: (expr_list:REG_UNUSED (reg:CC 17 flags)
022: (expr_list:REG_ARGS_SIZE (const_int 8 [0x8])
023: (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 7 sp)
024: (plus:SI (reg/f:SI 7 sp)
025: (const_int -4 [0xfffffffffffffffc])))
026: (nil)))))
MinGW-gdc(i686)で出力されているecxレジスタをthisとしている
コードがどうして生成されているのか分かれば直せるか？
オブジェクト指向言語特有の話かも知れませんが、多機能なクラスは
メソッドが沢山あるため、どうしてもコード行数が多くなりがちに思います。
そんな訳で今更ですがEmacsでコードブロックを折りたたむ事ができないか
調べてみたところ、hs-minor-modeの存在を知ったり。デフォルトの
バインドは若干使いにくい所に割り当たってますが、それは適当に
好みのバインドに割り当てる方向で。
2015/01/16
遅めに帰着。
MinGW-gdc調査。掴めず。
2015/01/15
遅めに帰着。
MinGW-gdc調査。特に得られるものは無し。
2015/01/14
遅めに帰着。
MinGW-gdc調査。RTLのダンプを眺めたり。問題となる構造体のメンバー関数の
入り口部分を見ていたところ、どうやら問題が起こるようなRTLが生成されて
いる予感がしたり。
001: ;; Function toHash (_D3std8internal3uni12CodepointSet6toHashMxFNaNbNfZk, funcdef_no=18, decl_uid=2597, symbol_order=23)
002:
003: (note# 0 0 NOTE_INSN_DELETED)
004: (note# 0 0 [bb 2] NOTE_INSN_BASIC_BLOCK)
005: (note# 0 0 NOTE_INSN_FUNCTION_BEG)
006: (insn/f:TI# 0 0 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [ S4 A8])
007: (reg:SI 4 si)) ../../../../gcc-4.9.2/libphobos/src/std/internal/uni.d:408# {*pushsi2}
008: (expr_list:REG_DEAD (reg:SI 4 si)
009: (nil)))
010: (insn/f# 0 0 2 (set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [ S4 A8])
011: (reg:SI 3 bx)) ../../../../gcc-4.9.2/libphobos/src/std/internal/uni.d:408# {*pushsi2}
012: (expr_list:REG_DEAD (reg:SI 3 bx)
013: (nil)))
014: (insn# 0 0 2 (set (reg/f:SI 4 si [orig:98 this ] [98])
015: (reg:SI 2 cx [ this ])) ../../../../gcc-4.9.2/libphobos/src/std/internal/uni.d:408# {*movsi_internal}
016: (nil))
017: (insn/f:TI# 0 0 2 (parallel [
018: (set (reg/f:SI 7 sp)
019: (plus:SI (reg/f:SI 7 sp)
020: (const_int -20 [0xffffffffffffffec])))
021: (clobber (reg:CC 17 flags))
022: (clobber (mem:BLK (scratch) [ A8]))
023: ]) ../../../../gcc-4.9.2/libphobos/src/std/internal/uni.d:408# {pro_epilogue_adjust_stack_si_add}
024: (expr_list:REG_UNUSED (reg:CC 17 flags)
025: (expr_list:REG_CFA_ADJUST_CFA (set (reg/f:SI 7 sp)
026: (plus:SI (reg/f:SI 7 sp)
027: (const_int -20 [0xffffffffffffffec])))
028: (nil))))
怪しいと思われるのは14,15行目で、ecxレジスタの値が構造体の
実体(this)を表しているかのように解釈していますが、正しく
ありません。DMD2.062ベースのgdcでは14,15行目のRTLは
出てきません。でも、何故こうなるのかはよく分からず。
そして、ここん所はGIMPLEには表現されていないようです。
そういえば、Cygwinのgdbを使用してMinGW実行バイナリをデバッグ
してみたら、MinGWのgdbでは全然見る事のできなかった値を
表示できたり。MinGWのgdbは7.2でかろうじてD言語サポートが
入ったバージョンに対して、Cygwinのgdbは7.8だったので良い感じに
なっているのかも。今までうまく見られなかった状態を見れば
何か判るか？
2015/01/13
遅めに帰着。
MinGW-gdc調査。RTLのダンプを見比べたり。どれも微妙に違っててなんだこれ？
って感じ。
2015/01/12
AM中に起床。
MinGW-gdc調査。SegfaultするコードのGIMPLEを比較してみるのですが、
GIMPLE的に Segfaultするi686ターゲットと 普通に動くx86_64ターゲットの差が無いので、
バックエンド生成時の問題なのかしら？と思ったり。
RTLを取り合えず判らないなりに見てみた所、どうもメンバー関数呼び出し時の
受け側がマズっている予感。
2015/01/11
AM中に起床。
掃除したり。
最近のEmacsでは、linum-modeという行番号を表示するモードがありますが、
行数の多いファイルを開くと我慢できないほど表示が遅くなります。
高々画面に表示されている分の行数を専用のバッファに表示するだけ
なのに、何故こんなに遅いんだろう？と不思議に思ったり。
elispを少し眺めてみたのですが、毎回バッファの先頭行からカウントしている
ような気がしたりも。ウインドウに表示されている最初の行番号と画面の行数だけ
がすぐに得られれば、こんなに遅くならないようにも思ったり。
MinGW-gdc調査。なんとなく構造体を 連想配列のKeyに使う場合用に、
toHash()というメンバー関数をカスタマイズして良い事になっている
(参考)のですが、
このtoHash()を定義して、かつそれを呼び出した時にバグを踏む
感じっぽいというのが判ってきました。でも、うまく再現コードにできず。
2015/01/10
起きたら午後もいい時間。寝すぎ。
MinGW-gdc調査。ここを通れば再現するハズというルートがあるのですが、
どうにも通らず。
そういやD言語で書いた手持ちのWindowsアプリをオリジナルのDMDで
コンパイルする事はありませんでした。外付けのC言語で書かれた
ライブラリ群をリンクできないからというのが理由でした。
で、以前作成した
HelloWorldを表示するだけのウインドウアプリは外付けのライブラリを
使用していないのでリンクできるのでは？と思い、dmdでのビルドを
試してみたり。結論から言うとリンク＆実行できました。でも、
ファイルの拡張子ルールがMinGWなどのいわゆるUNIX系のそれと違って
いるので、Makefileは結構直す必要がありました。
そもそも、オブジェクトファイルのフォーマットが違ってると時点で、
リンクするのが急に面倒臭くなるのはイマイチだなぁと思ったりも。
.dllも.aと同様に直接ファイルを指定すればリンクできるbinutilsに比べると、
.dllから.libを一旦生成しておかないとリンクできないとか面倒臭すぎると
思います。
2015/01/09
早めに帰着。
i686ターゲットのMinGW-gdcでずっこけ実行ファイルが生成される件の
調査。DMD2.065ベースのgdcで連想配列のキーに tupleを使うと
何故かコンパイルエラーするので再現しなくなっているのを
tupleからrangeに変えればいけるか？と思ったのですが、
どうにもrangeは配列との区別が付かなくて、rangeになっているのか
否かが判別できません。コードの例もautoで変数代入しているのしか
無い為、構造体やクラスのメンバー変数にしたい場合、どういう型で
宣言すれば良いのか？とか、よく分からないです。
import std.stdio;
import std.range;
void main()
{
int[] ival ;
auto at = chain( [1,2,3], [4,5,6] ) ; // エラーしない
ival = chain( [1,2,3], [4,5,6] ) ; //[9] Error: cannot implicitly convert expression (chain([1, 2, 3], [4, 5, 6])) of type Result to int[]
}
サンプルコードでautoを使うのは禁止にして欲しいと思わなくもなかったり。
2015/01/08
遅めに帰着。
magitのパッケージアップデートを
してみたり。githubのmasterブランチに比べると大分古い気がしなくもありませんが、
2014/12/28付けのパッケージなので、まぁこれが最新なのでしょう。
そんな訳で cached fileを表示するパッチを更新したり
(magit.el.20141228.1413.patch)。
御参考まで。
2015/01/07
遅めに帰着。
ちょろり調べ事をして終了。
2015/01/06
遅めに帰着。
調べ事をして終了。
2015/01/05
若干早めに帰着。
ちょろっとWeb巡回して終了。
2015/01/04
AM中に起床。
掃除したり、ぐーたら過ごしたり。今日で休みも終わりか.....
湿度計で30% くらいになる時があり、その時は部屋干ししっ放しの
衣類を霧吹きで少し湿らして湿度コントロールしてみています。
洗濯したばかりのものを部屋干しすると、湿度30% からでも、
30分もすれば50% まで上がりますが、霧吹きで湿らせてもせいぜい 40%
くらいにしかなりません。そもそも、湿度50% って水分量にすると
どれくらいなの？っていうのを調べたり。
計算Webサイトなどから計算してみると、24℃で50% にするには、
約11[g/m^3] という事らしい。部屋の容積は約25[m^3]って感じなので、
275g==275mlあれば、50% になるハズ。でも、霧吹きで300mlくらい
の水を使っても、せいぜい40% くらいにしかなりません。
完全に乾く必要があるので、倍くらいの水を含ませないとダメなのかも
と思ったり。でもそれって、結局 乾いた衣類を全て洗濯直後まで
湿らせなくてはならないので、流石にそれはムリだという事で40%
くらいで諦める方向で(^^;
SAI2遊び。パース定規をもそもそ使ってみたり。グリッドを作る手間が
省ければなぁとは思いましたが、ペンレイヤーでの交点まで削除が
良い感じだし、間違えても簡単に直せるし楽チンでした。
因みに下の絵では、グリッドを作るのはペンレイヤーを使用していますが、
建物本体は通常レイヤーを使用しました。窓枠の幅とかはグリッドが無いと
消失点方向に間隔を揃えられませんので必須です。
元サイズは約2850x2830くらいを縮小しているので
大分潰れていますが、その方がアラを誤魔化せるので良いですね(^^;
2015/01/03
昼頃起床。
SAI2の新しいので遊んだり。
気づいた点は画像にコメント文として記載してみました。御参考まで。
そういや自動選択が まだ実装されていないようなので、
塗分けするのがちょっと辛かった(^^;
そういや我が家のペンタブレット(Intuos3)には、ファンクションキーと
称したショートカットキーがタブレット面に付いているのですが、
全く使っていませんでした。それどころか、キーボードの足がそのキーを
押してしまっていて、Cntlキー押しっぱなし現象とか謎の挙動を起こしたり
してました。で、キーの横にトラックパットという静電パット領域がある
のに気づき、何気にマウスのホイール代わりになるというを今日知りました(^^;;;;;;
あれ？この辺カスタマイズすれば線画描くだけならキーボード無くてもいけそう
な気がしてきました。つーか、完全に猫に小判です(-_-;;;;
2015/01/02
昼頃起床。
CygwinでMinGW-gdcのクロスビルド。x86_64-w64-mingw32の方は、
MinGWからlibmingw32.a, libmingwthrd.a, libmingwex.a の三つのファイルを、
インストールprefix下のライブラリパス($prefix/x86_64-w64-mingw32/lib)に置けば、
Cygwinパッケージの /usr/x86_64-w64-mingw32/sys-root/mingw/lib/ 下の
それらを使わずにうまくリンクできました。
$ x86_64-w64-mingw32-gdc.exe -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gdc
COLLECT_LTO_WRAPPER=/usr/local/gdc031_2065_492_mingwcross/libexec/gcc/x86_64-w64-mingw32/4.9.2/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-4.9.2/configure --build=i686-pc-cygwin --host=i686-pc-cygwin --target=x86_64-w64-mingw32 --enable-languages=d,lto --prefix=/usr/local/gdc031_2065_492_mingwcross --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap --disable-shared --disable-multilib
Thread model: win32
gcc version 4.9.2 (GCC)
$ cat iam.d
import std.stdio;
import std.string ;
int main()
{
version( GNU ) writef("I am GNU\n" ) ;
version( Unix ) writef("I am Unix\n" ) ;
version( linux ) writef("I am linux\n" ) ;
version( Windows ) writef("I am Windows\n") ;
version( MinGW ) writef("I am MinGW\n" ) ;
version( MinGW32 ) writef("I am MinGW32\n") ;
version( MinGW64 ) writef("I am MinGW64\n") ;
version( cygwin ) writef("I am cygwin\n" ) ;
version( Win32 ) writef("I am Win32\n" ) ;
version( Win64 ) writef("I am Win64\n" ) ;
version( Posix ) writef("I am Posix\n" ) ;
version( X86 ) writef("I am X86\n" ) ;
version( X86_64 ) writef("I am X86_64\n" ) ;
version( ARM_SoftFloat ) writef("I am ARM_SoftFloat\n" ) ;
version( ARM ) writef("I am ARM\n" ) ;
version( PPC ) writef("I am PPC\n" ) ;
version( PPC64 ) writef("I am PPC64\n" ) ;
version( PPC_SoftFloat ) writef("I am PPC_SoftFloat\n" ) ;
version( PPC_HardFloat ) writef("I am PPC_HardFloat\n" ) ;
return(0) ;
}
$ x86_64-w64-mingw32-gdc.exe iam.d
$ ./a.exe
I am GNU
I am Windows
I am MinGW
I am Win64
I am X86_64
以前作成した、ごく簡単なWinアプリコード
のビルド＆実行はできたので、どれだけいけるかは不明ですが全然ダメって事は無いようです。
i686-pc-mingw32の方は全然ダメでどうにかリンクできても、いきなりSegfaultする
実行ファイルしか生成されませんでした。そういやgdcの為にbinutilsにTLSパッチを
あてていたりしているので、そこのビルドから行えばいけるかも知れませんが、
ちょっと弄るくらいじゃダメそうです。逆にゼロからでも、一意の手順で
ビルドできればそれでも良いのですが、どうなんだろう？
i686-pc-mingw32-gdc向けに一応binutilsのビルドも試してみました。TLSパッチがあたるbinutils-2.23を
使って、
../binutils-2.23.1/configure --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-mingw32 --with-arch=i686 --prefix=/usr/local/gdc031_2065_492_mingwcross --disable-nls --disable-win32-registry --with-sysroot=/usr/i686-pc-mingw32/sys-root
てなconfigureオプションでビルド。エラー無くビルドできたので、
make install。
x86_64-w64-mingw32と同じように、MinGWの方から
libmingw32.a, libmingwthrd.a, libmingwex.a に加えて crt2.o の
4つを $prefix/i686-pc-mingw32/lib の下にコピー。
この状態で、既にinstall済みのi686-pc-mingw32-gdcを使ってみたの
ですが、リンク時のワーニングが消えなかったのでgdcも再ビルドしました。
そうした所、一応使えるi686-pc-mingw32-gdcがビルドできました。
$ i686-pc-mingw32-gdc.exe -v
Using built-in specs.
COLLECT_GCC=i686-pc-mingw32-gdc
COLLECT_LTO_WRAPPER=/usr/local/gdc031_2065_492_mingwcross/libexec/gcc/i686-pc-mingw32/4.9.2/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-4.9.2/configure --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-mingw32 --enable-languages=d,lto --prefix=/usr/local/gdc031_2065_492_mingwcross --with-sysroot=/usr/i686-pc-mingw32/sys-root --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap
Thread model: win32
gcc version 4.9.2 (GCC)
$ i686-pc-mingw32-gdc.exe iam.d
$ ./a.exe
I am GNU
I am Windows
I am MinGW
I am Win32
I am X86
でも、特定コードでSegfaultする問題(参考)は
そのままです。ただ、クロスコンパイラでも再現するので、gdc本体の問題の
可能性は大分高いのじゃないかなと思ったりも。
いい加減深夜に、SAI2の新しいのが出ているのに気づいたり！
明日試してみます。
2015/01/01
あけましておめでとうございます。今年もよろしくお願いしますm(_'_)m
CygwinパッケージにはMinGWのクロスビルド環境があるのですが、
それを使ってMinGWターゲットのクロスgdcをビルドできないかと
思ったり。gcc-4.9.2とgcc-4.9.xベースのブランチの
c58d2e01d81d5c8c1920d5882910dd47dc587ec6を使用して
試してみたり。
結果から言うと、ビルドはできたもののビルドしたコンパイラで
どうしてもリンクできないシンボルが解決できず使えるものに
なりませんでした。うまくいきません。
以下、覚え書き。
./setup-gcc.sh gcc-4.9.2
pushd gcc-4.9.2
patch -p1 < ../0001-Remove-fPIC-for-MinGW.patch
patch -p1 < ../mingw-tls-gcc-4.8.patch
popd
以上はREADME-MINGW.mdの内容と、いつも通りのオペレーション。
$ diff -c gcc-4.9.2/gcc/d/dfrontend/object.h.orig gcc-4.9.2/gcc/d/dfrontend/object.h
*** gcc-4.9.2/gcc/d/dfrontend/object.h.orig 2014-11-11 22:13:35.000000000 +0900
--- gcc-4.9.2/gcc/d/dfrontend/object.h 2015-01-01 09:25:50.569066700 +0900
***************
*** 10,16 ****
#ifndef OBJECT_H
#define OBJECT_H
! #define POSIX (__linux__ || __APPLE__ || __FreeBSD__ || __OpenBSD__ || __sun)
#if __DMC__
#pragma once
--- 10,16 ----
#ifndef OBJECT_H
#define OBJECT_H
! #define POSIX (__linux__ || __APPLE__ || __FreeBSD__ || __OpenBSD__ || __sun || __CYGWIN__)
#if __DMC__
#pragma once
てなパッチを当てました。これが無いとWIN32でもPOSIXでも無い環境という解釈に
なってしまい途中でコンパイルエラーになります。
あとlibdruntimeに
$ diff -c libdruntime/core/stdc/stdlib.d.orig libdruntime/core/stdc/stdlib.d
*** libdruntime/core/stdc/stdlib.d.orig 2014-11-11 22:13:35.000000000 +0900
--- libdruntime/core/stdc/stdlib.d 2015-01-01 16:07:43.456546200 +0900
***************
*** 67,77 ****
return strtod(nptr, endptr);
}
}
! else version (MinGW)
! {
! real __mingw_strtold(in char* nptr, char** endptr);
! alias __mingw_strtold strtold;
! }
else
{
real strtold(in char* nptr, char** endptr);
--- 67,77 ----
return strtod(nptr, endptr);
}
}
! //else version (MinGW)
! //{
! // real __mingw_strtold(in char* nptr, char** endptr);
! // alias __mingw_strtold strtold;
! //}
else
{
real strtold(in char* nptr, char** endptr);
$ diff -c ./libdruntime/gcc/gthreads/win32.d.orig ./libdruntime/gcc/gthreads/win32.d
*** ./libdruntime/gcc/gthreads/win32.d.orig 2014-11-11 22:13:35.000000000 +0900
--- ./libdruntime/gcc/gthreads/win32.d 2015-01-01 16:08:59.219879600 +0900
***************
*** 47,52 ****
--- 47,53 ----
import core.stdc.errno;
alias gthread_key_t = ULONG;
+ extern (Windows) nothrow int InterlockedIncrement(int*);
struct gthread_once_t
{
の二つを当てたり。これはMinGWでネイティブコンパイルしてもリンク時に
シンボルが見つからなくてリンク失敗するのですが、クロスコンパイラに
おいても同じ問題になったためです。
../gcc-4.9.2/configure --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-mingw32 --enable-languages=d,lto --prefix=/usr/local/gdc031_2065_492_mingwcross --with-sysroot=/usr/i686-pc-mingw32/sys-root --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap
てなconfigureオプションで実行。make; make installで
/usr/local/gdc031_2065_492_mingwcross/binにPATHを通せば
i686-pc-mingw32-gdc.exeが使用可能になります。でも、実際に
使うと次のようなリンクエラーになりました。
$ i686-pc-mingw32-gdc.exe hello.d
警告: __D2rt8lifetime18__blkcache_storagePS2rt8lifetime7BlkInfo@secrel32 を __D2rt8lifetime18__blkcache_storagePS2rt8lifetime7BlkInfo にリンクすることによって解決しています
これらの警告を無効にするためには --enable-stdcall-fixup を使用してください
これらの修正を無効にするためには --disable-stdcall-fixup を使用してください
警告: __D2rt8lifetime12__nextBlkIdxi@secrel32 を __D2rt8lifetime12__nextBlkIdxi にリンクすることに よって解決しています
警告: __D2rt5qsort8tiglobalC8TypeInfo@secrel32 を __D2rt5qsort8tiglobalC8TypeInfo にリンクすること によって解決しています
警告: __tls_end@secrel32 を __tls_end にリンクすることによって解決しています
警告: __tls_start@secrel32 を __tls_start にリンクすることによって解決しています
警告: __D4core6thread6Thread7sm_thisC4core6thread6Thread@secrel32 を __D4core6thread6Thread7sm_thisC4core6thread6Thread にリンクすることによって解決しています
警告: __D4core6thread5Fiber7sm_thisC4core6thread5Fiber@secrel32 を __D4core6thread5Fiber7sm_thisC4core6thread5Fiber にリンクすることによって解決しています
/usr/local/gdc031_2065_492_mingwcross/lib/gcc/i686-pc-mingw32/4.9.2/../../../../i686-pc-mingw32/lib/libgphobos2.a(math.o): 関数 `D3std4math4logbFNbNeeZe' 内:
/home/TANE/develop/dlang/gcc/gdc031_2065_49x/GDC-c58d2e01d81d5c8c1920d5882910dd47dc587ec6/build_mingwcross/i686-pc-mingw32/libphobos/src/../../../../gcc-4.9.2/libphobos/src/std/math.d:2756: `logbl' に対する定義されていない参照です
/usr/local/gdc031_2065_492_mingwcross/lib/gcc/i686-pc-mingw32/4.9.2/../../../../i686-pc-mingw32/lib/libgphobos2.a(math.o): 関数 `D3std4math5roundFNbNeeZe' 内:
/home/TANE/develop/dlang/gcc/gdc031_2065_49x/GDC-c58d2e01d81d5c8c1920d5882910dd47dc587ec6/build_mingwcross/i686-pc-mingw32/libphobos/src/../../../../gcc-4.9.2/libphobos/src/std/math.d:3370: `roundl' に対する定義されていない参照です
/usr/local/gdc031_2065_492_mingwcross/lib/gcc/i686-pc-mingw32/4.9.2/../../../../i686-pc-mingw32/lib/libgphobos2.a(math.o): 関数 `D3std4math5truncFNbNeeZe' 内:
/home/TANE/develop/dlang/gcc/gdc031_2065_49x/GDC-c58d2e01d81d5c8c1920d5882910dd47dc587ec6/build_mingwcross/i686-pc-mingw32/libphobos/src/../../../../gcc-4.9.2/libphobos/src/std/math.d:3424: `truncl' に対する定義されていない参照です
collect2: error: ld returned 1 exit status
確かに、数学関数のlogbl, roundl, truncl は
/usr/i686-pc-mingw32/sys-root/mingw/lib/libmingwex.aに入っていて
欲しいのですが、何故か入っていません。
コンパイルだけを「i686-pc-mingw32-gdc.exe -c hello.d」で行って、
リンクをMinGWネイティブgdcで行えばとりあえずは動くようです。
ただ、それだとlibphobosでSegfaultする件はそのままなので、
やっぱダメですが。
x86_64-w64-mingw32-gdcのCygwinクロスビルドも試してみたり。
ソースはi686-pc-mingw32と同じで、
../gcc-4.9.2/configure --build=i686-pc-cygwin --host=i686-pc-cygwin --target=x86_64-w64-mingw32 --enable-languages=d,lto --prefix=/usr/local/gdc031_2065_492_mingwcross --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap --disable-shared --disable-multilib
てなconfigureオプションでlibphobosまでビルドできましたが、
実際に使ってみると、
$ x86_64-w64-mingw32-gdc.exe hello.d
/usr/local/gdc031_2065_492_mingwcross/lib/gcc/x86_64-w64-mingw32/4.9.2/../../../../x86_64-w64-mingw32/lib/../lib/libgphobos2.a(win32.o): 関数 `gthread_once' 内:
/home/TANE/develop/dlang/gcc/gdc031_2065_49x/GDC-c58d2e01d81d5c8c1920d5882910dd47dc587ec6/build_x86_64_mingwcross/x86_64-w64-mingw32/libphobos/libdruntime/../../../../gcc-4.9.2/libphobos/libdruntime/gcc/gthreads/win32.d:98: `InterlockedIncrement' に対する 定義されていない参照です
collect2: error: ld returned 1 exit status
InterlockedIncrement()は、kernel32に含まれているような情報を得たのですが、
実際にはlibmingwex.aに含まれているようです。でも、Cygwinパッケージ内のクロスライブラリ
libmingwex.aには何故か入っていなくて、リンクに失敗するという流れ。
MinGW64のlibmingwex.aを持って来れば良いのですが、ただ差し替えるだけだとダメで
リンク時に二度指定されている-lmingwex の二つ目をMinGW64のに差し替えれば
リンクできるという、とんでもなく面倒臭い方法を使えば動くというレベル。
CygwinのMinGWクロス環境パッケージがイマイチなのかしら？