遅めに帰着。
あまりの眠さに急速停止。
遅めに帰着。
調べ事をして終了。
遅めに帰着。
Web巡回して終了。
遅めに帰着。
何故かPCだけネット接続ができなくなってて再起動。その後、何故か
TeraTermからCygwin接続できなくてまた再起動。ひとまず問題無くなった
ものの、原因不明なのが解せない。
AM中に目が覚め、うだうだしてたら昼。
掃除したり。
ちょろり実験。表示してみただけ。
16x16ドットのチップを敷き詰めているのですが、重ね合わせはできないので、
スプライトのようにはいかない感じ。てか、16x16ってそのまま表示させるとちっちゃ！
スムーズに動かそうと思うと、8x8とか4x4のチップにするのが良さそうですが、
そうすると全てをそのサイズに区切らなくてはなりません。すると、
殆ど全部を複合スプライト/BG扱いで管理する必要があるので、なにかしら
表示の仕組みを考える必要がありそうです。
てな訳で、もう少し簡単にイケるのかな？と思ったのですが、意外と面倒臭い
感じになりそうというのが判った気も。
Revision 2016。Modern Graphicsを見る事ができたり。最初の方を少し
見逃してしまいましたが、割と上手い感じのが揃っているように思いました。
使用するツールはPhotoshopが多いですが、1作品だけSAIを使ったものが
ありました。
昼過ぎ起床。寝過ぎ。
Revision 2016。CEST時間のようなのでJST-8時間。セミナーとかは
観られそうですが、コンポは眠くて観られそうにありません(^^;
PS4の「はーとふる彼氏」
というゲームの存在に気づいたり。どうやら日本の同人サークルによるPCゲームだったようで
話題になっていたそうです
(はーとふる彼氏のWikipedia)。
パブリッシャーはGHI Media,LLC(Devolver Digital)という所のようで、
Wikipediaを
勘で読む感じアメリカの会社のようです。日本の同人ゲームが海外の
パブリッシャーにより日本で(も)発売されるというのはややこしい
感じがしなくもありませんが、PCでは海外版へ移植されていた所を見ても
比較的容易に海外展開できる状態にあったのかも知れません。
そういやEmacsLISPで、画像データを挿入するにはinsert-image関数を使用
します。一方、文字列の場合は insert関数を使用します。このとき、画像は
文字ではありませんので、concat関数で 文字列を連結する感じで画像を連結
する事ができません。絵文字の要領で扱う訳にはいかないという感じです。
X68kのBG面のようにチップ画像をタイル状に 並べて表示しようと思うと
なかなか面倒臭い感じです。
遅めに帰着。
ちょろり調べ事。
あ、そういや本日でへっぽこページは16周年を迎えました。
気づくと5bit必要な期間になってましたよ(^^;
毎度みてくださっている方々に感謝いたします。これからもよろしくお願い致しますm(_'_)m
遅めに帰着。
そういや明日からRevision 2016
が開催されます。動画配信で観られるかな？
遅めに帰着。
ちょろり調べ事。
遅めに帰着。
調べ事をして終了。
起きたら午後もいい時間。寝過ぎ。
左腕が痛くてぐったり。去年末から断続的に続く肩の痛みの副作用
のような気も。どうしたもんか。
先日作ったELISPをテストしているとEmacsごとお亡くなりになる現象
に遭遇したり。作りがマズっていた所があり、直してみたところひとまず
安定。でも、ELISPのバグによってSegfaultを引き起こせるということは、
安定度的にまだ改善余地があるという事なのかも知れません。
AM中に起床。
掃除したり洗濯したり。
x86_64ターゲットのgdcでgetopt()が動かない件。
更にコードを切り出して、以下のようなテンプレートを使ったコードが
ダメそうな事が判ったり。
$ cat -n template_bug_test.d
1 import std.stdio;
2 import std.string;
3
4 dchar optchar='-' ;
5 private void chkopt(T...)(ref string[] args)
6 {
7 foreach( no, arg ; args ){
8 writef("%d %s %s %x\n",no,arg,arg[0]==optchar,optchar) ;
9 }
10 }
11
12 void main(string[] args){
13 chkopt(args) ;
14 return ;
15 }
$ x86_64-w64-mingw32-gdc -g -O2 -m64 template_bug_test.d
$ ./a.exe aa bb cc -h -x
0 C:\cygwin\home\TANE\develop\dlang\test\a.exe false 0
1 aa false 0
2 bb false 0
3 cc false 0
4 -h false 0
5 -x false 0
$ gdc -O2 -m64 template_bug_test.d $ ./a.out aaa bbb ccc -h -x 0 ./a.out false 2d 1 aaa false 2d 2 bbb false 2d 3 ccc false 2d 4 -h true 2d 5 -x true 2d $ 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)
昼過ぎ起床。寝過ぎ。
手持ちD言語コードの中にstd.getopを使用したコードがあるのですが、
x86_64ターゲットのgdcでビルドすると期待通りに動いていない感じだったり。
$ cat -n getopt_test.d
1 import std.stdio;
2 import std.string;
3 import std.getopt;
4
5 void main(string[] args){
6 bool opt_help=false ;
7
8 try{
9 getopt(args,
10 std.getopt.config.caseSensitive,
11 "help|h", &opt_help ) ;
12 }catch(Exception e){
13 writef("%s\n",e.msg) ;
14 return ;
15 }
16
17 if( opt_help==true ){
18 writef("This is PirntHelp.\n") ;
19 }
20
21 foreach( n, arg ; args ){
22 writef("%2d: %s\n",n,arg) ;
23 }
24
25 return ;
26 }
$ i686-pc-mingw32-gdc -O2 getopt_test.d $ ./a.exe aaa bbb ccc 0: C:\cygwin\home\TANE\develop\dlang\test\a.exe 1: aaa 2: bbb 3: ccc $ ./a.exe -h aaa bbb ccc This is PirntHelp. 0: C:\cygwin\home\TANE\develop\dlang\test\a.exe 1: aaa 2: bbb 3: ccc $ ./a.exe -h -x aaa bbb ccc Unrecognized option -x
$ x86_64-w64-mingw32-gdc -O2 -m64 getopt_test.d $ ./a.exe aaa bbb ccc 0: C:\cygwin\home\TANE\develop\dlang\test\a.exe 1: aaa 2: bbb 3: ccc $ ./a.exe -h aaa bbb ccc 0: C:\cygwin\home\TANE\develop\dlang\test\a.exe 1: -h 2: aaa 3: bbb 4: ccc $ ./a.exe -h -x aaa bbb ccc 0: C:\cygwin\home\TANE\develop\dlang\test\a.exe 1: -h 2: -x 3: aaa 4: bbb 5: ccc $ 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-20160221/configure --with-pkgversion='gdc-6 77f216c1b9' --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 20160221 (experimental) (gdc-6 77f216c1b9)
if (!a.length || a[0] != optionChar) //optionCharが何故か0
↓↓↓↓↓
if (!a.length || a[0] != '-') //こちらなら反応する
|
→ |
|
遅めに帰着。
あまりの眠さに急速停止。
遅めに帰着。
具合が悪くて急速停止。
遅めに帰着。
そういや長いことDMD2.058ベースのGDCを使っていたので、すっかり忘れて
いましたが、2.06xならば UFCS(Uniform Function Call Syntax)が使えるように
なってます。ただ、メンバー関数orメソッドかと思って探したら違ってて、
しかもどこに定義があるのか直ぐに見つけられない事があるとか、
関数呼び出しと見た目の実行順序が逆なので、慣れてない目で見ると、
a.b.c.d.write とかは、どうなるんだっけ？ってのが直ぐ判らないとか、
個人的にはイマイチに感じます。
遅めに帰着。
調べ事をして終了。
遅めに帰着。
Web巡回して終了。
昼頃起床。
x86_64ターゲットのgdcでcurlがsegfaultする件。
curlと言いつつ、実際にはlibssh2を使ってsftpを実行しているのですが、
どうやらクロスビルドに失敗している模様。話は二つありそうで、一つは
コネクションに失敗している、もう一つはコネクションに失敗した後の
例外処理でズッコケるという感じ。前者はlibssh2のビルドがうまくいっていない
と思われる所ですが、後者はgdcにマズっている所がありそうという感じでしょうか。
掃除したり。
MSYS2(x86_64)で libssh2-1.7.0をネイティブビルドしてみたのですが、
exampleとして生成さるscp.exeとかはやっぱり動かなかったり。あれぇ？
Cygwinでビルドしたところやっぱりダメだったので、ソースを見てみた
ところ、普通のscpとは引数の指定方法が違っていたり(^^; でも、
Cygwinでビルドしたのは32bitも64bitも動いたのですが、MinGW64のは
クロスビルドのもネイティブビルドのも動かなかったり。なので、
やっぱりlibssh2のビルドがうまくできていないという事には変わりが
無い模様。
MinGW64ネイティブの方でgdbに載せてみたみたところ 普通に動いたり。
エー？
結局、libssl, libcrypto はMinGW64のできあいのスタティックライブラリを、
libcurlとlibssh2(結局scpが普通のbashコマンドラインから動かない理由は
判らないまま)はMinGW64でネイティブビルドしたものを使って、
Cygwin上で動作するgdcのx86_64ターゲットのクロスコンパイラでソースを
ビルドしたところ、sftpの動く実行ファイルが生成できました。
ただし、multiple defineの問題はそのまま残っているので、x86_64ターゲットの
gdcではリンカオプションの--allow-multiple-definitionの指定が
必須になってます。
ひとまずgcc-6.1が来た時に、すぐに乗り換えられそうかな？という感じ。
昼前起床。
先日のビルドはi686-pc-mingw32,i686-w64-mingw32,x86_64-w64-mingw32どのターゲットとも
エラー無く終了。手持ちコードをいくつかコンパイル＆実行してみましたが、
使った範囲では問題無さげ。もしかするとパッチのいくつかは不要になって
いるのかも知れませんが、確認はしてません。
散髪に行ったり。
これまで、x86_64ターゲットでlibcurlのビルドができなかった為、curlを使った
コードのテストは放置していたのですが、今ならできないか？と思い試して
みたり。で、ビルドの方は取りあえず libcurlとlibssh2 はconfigureの
おかげでCygwinのクロスmingw-gccを使ってクロスコンパイルできましたが、
opensslはビルドできず。でも、ひとまずこれで試したり。
gdc側のハマり所として、随分前に
htonl(), ntohl(), htons(), ntohs() がmultiple define でリンクできなかった
ので、core/sys/windows/winsock2.d内の関数定義を削除して対応。
で、なんとかリンクはできたものの、実行してみるとcurlのFTPでSegfaultしている
ようだったり。少し追いかけてみたところ、libphobos/libdruntime/rt/lifetime.d内
のメモリ割り当てで失敗しているような。うーむ。
そういや、lifetime.dの中で「for (auto i = 0; i < n; i++){...}」という
ループコードがあるのですが、この場合のiの型は何になるんだろう？と
思ったり。
winsock2.dの関数定義を削除してしまうと、libphobosの再ビルドに失敗
してしまうので、リンカオプションの--allow-multiple-definitionで
multiple defineを許可(よきに計らってくれる？)で回避してみたり。
それにしてもx86_64の方が安定度が低い気がするのは何故だろう？
遅めに帰着。
gcc-5対応のgdc-2.067を試そうかと思ったのですが、あと1ヵ月もすればgcc-6.1
が出るであろうという事でgcc-6.0(開発版スナップショット)で試す事にしたり。
で、ビルド待ち。
遅めに帰着。
gdc-2.067のMinGW向けにパッチを作ったり。
遅めに帰着。
mplayのアスキーアート表示。実はCygwin-Xのウインドウが開ける
仕掛けになっていて、それだとFull-HD表示させてもモッサリ感が
無いというのに気づいたり。あと、minittyでもモッサリ感が無く
シャキシャキ表示されました。
gdc5-2067というブランチができているようだったり。
週末にでもMinGWビルドを試してみよう。
大分遅めに帰着。
Web巡回して終了。
遅めに帰着。
GDCの2.067が
ついにmasterにマージされました。そして、2.068対応がスタートしたようです。
gdc-5(gcc-5.x.xをベースとするブランチ)へのマージはまだのようなので、
それが来たらMinGWビルドを試してみよう。
所で、DMD2.069からはフロントエンドがD言語化されていて、LDCの方は
2.069.2を取り込めているようです。GDCはもうしばらく先って所でしょうか。
AM中に起床。
掃除したり洗濯したり。
ちょろり実験コーディング。動画をアスキーアートに変換して表示するとどれくらい
の速度で表示できるだろうと思ったり。結論から言うと驚くほど高速には
表示できないという感じ。生成したファイルは
こちら(tane_anim_ascii.txt.xz)。
ターミナルサイズを幅183文字以上、高さ61文字以上にして、「xz -dc tane_anim_ascii.txt.xz」
とかでターミナルにぶちまけば再生されるという感じです。
そこそこのフレームレートは出るようですが、もっと高フレームレート
になる事を期待してました(^^;
で、以前、音声＆動画再生用にビルドした
MPlayerに、aalibを経由してascii artで表示するという機能が付いている事を知ったり。
使っていた奴はstaticリンクしていた都合で使えなかったのですが、再ビルドしてみた所、
使える感じだったり。ただ、表示が何やら変な感じでオプション類を調べてみたところ、
「mplayer.exe -vo aa:driver=linux -monitorpixelaspect 0.5 -quiet foo.mp4」
とかやればターミナルサイズに合わせてレンダリングするようです。
「driver=curses」にするとカラーシーケンスを使用するようですが、なんか
微妙です。全画面(316 x 91 文字)でレンダリングするとレンダリングスピードの方が
追い付かないようでモッサリした感じになります。
先週、0.9mmのシャープペンを買ったのですが、その時、0.2mmのシャープ芯
があり、そんなのあるんだと思いました。0.3mmシャープペンというのは
25年以上前から存在していたのですが、とにかく簡単に折れるので
製図などの特殊用途という感じでした。それよりも細いって？と思い、
少し調べてみたところ、どうやら折れにくい仕掛けになっている事を知り、
興味が沸いてきたので買ってみました。
それが「orenz」です。
確かに普通に書いてても全く折れる気配がありませんでした。
常にパイプで包んだ状態にしているというのがポイントのようです。スゲェ。
起きたら午後もいい時間。寝過ぎ。
大分前に BigDogなる四本足の
歩行ロボットの存在を知ったのですが、その後の進化(?)で二足歩行に
なったのが、今回知った
動画。
Atlasって名前らしい。雪道でも平気だし、物も運べるし、自分で起きられるし、
中の人スゲー(違 って感じです。
ちょろっとperlでコーディングする用事があったのですが、
リアルタイム文法チェックの為にflycheckを使ったり。
D言語とかでコーディングする場合はコンパイラのバージョンとか
オプションとかを指定する必要がある環境の為flymakeを使うのですが、
perlのように環境依存度が強くないプログラムの場合はflycheckが
手軽で良い感じです。で、今まで気にしたことが無かったのですが、
ファイルをオープンする際に、
open(infile, $file) ;
Unquoted string "infile" may clash with future reserved word (perl)
open('infile', $file) ;
open(INFILE, $file) ;
遅めに帰着。
あまりの眠さに急速停止。
遅めに帰着。
Cygwinアップデートしたらgitが使えなくなったりして。rebaseした
後にWindowsを再起動する必要があるパターンにハマった模様。
取りあえず使えるようになったものの、なんとなく釈然としない気も。
遅めに帰着。
ちょろり調べ事。
遅めに帰着。
ちょろりWeb巡回して、speed-type。やればやるほど伸びない。