2016/01/31
AM中に起床。
掃除したり洗濯したり。
Emacs美人時計のロックの件。デバッグ表示をONにしたまましばらく放置
していると、自動ロック開放がまぁまぁな頻度で実行されている事が
判ったり。emacs-deferredのタイムアウト処理も追加してみたのですが、
それでも自動ロック開放のコードが動いているもよう。
因みに、deferredのタイムアウトは10秒とし、deferredタイムアウト時はロックを開放。
自動ロック開放は約30秒(run-with-timerで1秒毎に実行するのを30回分)で発動する
ようにしました。
なので、deferredのタイムアウトが必ず10秒で発生するのであれば、
自動ロック開放の方は発動しないハズなのですが、発動している所を見ると
HTTPアクセスのどこかで突っかかっているという事なのだろうと推測します。
しばらくテストしてみる感じで。
x86_64ターゲットのMinGW-gdc2.067。以前、
real型の値をwritef()するとSegfaultするという問題があったのですが、
2.067で直っているみたい。
emacs-25.0.90ってのがプリビュー版アーカイブとしてリリースされていた
のでCygwinでビルドしてみたり。「./configure --prefix=/usr --without-imagemagick」で
ビルドしたのでemacs-w32ではありませんが、ひとまずエラー無くビルドできて
少し.emacsを直す必要がありましたが起動できました。xwidgetを使えるように
なるらしいのですが、具体的にどうやって使うのかよく判らなかったり。
それを除くと見た目の新しさは無いように思ったりも。
どうやらconfigureオプションに --with-xwidgets を追加しなくてはならない
模様。そして、こちら
のページの「The interface」の項に簡単な例と思われるコードがあるので
スクラッチバッファで実行してみたところ、Segfaultで落ちたり。
Program received signal SIGSEGV, Segmentation fault.
produce_xwidget_glyph (it=0x5a798f8) at xdisp.c:26109
26109 it->ascent = it->phys_ascent = glyph_ascent = xw->height/2;
(gdb) where
#0 produce_xwidget_glyph (it=0x5a798f8) at xdisp.c:26109
#1 x_produce_glyphs (it=0x5a798f8) at xdisp.c:27609
#2 0x00431e3d in display_line (it=it@entry=0x5a798f8) at xdisp.c:20559
#3 0x004346f7 in try_window (window=window@entry=-2115111451, pos=..., flags=flags@entry=1) at xdisp.c:17134
#4 0x004476c5 in redisplay_window (window=window@entry=-2115111451, just_this_one_p=just_this_one_p@entry=false)
at xdisp.c:16599
#5 0x0044a00e in redisplay_window_0 (window=-2115111451) at xdisp.c:14391
#6 0x00537d5c in internal_condition_case_1 (bfun=bfun@entry=0x449fe0 <redisplay_window_0>, arg=arg@entry=-2115111451,
handlers=8652531, hfun=hfun@entry=0x4128c0 <redisplay_window_error>) at eval.c:1333
#7 0x00417e2d in redisplay_windows (window=-2115111451) at xdisp.c:14371
#8 0x00437fbc in redisplay_internal () at xdisp.c:13931
#9 0x00439ba5 in redisplay () at xdisp.c:13164
#10 0x004d56ce in read_char (commandflag=commandflag@entry=1, map=map@entry=-2105672621, prev_event=0,
used_mouse_menu=used_mouse_menu@entry=0x5a7c98b, end_time=end_time@entry=0x0) at keyboard.c:2466
#11 0x004d7e04 in read_key_sequence (keybuf=keybuf@entry=0x5a7ca38, prompt=prompt@entry=0,
dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
at keyboard.c:9042
#12 0x004d975e in command_loop_1 () at keyboard.c:1347
#13 0x00537cf5 in internal_condition_case (bfun=bfun@entry=0x4d9590 <command_loop_1>, handlers=handlers@entry=9504,
hfun=hfun@entry=0x4d0a80 <cmd_error>) at eval.c:1309
#14 0x004cc4bf in command_loop_2 (ignore=0) at keyboard.c:1089
#15 0x00537c9b in internal_catch (tag=tag@entry=22704, func=func@entry=0x4cc4a0 <command_loop_2>, arg=arg@entry=0)
at eval.c:1074
#16 0x004cc47a in command_loop () at keyboard.c:1068
#17 0x004d06ea in recursive_edit_1 () at keyboard.c:674
#18 0x004d09ce in Frecursive_edit () at keyboard.c:745
#19 0x005c3880 in main (argc=<optimized out>, argv=0x5a7cc3c) at emacs.c:1600
(gdb)
因みに、サンプルコードを Webページからコピペすると、ダブルクオートや
シングルクオートが全角コードになってしまうためLISPエラーになります。
手で直して実行する必要があるようです。
2016/01/30
昼過ぎ起床。寝過ぎ。
そういやEmacsの美人時計を常用していて、極稀に画像更新が行われなく
なる現象に遭遇していました。稀なものですから、stop→startすると
また動くのは確認していたのですが、遭遇したらデバッグフラグを上げて
状態を見るというのを毎回忘れて、原因不明な状況でした。
で、再現していたので状態を見てみたり。
状況としては、ずっと前に
画像取得が多重起動しないようにロックする機構を設けてみたのですが、
何故かロックしっぱなしの状態に陥っているようでした。
emacs-deferred
の使い方としては、どこを通ってもロックフラグを落としているつもり
なのですが、何故かロックしっぱなしになってます。
取りあえず手でロックに使っている変数を変えてやれば再開したこと
から、ロック判定を行って n回以上ロックされていると判断できれば
ロックを開放するコードを追加してみたり。
ロックを手動で開放した後のEmacsを終了する際に、httpアクセスのプロセスが
動きっぱなしになっていたのをよく見ずに閉じたのですが、
もしかしてhttpアクセスを無限に待っている状態の所に
run-with-timerによって次の起動がかかっていたのでは？
(すなわち二重起動状態になっていたのでは？)と思ったりも。
httpアクセスはタイムアウトする訳ではないのか？
Windows10にしてからVMwareの立ち上げ時に「パワーオン中にエラーが発生しました」
みたいなメッセージが出る事があったのですが、
こちら
のブログエントリのように
「コントロールパネル＞管理ツール＞サービス」から
「VMware Authorization Service」を起動すれば良いようです。
POUETのトップページにある
「upcoming parties」に
ASSEMBLY WINTER 2016
の告知が出ていたり。つい先日まで
Tokyo Demo Fest 2016の方
が直近に開催されるイベントだったのに追い抜いちゃってます(^^;
てか来週じゃん。
そういやTokyo Demo FestのスポンサーにPolyphony Digitalの名前が
挙がっていたり。
そういやいつの頃からかDMDのcore.sys.windowsにWindowsAPIバインディング
のコードが取り込まれていた模様。gitには2015年10月頃に入っていたようですが、
DMD2.070.0から一般開放されたようです。拙作のwin32frameを WindowsAPIバインディング
からcore.sys.windows使用に変えてコンパイルしてみたところ、簡単なGDIアプリ
ならばコンパイルできたり。そういやDMD2.070.0ではclear()関数って
無くなったの？
覚書。Emacsの「*Messages*」バッファはデフォルト1000行ですが、
変数message-log-maxで変えられる。美人時計のデバッグの為にmessage関数を
使っているのですが、1000行だとあっと言う間に埋まってしまったので。
gdc2067のx86_64ターゲットがダメな件。va_arg()のコードを弄ったり。
version(GNU){
version( X86 ){
}else version( X86_64 ){
★1
}else version( ARM ){
}else{
}
}else version( X86 ){
}else version (Windows){
★2
}else version (X86_64){
}else{
}
というバージョン分けコードになっていて、MinGWの時にGNU且つX86_64を通っていた
(★1のコード)のがマズかった感じ。てかこの構造、最後の「!GNU 且つ !Windows 且つ X86_64」って
どういう時に通るんだ？という謎。さておき、X86_64のMinGWの時に必要なコードは
Windowsの所(★2のコード)でした。なのですが、MinGWはバージョンがややこしいです。
$ cat iam.d
import std.stdio;
import std.string ;
import std.compiler;
int main()
{
writef("%s %s %s.%03d (D%s)\n",name,vendor,version_major,version_minor,D_major) ;
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 ./iam.d
$ ./a.exe
GNU D gnu 2.066 (D2)
I am GNU
I am Windows
I am MinGW
I am Win64
I am X86_64
結局以下のようにするハメに。
version(GNU){
version( X86 ){
}else version( X86_64 ){
version(MinGW){
★2 ←───移植───┐
}else{ │
★1 │
} │
}else version( ARM ){ │
}else{ │
} │
}else version( X86 ){ │
}else version (Windows){ │
★2 ───────────┘
}else version (X86_64){
}else{
}
Windowsのコードを GNU且つX86_64且つMinGWの下にも書くという感じで
Segfaultしていたコードも動くようになりました。
コンパイラが予約しているversion()は、OSとCPUアーキテクチャが
ごちゃ混ぜになっているのもあるのですが、
論理演算が書けないので 安易にバージョン分けすると
今回のように同じコードをあちこちに散りばめるハメになりがちです。
2016/01/29
遅めに帰着。
DMD2.070.0がリリースされている模様。
gdc2067のx86_64ターゲットがダメな件。va_arg()が怪しいと踏んで
調べてみたり。どうやらva_listが思っているのと違うのでは？
と思ったり。core/stdc/stdarg.d の中で version(GNU)且つversion(X86_64)
の時のコードが生きているようなのですが、そこでは
va_list型で渡って来るapxという変数を スコープ内で __va_listという
別の構造体にキャストしています。
:
21 version( GNU )
:
67 else version( X86_64 )
68 {
69 /// Layout of this struct must match __builtin_va_list for C ABI compatibility
70 struct __va_list
71 {
72 uint offset_regs = 6 * 8; // no regs
73 uint offset_fpregs = 6 * 8 + 8 * 16; // no fp regs
74 void* stack_args;
75 void* reg_args;
76 }
77
78 ///
79 void va_arg()(ref va_list apx, TypeInfo ti, void* parmn)
80 {
81 __va_list* ap = cast(__va_list*)apx;
:
で、va_listのサイズをsizeofプロパティで調べてみたところ「8」でした。
SegfaultするコードをFedoraでビルドしたgdcでコンパイルしたらどうなるか？
と思い試してみたところ、こちらはずっこける事なく動きました。こちらでも
va_listサイズを調べてみたところ「24」でした。
前述__va_list構造体のサイズは uintが二個とポインタ(8byte)が二個なので、
合計 24バイトという事でva_listサイズと同じです。ところがMinGWの方はva_listの
サイズが8なのに、24バイトの __va_list にキャストしているものですから、
何が入っているか判らない領域を参照してしまいます。
gdbで追っかけてみたところ、メンバー変数stack_argsをポインタ参照してる所で、
たまたま0が入っていたものですからヌルポアクセスでSegfaultしたという流れでした。
そんな訳で、このコードじゃダメなんじゃ？という気がしてきました。
WindowsアップデートのPC再起動ついでにCygwinをアップデート。Cygwin-2.4.xに
なったので、またEmacsの美人時計などで影響が出ないか要監視かも。
2016/01/28
遅めに帰着。
あまりの眠さに急速停止。
2016/01/27
遅めに帰着。
あまりの眠さに急速停止。
2016/01/26
遅めに帰着。
gdc2067のx86_64ターゲットがダメな件。
可変長引数渡しがうまくできていない感じというのが判ってきたのですが、
謎のキャストを行っていて何故そんな事をしているのか理由が判らなかったり。
問題となっているのはstd.format.doFormat()内でva_arg()という関数を
実行していて、ここんところで何か変な感じになってます。で、gdc2066と
比べてみるのですが、gdc2066ではdoFormat()のコードが全く異なって
いて、va_arg()関数自体を使用していなかったり。うーむ。
2016/01/25
遅めに帰着。
D言語で関数の中に関数宣言が書ける件。以下のような記述が許容されています。
1 import std.stdio;
2 import std.string;
3
4 void main()
5 {
6 int add(int x, int y){
7 int subadd(int a, int b){
8 return(a+b) ;
9 }
10 return(subadd(x,y)) ;
11 }
12
13 writef("%d\n",add(1,2)) ;
14 writef("%d\n",ADD(1,2)) ;
15 }
16
17 int ADD(int x, int y)
18 {
19 return(x+y) ;
20 }
アセンブラコードで6行目のadd, 7行目のsubadd, 17行目のADDを見てみると、
add → _D12func_in_func4mainFZ3addMFiiZi
subadd → _D12func_in_func4mainFZ3addMFiiZ6subaddMFiiZi
ADD → _D12func_in_func3ADDFiiZi
てな感じに名前を付けているようです。名前衝突を防げるという
メリットはありそうですが、同一ファイル内であればそもそも
衝突しないし、同名で動作の異なる関数を同一ファイル内のあっちと
こっちで使うというのは、使えるからといって使うか？という
感じの奴だと思います。
例示した程度のコード量ならまだしも、スクロールが必要なコード量
で、しかも関数定義だけして実際に使っていないとかあると、
通過するコードが非常に判りにくくなると思います。
なんかあえてこう書く利点が見当たらないように思うのですが
どうでしょう？
2016/01/24
昼前起床。結局、関東地方で雪は降らなかった模様。
掃除したり洗濯したり。
gdc2067のx86_64ターゲットがダメな件。stdoutが出力が変な件に続き、
Segraultする件を調べたり。どうやらstd.format.doFormat()の中でずっこけ
ているようで、簡単なコードで絞り込めたのですが、そもそも2.066→2.067で
思いっきり書き換えられている為、エンバグしているんじゃないかと
思ったりも。あと、単なる関数かと思いきや関数内に関数宣言があったりして
訳が分からない書き方になっているような気が。
新しいsai2で、グラデーションツールが追加されたのですが、それで
生成したグラデーションが なんだか粒感があるように感じたり。
「RGB=255,0,0 → 0,0,0」へのグラデーションの、中間くらいのところの
スナップショットですが、あるピクセルと隣接するピクセルとの色差が
4くらい離れている場合があり、それが粒感を感じる原因ではないかと推測します。
フルカラーのマッハバンド除去を行うのであれば、
色差1を埋めるのにディザリングする感じで良いように思いますので、
その場合、あるピクセルと隣接するピクセル との色差は最大が1という事
になるかと思います(ただし、256ピクセル以上の幅をグラデーションで埋める
場合の話で、256ピクセルより狭い領域の場合、隣接ピクセルの色差が大きく
なるのは正しい)。
ところで、RGB48bitカラーの場合、内部データ的には細工無しに48bitカラーで
グラデーション生成して、表示等でRGB24bitにする時にディザリングするのかな？
とも思ったのですが、スポイトで吸える所を見ると、内部データとしても色差のある
グラデーションとして生成されていると想像します。
このようなグラデーションも用途によってアリだと思いますが、粒感の無い
グラデーションも生成できると良いかと思います。
2016/01/23
起きたら午後もいい時間。寝過ぎ。
そういやx86_64ターゲットのgdc(2.066/2.067共)でコンパイルオプションを-O0で
最適化無しにするとphobosのsocket.oのリンクに失敗するのに気づいたり。
メインでx86_64ターゲットで使っていなかったのと、デバッグで
-O0を使っていなかったというのもありますが、なんで？という感じ。
でもこの現象って、以前
binutilsもビルドすることで、理由は判らないけどなんとなく解決した
「-lgphobos2 -lws2_32」付けないとダメ問題が再発しているようです。
今回のも「-lgphobos2 -lws2_32」を付ければ一応リンクできました。
うーむ、うまくいかないものです。
gdc2067のx86_64ターゲットがダメな件。streamへのポインタがnullになって
いるのを追いかけてみたのですが、stdio.d内の
構造体 LockingTextWriter のコンストラクタで、値が入っている
ハズのものが既にnullになっていたり。
stdio.d内にFileという構造体があるのですが、そもそも超巨大なのと、
コード内ドキュメントも大量に含まれていて見渡すのが大変です。
もう少し調べてみると、2.066と動きが違っているもよう。phobosとして
使用するstdoutの初期化がうまくできていないのかも？ 幸いにして
core.stdc.stdioのprintf()は
使えるので、かろうじてprintfデバッグできそうですが、出力系が完全に
封じられる状態での出力系のデバッグって、よく考えるとどうやるのが良い
のだろう？と思ったりも。
なんとなくこれじゃね？ってのに辿り着いたり。libdruntime/core/stdc/stdio.d
の中にstdoutの実体が宣言されています。これとは別に_iobという配列があり、
これがCライブラリ上の標準入出力のハンドラの実体になるようです。
で、Win32とかではD言語上のstdin,stdout,stderrというポインタを、
_iob[0〜2] に結び付ける事で、D言語上の core.stdc.stdio.stdout は
Cライブラリ上の標準入出力ハンドラをアクセスするという言い換えれば
alias的な感じになっています。で、本題。OSタイプによって結び付け方が
色々あり、Win32且つMinGWの時は結び付けを行っているのですが、
何故かWin64では明に結び付けを行っていないコードになってました。
この為、nullのままになっているものと推測されます。ここをWin32の
コードを参考に明に結び付けを行ってみた所動くようになりました。
ただ、2.066の時とコードは変わってなくて、2.066では何故これで動いて
いたのか謎です。
$ 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 -O2 iam.d
$ ./a.exe
I am GNU
I am Windows
I am MinGW
I am Win64
I am X86_64
$ x86_64-w64-mingw32-gdc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gdc
COLLECT_LTO_WRAPPER=/usr/local/gdc_2067_600_mingwcross/libexec/gcc/x86_64-w64-mingw32/6.0.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-6-20160103/configure --with-pkgversion='gdc-6 f3d27a14e9' --build=i686-pc-cygwin --host=i686-pc-cygwin --target=x86_64-w64-mingw32 --enable-languages=c,c++,d --prefix=/usr/local/gdc_2067_600_mingwcross --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --enable-threads=win32 --disable-win32-registry --enable-target-optspace --disable-nls --disable-bootstrap --disable-shared --disable-multilib --enable-long-long --enable-sjlj-exceptions
Thread model: win32
gcc version 6.0.0 20160103 (experimental) (gdc-6 f3d27a14e9)
ただ、手持ちのWinアプリコードでSegfaultするものがあり、それは
別途調査が必要。
遅ればせながらSAI2の新しいのが出ているのに気づいたり。お疲れさまです。
編集系機能が一気に充実したように思います。
2016/01/22
遅めに帰着。
肩の痛みは大分治まったり。それにしても、左肩と右肩が交互に
痛くなってるような気が。もし、両方同時に痛くなった事を
考えると恐ろしい。
そういえば、Cygwin Snapshots
のページで、アップデート毎にChangeLogリンクから差分説明を
見る事ができていたのですが、少し前から内容が表示されてないような気が。
Diffsのリンクで差分がある事は確認できるので、何か変えた部分があるのは
確かなのですが。何故差分説明だけ何も出てこなくなったのだろう？
Pouetに上がっていた「Synchrony 2016」っていうメガデモイベントの256bの1位作品
「Futura」。
これ、256byteとは到底思えないのですが！？どうなってんの！？
2016/01/21
遅めに帰着。
あまりの眠さに急速停止。
2016/01/20
飲み会。遅めに帰着。
急速に眠くなったのですが、右肩が激しく痛み初めて眠れず。
2016/01/19
遅めに帰着。
gdc2067のx86_64ターゲットがダメな件。標準出力に表示するのに、
最終的にCライブラリのfwrite()に到達するのですが、
どうやらfwrite()に指定しているstreamへのポインタがnullポインタ
になっていて、それを食ったせいでC runtimeがワーニングメッセージを
出しているという流れのようです。gdc2066と動きを比べられそうなので、
いつstreamがnullポインタになっているのか、いつ有効な値が代入
されるのかを比べれば原因に辿り着けるかも。
全然関係無いのですが、x86_64のgdcで何故かリンクに時間がかかる
感じになってたり。リンカが動いている間、特にCPU負荷もディスク負荷
も高くない為、一瞬ハングしているように見えるのですが、しばらく
待てばプロンプトが戻ってくるので動いてはいるのですが。
Windows10にする前は気にならなかったような気がしたりも。
2016/01/18
朝から大雪。遅めに帰着。
ちょろりダラバー。まだ要領が掴めません。
2016/01/17
AM中に起床。
掃除したり。
gdc-2.067のx86_64ターゲットがダメな件。GC内のmutex処理で
なんかなってそうなそうでもないような。如何せんステップ実行
していると途中でハングしてしまうものですからどうにも追いかけ
られず。因みに、writef()を使わずに、
core.stdc.stdio.printf() を使えば文字列出力はできるようなので、
全くダメという訳では無さそうですが.....
試しにいくつかWinアプリコードのコンパイルを試してみたり。
そしたら上手く動くものの方が多い為、単純にメモリ割り当てに失敗している
とかいう訳ではないような。
「オーディンスフィア レイヴスラシル」と同時に「ダライアスバースト クロニクルセイバーズ」
が来ていたので、思わずダライアスの方を先にポチってしまったり。
ダライアスバースト シリーズは今までPSPにしか来ていなかったのと、
アーケードでもやった事無いので 初プレイです。
オリジナルのCSモードを少しだけやったのですが、バーストをイマイチ
使いこなせていません(^^;
そういやアーケードのダライアス筐体稼働から今年で30周年か。
アーケードアーカイブズでも来るのは それも関係あるのか。
gdc-2.067のX86_64ターゲットがダメな件の続き。
2.066と動きを比べてみたのですが、全然違っててあまり参考にならなかったり。
オプティマイズレベルを下げるとどうなるか？と思い、-O0でlibphobosを
コンパイルしてみたのですが、ICEずっこけしてコンパイルできなかったり。
2016/01/16
AM中に起床。
gdc-2.067のMinGWビルド。と言っても、まずはCygwinのクロスMinGW-gdcのビルドですが。
で、あちこち直す所がありましたが、ひとまずビルドに成功。
極簡単なコードと、手持ちのWinアプリをコンパイル＆実行してみたところ、
奇跡的に動いたり。
$ 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) ;
}
$ i686-pc-mingw32-gdc -O2 iam.d
$ ./a.exe
I am GNU
I am Windows
I am MinGW
I am Win32
I am X86
$ i686-pc-mingw32-gdc -v
Using built-in specs.
COLLECT_GCC=i686-pc-mingw32-gdc
COLLECT_LTO_WRAPPER=/usr/local/gdc_2067_600_mingwcross/libexec/gcc/i686-pc-mingw32/6.0.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-6-20160103/configure --with-pkgversion='gdc-6 f3d27a14e9' --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-mingw32 --enable-languages=c,c++,d --prefix=/usr/local/gdc_2067_600_mingwcross --with-sysroot=/usr/i686-pc-mingw32/sys-root --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap
Thread model: win32
gcc version 6.0.0 20160103 (experimental) (gdc-6 f3d27a14e9)
手持ちコードも2.067対応で直す必要があったのですが、2.066まで
core.exception.onSwitchError() ;
とだけ書けば良かったのが、
import core.exception;
:
core.exception.onSwitchError() ;
という感じで、importが必要になったようです。こうなった理由は良く分かりません。
gdc2.067でいくつか手持ちWinアプリコードのコンパイル＆実行を試してみたり。
2.066とは作りが変わっててlibphobosへのパッチが当たらなくなっていた
のですが、不具合のあった箇所は ほぼ直っていないようです。
一応、手持ち分については全部対応してそれとなく大丈夫そう。いつmasterブランチにマージされるかは
判りませんが(今からだとgcc-6のリリースに合わせるくらいか？)、
今と変わらないくらいのコンパイラ品質ならば、乗り換えは比較的スムーズに行えるかも？
とは言え、DMDは2.070がベータテストされている所なので、じわじわと
離れてきている事には変わりありませんが。
x86_64-w64-mingw32ターゲットでクロスコンパイラをビルドしてみたり。
エラー無くビルドできたのですが、make installして HelloWorldレベルの
極簡単なコードをコンパイル＆実行してみるも文字列が表示されず。
デバッガで追いかけてみるも、
warning: Invalid parameter passed to C runtime function.
なる文言が大量に表示されてSegfaultする訳でもなく終了する感じ。
如何せん メモリ割り当てコードを通った後でずっこけているようなの
ですが、メモリ割り当てコードがあまりにも長すぎて追いかけるのに
我慢ならず。どうしたもんか。
それにしても、よもやX86_64の方がダメとは予想外だったかも。
2016/01/15
遅めに帰着。
先日のgdc-2.067のビルドはエラー無く終了してたり。しかし、make installすると
libdruntime/object.diが無くてinstallに失敗。libdruntime/object.dをlibdruntime/object.di
にコピーして無理矢理成功。で、簡単なコードについては問題無く動作
する模様。
$ 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( Windows ) writef("I am Windows\n") ;
version( MinGW ) writef("I am MinGW\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" ) ;
return(0) ;
}
$ gdc -O2 iam.d
$ ./a.out
I am GNU
I am Posix
I am X86_64
$ gdc -v
Using built-in specs.
COLLECT_GCC=gdc
COLLECT_LTO_WRAPPER=/usr/local/gdc_2067_600/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-6-20160103/configure --with-pkgversion='gdc-6 f3d27a14e9' --enable-languages=c,c++,d --prefix=/usr/local/gdc_2067_600 --disable-bootstrap --disable-nls --with-bugurl=http://bugzilla.gdcproject.org --enable-checking=yes --disable-libgomp --disable-libmudflap
Thread model: posix
gcc version 6.0.0 20160103 (experimental) (gdc-6 f3d27a14e9)
MinGWでビルド試してみるか......？
そういや Emacsのgoogle-translateでJSON readtable errorが出るようになっている件。
1/11付けでmasterに取り込まれたようです。
2016/01/14
遅めに帰着。
そういやGDCの
ibuclawさんのブランチに少し前から2.067が来ていて、testsuiteまで
揃っている感じだったので、Fedoraでビルドを試してみる事にしたり。
終わらず。
2016/01/13
早めに帰着。
「ピアノの森(26)」最終巻。すっかり忘れていたネタがそういう流れになる
のか！と。最後にきっちりまとまってとても良い作品だったと思います。
ところで、帯に「18年間のご愛読、本当にありがとうございました。」
とありますが、
Wikipedia
によると、最初は1998年からヤングマガジンアッパーズで連載
されていたのが途中でモーニングに移籍したという事です。
この為、モーニングKC版の単行本は、1〜10巻の途中までは
初版が2005年発行になってます。TANEはその頃から読み始めた
ので、実時間では約10年という感じです。因みに、手の故障の
話が出たのは2006/12/22初版発行の13巻くらいで、最終巻での
ネタ振り回収まで9年くらい温存してた事になりますが、
理由を満たすのには時間が必要だった為なのかも知れません。
DMD2.069対応の件。そういや、
void readvar(T)(File infile, out T x){T[] d = infile.rawRead(new T[1]) ; x=d[0] ; return;}
:
int var1 ;
infile.readvar(var1) ; //readvar(infile,var1) と同じ。
って書いても良いらしい事を思い出したり。ただ、自分で書く分には
良さげに見えるのですが、人が書いたのを読む場合、Fileのメソッドorメンバー関数
としてreadver()がある様にも見えますので、分かりにくい所にテンプレート
が置いてあると、
「std.stdio.Fileを見てもreadvar()なんて無いぞ？」と訳が分からなく
なる可能性があるかも。例えば、
import std.stdio;
import std.string;
int readX()(TestStruct ts){writef("TestStruct Template\n") ;return ts.x;}
struct TestStruct
{
int x=1,y=2,z=3 ;
int readX(){
writef("TestStruct member func\n") ;
return(x) ;
}
}
void main()
{
TestStruct ts ;
writef("%d\n",ts.readX()) ;
return ;
}
というコードの場合、ts.readX()は、構造体TestStructのreadX()メンバー関数
が実行されます。そして、メンバー関数readX()を別の名前にするなどして無くすと、
テンプレートのreadX()が有効になるようです。勝手にオーバーライドされる事は無い
ようですが、もしオーバーライドできてしまうと、
「メンバー関数を直しても一向に動きが変わらない」という謎の現象に見えてしまう所
かも知れません。
2016/01/12
気持ち早めに帰着。
先日右肩が痛かったのが朝まで続き、少し良くなったと思ったら夜から
再び左肩が痛くなったり。どのような体勢になっても痛くない姿勢が
見つからなくて死亡。
2016/01/11
昼頃起床。
1ヵ月ほど前に左肩が痛くて腕が上がらなくなっていたのですが、
最近やっと回復できたと思っていたところ、昨日から右肩が痛くて腕が
上がらなくなったり。なんてこと。
プロ遊の下に「バイトオーダーの雑記」
という文書を置きました。雑記ですが御参考まで。
ちょろりお出かけ。ついでに本屋に。
「ヤコとポコ(1)」。なんとなく手に取って買ってみたり。
読んだことはないのですが「花のズボラ飯」の水沢悦子氏の
作品だったらしい。
DMDの2.069で std.streamが非奨励になるというワーニングが出るように
なっていたので、GDCにはまだ関係ありませんが対応しておく事にしたり。
で、困った事に「abstract void read(out byte x);」を含む一連の
特定の型の変数に読み込む方法が無くて、えー？って感じに。
画像ファイルのヘッダ部分は型に統一性が無く、リトルエンディアンで
記録されていたりする為、前述の特定の型の変数に読み込むというのは
見た目のアホっぽさを問わなければ、一番シンプルに使用できたのですが......
例えば、biっていう構造体のWidthっていうint型のメンバー変数に
ファイルから値を読み込む場合、「infile.read(bi.Width);」とか
やれば良かったのですが、std.stdioのFileを使用すると、
int[] a = infile.rawRead(new int[1]) ;
bi.Width=a[0] ;
みたいな事を毎回やらなくてはならないという気がしたりも。
ひとまずテンプレートを使って最小限書き換えで済むように対応してみたものの
(完全に置き換え可能な書き方ができるのかも知れませんが、テンプレートスキルが低くて
できず)、オブジェクト指向っぽさがすっかり無くなってます。
void readvar(T)(File infile, out T x){T[] d = infile.rawRead(new T[1]) ; x=d[0] ; return;}
int var ;
readvar(infile,var) ;
毎回newを実行しなくてはならないのだろうか？というのも疑問。
2016/01/10
AM中に起床。
掃除したあと、アパートの契約更新にお出かけ。滞り無く終了。
作文したりコーディングしたり。
そういやWindows10のタスクマネージャーで、詳細タブのプロセス
一覧を選ぶと 全てのプロセスが見られますが、
32bitなのか64bitなのかは区別が付きません。
手持ちソースの32bit/64bit両対応ビルドテストをしていると、
どっちでビルドしたかが判らなくなる時があるので不便です。
Windows7の時は確認できたのに。
2016/01/09
起きたら午後もいい時間。寝すぎ。
libbpgのビルド。
すったもんだしながらどうにかビルドに成功。
全く弄らずにビルドできるようには なっていなさそうなので、
libjpegくらいに手のかからない感じにならないと開発側には
なかなか普及はしないかも。
で、いくつか画像の変換を試してみたり。どうやらエンコードは
マルチスレッドで動作するらしく、全CPUを使って動作している
ようです。スレッドを絞るオプションは無さげ。
概ね良好な結果が得られるようです。
GIMP2.9.2ってのがリリースされている事を知ったり。でも、
安定版は2.8.xしか無いようで、2.9.xは開発バージョンの位置づけの
ようです。そういや、バージョンナンバー x.y.zの yが奇数の場合は
開発バージョンなのだったけ？
さておき、2.10に向けては GEGL推しのようです。他にもキャンバス
の回転表示をサポートしたり、色々と機能追加されているようです
(リリースノート(英語))。
ただ、Known Issuesの所に、安定はしているが性能的にはまだ遅い所が
あるってな事が書かれているようです。
2016/01/08
遅めに帰着。
Emacsのgoogle-translateでJSON readtable errorが出るようになっている件。
masterへの取り込みはまだみたいですが、
こちらに
ワークアラウンドコードが来ていたり。
こちらの
コードをload-libraryで読み込むように.emacsに追加すると、
翻訳できるようになりました。ありがたいことです。本体に統合されればelpaとか
でもインストールできるようになるかと思われます。
2016/01/07
気持早めに帰着。
libbpgをビルドしてみたり。でも、コンパイルエラーで停止。
あまりの眠さに急速停止。
2016/01/06
気持早めに帰着。
調べ事をして終了。
2016/01/05
遅めに帰着。
Emacsのgoogle-translateでJSON readtable errorが出るようになっている件。
こちらのページに
ワークアラウンドが示されて v0.11.3 としてmasterに取り込まれているようなのです。
変更分を手で取り込んで、Cygwin(32bit)のemacs-w32で試してみたのですがエラーするもよう。
論理積を計算する箇所がいくつかありますが、(logand (+ a d) 4294967295)や
(logand a 2147483647)の定数の値が大きすぎて表現できる値を超えているようです。
うまく動いている人が居るのは逆に何故？という気も。
既にIssuesに挙がっている
ようなので、もうしばらく待ちかも。
2016/01/04
遅めに帰着。
ちょろり調べ事をして終了。
2016/01/03
昼前起床。
掃除したり洗濯したり。
何気に東京MXにチャンネルを合わせたら「SHIROBAKO」というアニメを
放送していたり。24話の連続放送の途中だったのですが、見始めたら
面白くて最後まで観てしまったり(^^;
どんなアニメかはWikipedia
とかに譲るとして、実際に原作者からNGが出たらやり直しているのだろうか？
と思ったりも。
ちょろり作文。
2016/01/02
昼頃起床。
完全に昼夜逆転しているので強制反転しないとマズい(^^;
ぐうたら過ごして終了。
2016/01/01
あけましておめでとうございます。今年もよろしくお願いしますm(_'_)m
と言っても年が明けて2.5時間過ぎた所ですが、夜更かししてもそもそコーディングしたり
Webを眺めたり。
なんかPixivが妙な事になっているような。DoS攻撃食らってないか？
寝て起きたら午後もいい時間。寝すぎ。
以前作った1ヵ月分だけを表示する
カレンダーELISPがバグっていたので直したり
(mcalendar_160101.tar.xz)。
正月早々こんな感じです(^^;
1/2付けになってますが、プロ遊の下の
D言語でウインドウクラスを実装したときの話
を更新しました。御参考まで。