昔の最近の出来事(2016.04)

2016/04/30

昼頃起床。

gdc-6(gcc-6.1.0向け)が来ているようだったのでビルドしてみたり。 テストバージョンだったgcc-6.0.0向けのパッチを概ねそのまま適用してみたり。 一件だげthreadに関するパッチが当たらなかったのですが、 元のファイル自体が無くなってただけなので特に問題無し。
ほどなくしてビルド完了。外付けのライブラリ群は6.0.0のを コピーして手持ちコードのコンパイルテストを実施。どれも特に問題無く ビルド&実行できました。ひとまずi686-pc-mingw32ターゲットでCygwinクロス コンパイラを試してみたので、他(i686-w64-mingw32のCygwinクロス, x86_64-w64-mingw32のCygwinクロス, i686-w64-mingw32のMSYS2ネイティブ, x86_64-w64-mingw32のMSYS2ネイティブ)も順次試してみる感じで。

$ 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) ;
}

$ i686-pc-mingw32-gdc -O2 iam.d

$ ./a.exe
GNU D gnu 2.067 (D2)
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_610_mingwcross/libexec/gcc/i686-pc-mingw32/6.1.0/lto-wrapper.exe
Target: i686-pc-mingw32
Configured with: ../gcc-6.1.0/configure --with-pkgversion='gdc-6 73a7fb5d4e(DMD2.067)' --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-mingw32 --enable-languages=c,c++,d --prefix=/usr/local/gdc_2067_610_mingwcross --with-sysroot=/usr/i686-pc-mingw32/sys-root --enable-threads --disable-nls --enable-sjlj-exceptions --disable-bootstrap
Thread model: win32
gcc version 6.1.0 (gdc-6 73a7fb5d4e(DMD2.067))

その後、i686-w64-mingw32のCygwinクロスとx86_64-w64-mingw32のCygwinクロスに ついては、コンパイラのビルドも、それを使った手持ちコードのビルド&実行 も特に問題無さげ。もうしばらく様子見で使ってみよう。

MSYS2ネイティブgdcでいつの間にかcurlをリンクしなくてはならなくなっていた件。 std.net.curlをimportするコードだとリンクが必要になる所は判ったのですが、 std.net.curlをimportしてないコードでもダメな場合の原因が掴めず。ひとまず 手持ちの画像ロードライブラリの6個のファイルが関係していそうという所 までは判ったのですが、ファイルのどこからcurlに繋がっているかまでは 追跡できず。

PNMフォーマットのローダー単体コードでcurlリンクが必要な所まで追跡できたり。 でも、BMPやTGAのローダー単体コードとimportしているライブラリは全く 同じな為、何故PNMフォーマットのローダーコードだけがcurlリンクが必要に なるのか判らず。

どうやらstd.conv.to テンプレートでchar配列から整数変換するコード を含んでいると何故かcurlリンクが必要になるもよう。

$ cat link_fail_test.d
import std.stdio;
import std.conv ;
import std.string ;

int main()
{
  char[] buf ;
  buf.length=3 ;
  buf[0]='1' ; buf[1]='2' ; buf[2]='3' ;
  int v;
  v=std.conv.to!(int)(buf);
  writef("conv = %d\n",v) ;

  return(0) ;
}

$ gdc -O2 link_fail_test.d
c:/msys64/mingw32/local/gdc20661_520_mingw/bin/../lib/gcc/i686-w64-mingw32/5.2.0/../../../../lib/libgphobos2.a(curl.o): In function `D3std3net4curl4Curl18_sharedStaticCtor2FZv':
C:\msys64\home\TANE\gdc\build_gdc_test1\GDC-dadb5a3784fc9e12761e49c35937ad1c594c824d\build_gcc_i686-w64\i686-w64-mingw32\libphobos\src/../../../../gcc-5.2.0/libphobos/src/std/net/curl.d:3498: undefined reference to `curl_global_init'
:メッセージ沢山
collect2.exe: error: ld returned 1 exit status

$ gdc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw32\local\gdc20661_520_mingw\bin\gdc.exe
COLLECT_LTO_WRAPPER=c:/msys64/mingw32/local/gdc20661_520_mingw/bin/../libexec/gcc/i686-w64-mingw32/5.2.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../gcc-5.2.0/configure --with-pkgversion='gdc-5 dadb5a3784' --build=i686-w64-mingw32 --host=i686-w64-mingw32 --target=i686-w64-mingw32 --enable-languages=c,d --prefix=/mingw32/local/gdc20661_520_mingw --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
Thread model: win32
gcc version 5.2.0 (gdc-5 dadb5a3784)

例えばこれが単に「std.conv.to!(int)("123");」とかだとリンクに成功します。 そして、「std.conv.to!(int)(buf.idup);」でもリンクに成功する事が判ったり。 ワークアラウンドとしては後者が良さげです。うーむ、それにしてもcurlと何の関係があるんだ?

2016/04/29

昼過ぎ起床。寝過ぎ。

もそもそとコーディング。

そういやDConf 2016。 今年はドイツで開催されるようです。CESTなのでJSTとの時差は-7時間。 ライブ配信があれば丁度良い時間に観られるのですが、後日動画アップ のパターンでしょう。

以前 MSYS2でビルドしたgdcを使ってコンパイルテストをしていたところ、 何故かcurlをリンクしなくてはならなくなっていたり。gphobos2の中から 参照されているようですが、極簡単なソースのコンパイルだと特に問題 無くリンクできる為、どうにも違いが判らなかったり。

2016/04/28

遅めに帰着。

Web散策していて知った timp というEmacsでマルチスレッドを扱う為のライブラリ。 YouTubeにデモ動画が上がってます (Emacs Multithread Demo, Emacs Multithreading Performance)。 興味深いです。

Cygwinのパッケージアップデートをしたところ、プロセスの一覧をリアルタイム 表示するtopコマンドの表示がやたら派手になってたり。

New top command on Cygwin

ただ、CPU数が100個以上あるようなサーバーだと、プロセス一覧枠が表示できなく なるように思ったりも。

2016/04/27

遅めに帰着。

gcc-6.1.0が来ていたり。

2016/04/26

遅めに帰着。

ちょろり調べ事。

2016/04/25

遅めに帰着。

POUETのとあるパーティーにエントリされていた作品のプラットフォーム に「SAM Coupé」ってのがあったのですが 何なのか判らなかったので Web検索してみたところ、1989年製のイギリスのホームコンピュータらしい (参考Wikipedia) というのを知ったり。 日本語のページが一切出てこないというのも珍しいかも。 1980年代は世界的にも色々なマシンが存在してたんだなぁと改めて思ったりも。

2016/04/24

AM中に起床。

洗濯したり掃除したり。

そういえば、スクロールアップ/ダウン、右/左スクロールといったとき、 背景が動く方向だっけ?それとも視線が動く方向(即ち背景が動く方向と逆)だっけ? とふと思ったり。概ね視線が動く方向で正しい感じなのですが、 Emacsのscroll-up/scroll-downコマンドは表示領域の動く方向を指していて、 スクロールバーの矢印の方向とは名前の意味が逆のようです。 因みにxyzzyでは next-page/previous-page というコマンド名になってい るようです。

2016/04/23

起きたら夕方。寝過ぎ。

PS4に来ていた「グラディウスII -GOFERの野望-」をポチってみたり。 X68kのはコンティニューを繰り返してどうにかこうにかクリアできていた のですが、なんか全く歯が立ちません(^^; アーケード版ってコンティニュー 無いんだっけ? そういえば、オープニングでグラディウス、沙羅曼蛇、と来て グラディウスIIのタイトルになりますが、それぞれ画面が切り替わる 時に画面の上の方に少しノイズが乗るのが再現されています。 X68kでノイズが乗っていたのはハードの都合によるものだと思っていた のですが、アーケード版でも乗っていたのかしら?と思ったりも。

2016/04/22

遅めに帰着。

「シュガー・ラッシュ」の後半から観たり。色々版権の関係で地上波では 難しかったりする?と思ったのですが関係無かったのかも。 シュガー・ラッシュの監督の新作が「ズートピア」という繋がり での放送だったもよう。

そういやこの前の剰余テストのコードですが、DMD2.071.0で試したところ、 MinGWと同じ結果になりました。

$ ../dmd/dmd_2.071.0/windows/bin/dmd.exe mod_test.d

$ ./mod_test.exe
test1 4
test1 3
test1 2
test1 1
test1 0
test1 5
test1 4
test1 3
test1 2
test1 1
test2 4
test2 3
test2 2
test2 1
test2 0
test2 -1
test2 -2
test2 -3
test2 -4
test2 -5

gdcのバグでは無さそう。 剰余演算のWikipedia によるといくつかアルゴリズムがあり、C99やDでは 「0への切り落とし除算(Truncated Division)」ってのが使われている ようです。ただ、size_t(uintやulong)が何故この結果になるのかは よく分からず。

2016/04/21

遅めに帰着。

Web巡回して終了。

2016/04/20

遅めに帰着。

ちょろりコーディング。なんかgdcのバグっぽい感じが。

$cat -n mod_test.d
     1  import std.stdio;
     2  import std.string ;
     3
     4  int main()
     5  {
     6    int[] list = new int[10];
     7    int cur ;
     8
     9    cur=5 ;
    10    for( int i=0; i<list.length; i++ ){
    11      cur = (cur-1)%list.length ;
    12      writef("test1 %d\n",cur) ;
    13    }
    14
    15    cur=5 ;
    16    for( int i=0; i<10; i++ ){
    17      cur = (cur-1)%10 ;
    18      writef("test2 %d\n",cur) ;
    19    }
    20
    21    return(0) ;
    22  }

$ i686-pc-mingw32-gdc -O2 mod_test.d

$ ./a.exe
test1 4
test1 3
test1 2
test1 1
test1 0
test1 5
test1 4
test1 3
test1 2
test1 1
test2 4
test2 3
test2 2
test2 1
test2 0
test2 -1
test2 -2
test2 -3
test2 -4
test2 -5

$ 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-20160221/configure --with-pkgversion='gdc-6 77f216c1b9' --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 20160221 (experimental) (gdc-6 77f216c1b9)

なんか剰余の結果がintのそれと違ってたり。配列のlengthプロパティ値の 型はsize_tですが、size_tの剰余演算がバグっているような気も?

因みに、Fedoraの方でビルドしたgdcでは以下のような結果に。

$ gdc -O2 mod_test.d
mod_test.d:11:11: error: cannot implicitly convert expression (cast(ulong)(cur - 1) % list.length) of type ulong to int
     cur = (cur-1)%list.length ;
           ^
$ gdc -m32 -O2 mod_test.d

$ ./a.out
test1 4
test1 3
test1 2
test1 1
test1 0
test1 5
test1 4
test1 3
test1 2
test1 1
test2 4
test2 3
test2 2
test2 1
test2 0
test2 -1
test2 -2
test2 -3
test2 -4
test2 -5

$ 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-20160221/configure --with-pkgversion='gdc-6 77f216c1b9' --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 20160221 (experimental) (gdc-6 77f216c1b9)

64bitだとulong演算結果をint型に代入できなくてエラーとなります。 32bitだとコンパイルできて、結果はMinGWのそれと同じになりました。 MinGW限定の話では無さげ。

負数の剰余結果はプログラム言語により異なるようなのですが、 プログラム言語内で整数型の違い(浮動小数と整数だと違うようなので) によって結果が異なるって事は無いかな?と思ったり。

2016/04/19

遅めに帰着。

ちょろりコーディング。

2016/04/18

遅めに帰着。

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

2016/04/17

AM中に起床。

洗濯したり掃除したり。

ちょろりコーディング。

2016/04/16

昼過ぎ起床。

昨日の深夜から地震報道に切り替わっているもよう。 二度目の方が本震というのは聞いた事が無いパターンです。

ちょろりコーディング。

2016/04/15

遅めに帰着。

全く気付いていませんでしたが、 「燃えろ!!プロ野球2016」。 マジでか。 こちらのページの下の方に「ジャンル 燃えプロ」とあって吹いた のですが、 こちらの記事にあるように、開発者の意向通りという事らしい。

2016/04/14

遅めに帰着。

熊本で大きな地震があったもよう。

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

2016/04/13

遅めに帰着。

XEiJの0.16.04.12が出ているのを知ったり。 SCSI HDDイメージからbootできる事を知り、XM6で使っている .HDSファイルを 食わせてみたところ何故か認識されず。ファイル→SCSI→ SCSIハードディスク/CD-ROM イメージを開く のダイアログからファイルを 選択しようとしても、何故かファイル一覧に出てこず。ファイル名の拡張子 だけでなく中身を見て判別しているようなのですが、何故認識されないのか までは判らず。

2016/04/12

遅めに帰着。

PS4のリモートプレイの解像度。どうやら720pの設定はちゃんと効いていた模様。 一番最初に540pでウインドウを開いたのですが、そのサイズが覚えられていたため、 720pの画像ソースが540pに縮小表示されていたようです。 で、720pでは下り転送レートが約9Mbpsでしたが、540pでは約5.5Mbps必要 なようです。概ねピクセル数に比例した転送レートが必要という感じのようです。

2016/04/11

AM中に起床。本日休業。

コーディングしたり掃除したりぐうたら過ごしたり。

「ONEPIECE(81)」。色々とネタ振りと回収がありながらの あの展開とは。 まだまだ当分続きそうです。

2016/04/10

午後帰着。

PS4のシステムソフトウェア3.50で、PCからのリモートプレイが サポートされたのを知ったり。

PS4 リモートプレイ on PC

設定では720pの解像度にしてみましたたのですが、何故か540pになっている ようです(確かに(説明Webページには540pと350pの説明しか無い)。サイズを540p720p、フレームレート「高」にした場合、 約9Mbps(1.1MB/秒)の下り転送レートになるようでした。 流石にレイテンシはどうにもならなくて、キー入力に少し遅れて 画面が追い付いてくるという感じ。アーケードアーカイブスのスターフォースくらい だとなんとか操作できる感じですが、TRIALS FUSIONは 全く思い通りに操作できない感じでした。RPGやシビアなアクションを 必要としないゲームであれば全然問題無いかも知れません。 ただ、操作の為にDUALSHOCK4が必要なので、実用的かと言われると ちょっと微妙な気がしたりも。
因みに、DLNAサーバをPCにして、PS4のメディアプレイヤーでDLNA動画再生を リモートプレイで操作してPC(DLNAサーバのPCと同じ)に表示すると いう事もできるようです(^^;

2016/04/09

早起き。

ちょこっと帰省。

2016/04/08

遅めに帰着。

ちょろり調べ事。

2016/04/07

遅めに帰着。

ちょろりコーディング。

2016/04/06

遅めに帰着。

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

2016/04/05

遅めに帰着。

ちょろりコーディング。

2016/04/04

遅めに帰着。

ちょろりコーディングのつもりが意外と面倒臭い感じだったり。

2016/04/03

昼過ぎ起床。

掃除したり洗濯したり。

ダラバー。全然伸びず。

2016/04/02

昼前起床。

「マイクロソフト、BashシェルをWindowsに搭載。」という 記事。 「本物のBash」とかなんのこっちゃよく判らない文言が散りばめられている のはさておき、Linuxバイナリを直接実行する仕組みで動くらしい (どうやら Linuxシステムコール実行をエミュレーションする方法っぽい)。 性能的に問題無いレベルで動いたりすると、CygwinやMinGWをはじめ 仕方なくVMwareでLinuxを使う必要も無くなるかも知れません。 X-Window対応は今の所無いっぽいですが、それもサポートされると いよいよLinuxじゃなくても良くなるかも知れません。

ひさびさにダラバー。でも、何度かやったのに1度しかバーストカウンターに 成功しなかったり。サイドカウンターに至ってはこれまで一度も成功したことが ありません。なんか根本的にタイミングを間違っているのか? そういやリプレイデータを見る仕組みが無い事に今頃気づいたり。 上手い人のをオンラインダウンロードしてボタン入力表示付きでリプレイ再生 できるとありがたいのですが。Webの動画だけだと結局タイミングが良く分かりません。

2016/04/01

遅めに帰着。

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


TOP PREV