早めに帰着。
怒り新党の新3大○○調査会でやってた、新3大アーケードゲームのスゴい職人技
で紹介されていたテトリス動画。
以前見つけた
ARIKAの公式動画のものです。で、今回知ったのですが、
認定モードってランダムで出てくるものらしく、この
動画をとらえるのに、二ヶ月かかったという事。
また、グランドマスターを取れた人は世界に6人しか居ない
らしい。
Emacs+美人時計。死ぬ気配無し。
早めに帰着。
Googleのトップページのアニメーションを見て、何だこれ？と
思ってクリックしてみたら、「火星で水と塩類の化合物が観測
された」という記事が出てきたり。なんか誤解を招きそうな
表現ですが、「塩類の化合物と水が観測された」という事で
良いんですよね？
Emacs+美人時計。死ぬ気配無し。
早めに帰着。
調べ事。
Emacs+美人時計。まだ死ぬ気配無し。
AM中に起床。
掃除したり洗濯したり。
MailingListやNetnewsの頃から、無料で見られる
テキストに対して「購読する」という言い方をする場合があります。
無料なので購読(買って読む)ではないのですが、何故か昔から
そう言われてて、「え？お金取られるならいいや」って思う人は今でも
居るんじゃないかと思います。どうやら「subscribe」が「購読する」
と翻訳された結果のようで、
今日現在でも、例えばInkscapeのMailingListの案内ページでは、
英語ページ
だと「subscribe」となっている箇所が、
日本語ページだと
「購読する」となっています。
Google翻訳 verb 1. 申し込む (apply, subscribe, request, propose, offer, book) 2. 購読する (subscribe)
昼過ぎ起床。
そういやgitのログとかを眺めていると、「Fix a bug.」のような
感じの見出しが付いている事があります。「バグを修正しました」的
な意味なのでしょうけど、「バグを修正してください」という
命令形として捉えられる事は無いのかしら？と思ったりも。
因みに、「Fix a bug.」をWebの翻訳機で日本語に翻訳してみたところ、
| 原文 | Fix a bug. | | Google翻訳 | 不具合を修正しました。 | | Excite翻訳 | バグを修正しなさい。 |
早めに帰着。
朝checkdiskは終わっていたので、デフラグを仕込んで出社。
そういや、記憶には無いのですが デフラグが定期スケジューリングされて
いたり。調べてみると
Windows7の初期設定らしい。で、思ったのですが、今まで勝手に起動
している感は無かったような？ダイアログなどを開かずに裏で実行
されてたものだとして、電源切ったりした場合はどう振舞うんだろう？と
思ったり。もっと言うと、ファイルシステムが壊れるような事って無いんだろう
ね？という所。なんか気になったので定期スケジュールを外してみました。
Emacs+美人時計テストを再度実行。
dmd2.068.2がリリースされているらしい。変更点が少ないのは
バグフィックスリリースだからでしょうか。
早めに帰着。
出掛けにcheckdiskを仕掛けたのですが、終わらず今日はPCを使えなかったり。
前回実績から約10時間くらいで終わる目論見だったのですが、20時間以上
かかってもまだ終わらず。ほっぽらかしのまま寝る。
昼頃起床。
Emacs+美人時計。死ぬ気配無し。長生きになっているのは確かな気も。
浦沢直樹の漫勉の録画を観たり。第一回の東村アキコ氏と、第三回の
浅野いにお氏。続けてみると、両者は対極にある感じですが、
それぞれのやり方、考え方で作品を描いているのだなぁと思いました。
それにしても、漫画を描くって手間がかかる作業だなぁと
見てて改めて感じます。
フォルクスワーゲン不正のニュース。
浄化機能をフルに動かせば試験をクリアできるのに、何故普段は
OFFにしているのか意味が判らなかったのですが、走行性能が
落ちるというのがその理由らしい。浄化機能がそれほど性能に
影響するものなのかしら？
少しWebで調べてみると、JAMA(日本自動車工業会)のページに
「
ディーゼル重量車の排出ガス規制値の日米欧比較」という表があり、
国によって規制値が異なるようです。
この辺とか読んでても、米国基準は厳しいという感覚の
ようです。ふーん。
ちょろりコーディング
Windowsリブートの為、Emacs+美人時計のテストは中断。
昼過ぎ起床。
HDDの検査を行っていたのですが、1ブロックだけ読み書き不能な
セクタがある以外はひとまず大丈夫そう。それにしてはちょいちょい
ファイルが壊れすぎに思いますが。HDD検査ソフトでは、
先頭からブロック読み出しを行うというものだったのですが、
最初の方と7割くらいの位置とでは読み出しスピードが
微妙に違っていたり。最初の方は150MB/sらいだったのが、7割
くらいの所では120MB/sくらいになってました。どうやら
ディスクの外周と内周との差のようで、Webで調べてみると
一般的に外周の方が転送レートが高いそうです。へー。
Emacs+美人時計。普段使いEmacs(-O0コンパイル)も、-O2版Emacsも
死ぬ気配見られず。やっぱりCygwin本体の問題が直ったのか？
Cygwinの2.3.0が正式にリリースされた後も大丈夫なようだったら、
今年の3月から悩まされた
「Emacs突然死問題」は終息したと見て良さそうかも。
そういやImageMagicを含んでビルドすると色々具合が悪くなっていた
件もついでに直ったりして？
Emacs+美人時計。普段使いEmacs(-O0コンパイル)の方が死にましたorz
ダメか.... ただ、死ににくくなっている気はするので、何度か試してみる
事にしよう。
AM中に起床。
Emacs+美人時計。死ぬ気配はまだ見られず。ただし、いつの間にか
画像更新されなくなるという現象が二回ほど発生。美人時計だけを
一旦止めて再実行すれば大丈夫そう。DISKを検査するアプリを実行していた
ので、何か待たされたりしたのが原因か？これは様子見。
普段使いEmacsは-O0で最適化レベルを下げてコンパイルしていました。
-O2だと美人時計起動でずっこけ確率がなんとなく上がるような気がする
というのが理由でした。で、-O2でもずっこけなければイケてるんじゃ？
と思い、-O2で再ビルドしてみる事に。ところが、
src/profiler.cで使用している timer_getoverrun()が見つからんと
リンクに失敗したり。ソースは一切変更していなかったので、Cygwin
の問題だと思ってWeb検索してみたところ、Cygwinでは
timer_getoverrunはサポートされていなかったのが、サポートされる
ようになったようで、/usr/include/time.hには関数宣言が存在
しているのですが、その実体が何故か見つからないという状態だったり。
ひとまず関数を使用しないようにしてビルド成功。
そんな訳で -O2版Emacs+美人時計も同時起動で様子見。
先日ビルドしたCygwin本体とnewlibのソースからtimer_getoverrun
がどこにあるか探してみたのですが、どうにも実体を見つけられず。
なんだこれ？本当にサポートできてるのかしら？
もう少し調べてみると
「
master 531125e: Enable CPU profiling on Cygwin」
なる書き込みを見つけたり(gitのログのようです)。因みに、Ken Brown氏は
Cygwin版 Emacsのメンテナンスを行っている人です。さておき、
確かに、gitのmasterブランチに反映されている模様。だた、
タイトルだけ見るとCPUプロファイリング(?)を有効にする為に
Emacsを弄ったように見えますが、そもそもCygwin側の対応が中途半端な為に
Emacsのコンパイルが通らなくなったのを、Emacs側でワークアラウンド
しているという事では無いのかしら？謎。
AM中に起床。
掃除したり。
Emacs+美人時計。同時に2個動かしているのですが死ぬ気配無し。
追いかけようとすると再現しなくなるパターンか。普段使い用でも
美人時計を起動して、計3つで再現待ち。これで死なないと、新しい
Cygwinでどうにかなっているのか？と思ったりも。
というのは、
「
[ANNOUNCEMENT] TEST RELEASE: Cygwin 2.3.0-0.3」と
いうアナウンス文書のBugFixesに、
「Fix long-standing potential SEGV on 32 bit Cygwin when the dynamic loader for OS functions fails to load a function on Windows 7 or later.」
てな文言があり(勘で読むと「32bit CygwinでDLLのローダーにあった潜在バグを直した」)、
何か関係しそうな気がしたりも。
今年の3月までは大丈夫だったのがCygwinをアップデートした
ある日を境に急に発現
するようになった不具合です。何にせよ これで直ってくれるのならば
ラッキーなのですが、さてどうなるか......？
Emacs+美人時計。結局死ぬ気配が無いので一旦停止＆Windowsを再起動。
ところがcheckdiskを要求されているのに気づかずしばらく待たされるハメに。
いくつかファイルが修復されたり。HDDがちょっとずつ劣化しているような気が。
で、再びEmacs+美人時計を起動して普段使いで様子見。
昼頃起床。寝すぎ。
手持ちD言語コードの中に emacs方式の文字コーディングで言うところの utf-8-dos(改行がCRLFのutf8)
のものがあります。これを全てutf-8-unix(改行がLFのutf8)に変更したいと
思ったのですが、ついでに不要な空白(gitで赤く表示される奴)の削除や
タブ文字の空白への置き換えも行いたいと思ったところ、Emacsのスクリプトモード
を使うのが良いっぽいと知ったり。そんな訳で以下のような感じにしてみたり。
$ cat toUTF8unix.el
(dolist (arg argv)
(let ((file arg))
(with-temp-buffer
(insert-file-contents file)
(untabify (point-min) (point-max))
(delete-trailing-whitespace)
(set-buffer-file-coding-system 'utf-8-unix)
(write-region (point-min) (point-max) file))))
$ emacs-w32 --script toUTF8unix.el *.d
早めに帰着。
先日起動したEmacs+美人時計がしばらくしてSegfaultしたり。
gdbに乗せていたのですが、以下のような感じに。
1 [sig] emacs-w32 11720 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 6, Win32 error 0
35094 [sig] emacs-w32 11720 proc_subproc: couldn't get proc lock. what 5, val 1
40038292 [sig] emacs-w32 11720 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,0), last 6, Win32 error 0
40038994 [sig] emacs-w32 11720 proc_subproc: couldn't get proc lock. what 5, val 0
[Thread 11720.0x30f8 exited with code 0]
80040701 [sig] emacs-w32 11720 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 6, Win32 error 0
80041167 [sig] emacs-w32 11720 proc_subproc: couldn't get proc lock. what 5, val 1
Fatal error 11: Segmentation fault
Program received signal SIGSEGV, Segmentation fault.
terminate_due_to_signal (sig=1488, backtrace_limit=60000) at emacs.c:379
379 exit (1);
(gdb) where
#0 terminate_due_to_signal (sig=1488, backtrace_limit=60000) at emacs.c:379
#1 0x769c1194 in WaitForSingleObjectEx () from /cygdrive/c/windows/syswow64/kernel32.dll
#2 0x769c1148 in WaitForSingleObject () from /cygdrive/c/windows/syswow64/kernel32.dll
#3 0x610f0500 in sig_send(_pinfo*, siginfo_t&, _cygtls*)@12 (p=p@entry=0x60fd0000, si=..., tls=tls@entry=0x0)
at /usr/src/debug/cygwin-2.2.1-1/winsup/cygwin/sigproc.cc:692
#4 0x610ed41c in _pinfo::kill(siginfo_t&)@8 (this=0x60fd0000, si=...) at /usr/src/debug/cygwin-2.2.1-1/winsup/cygwin/signal.cc:252
#5 0x610ed928 in kill0 (pid=pid@entry=11720, si=...) at /usr/src/debug/cygwin-2.2.1-1/winsup/cygwin/signal.cc:303
#6 0x610edb02 in kill (sig=11, pid=11720) at /usr/src/debug/cygwin-2.2.1-1/winsup/cygwin/signal.cc:312
#7 raise (sig=11) at /usr/src/debug/cygwin-2.2.1-1/winsup/cygwin/signal.cc:288
#8 0x610e9f35 in _sigfe () at sigfe.s:38
#9 0x00000000 in ?? ()
(gdb)
早めに帰着。
ここ2ヶ月ほどEmacsで美人時計を起動せずに使っていたのですが、
死ぬ気配が無いことと、Cygwin本体もバージョンアップしている事から、
再び美人時計起動のテストを始めてみる事にしたり。少なくとも、
先日 美人時計を起動したところ1日でEmacsが死んだので(美人時計無し
なら1week以上は死なない)、あまり状況に変化は無い模様。
早めに帰着。
そういや GDBの7.10ってのが最近リリースされたようなのですが、
変更点の一覧を見ていると、「HP/PA running HP-UX (hppa*-*-hpux*)」
と「Itanium running HP-UX (ia64-*-hpux*)」をサポートから外した
という一文が載っていたり。HP-UXってそんなに使われていないん
だっけ？と思ったのですが、新しいリリースもあるようなので
そんなでもないようなと思ったりも。それとも、OSじゃなくてCPU
の方に理由があるのか？
早めに帰着。
SCEJAのプレスカンファレンスを観たり。なんか色々出る事になっていたらしい。
色々出るのは良いと思いますが、直近の2016年1月発売が集中し過ぎてないか？
というのは少し気になったかも。
明日からPlayStation Nowの有料オープンベータが始まるらしい。
何気に150タイトルというのは結構多いかも。レンタルと定額の差が
激しい気がするのですが、調べてみたらレンタルは実時間借りという
事のようです。でも、PS Nowのページ
を見てみても、4時間、7日間、30日間のいずれも「200円+税〜」になってて、
なんのこっちゃ良く判らない気が。
個人的には、定額でガッツリ遊ぶ人はほとんど居ないという状況になるんじゃないかと
推測します。割安だとしても古いタイトルに違いは無い訳で、それで遊べるくらいの
人であれば、PS4のベスト版やPS-plusの月替わりタイトルでも十分
遊べると思う訳です。個人的には客引きに使うのは良いと思いますが、
最終的には新作タイトルに人を誘導するべきだと思います。
何故なら、人に与えられた時間は有限な訳ですから、
新作タイトル以外に誘導してしまうと、新作タイトルから見たら
機会損失になると考えられるからです。色々なゲームのライフスタイルが
あるのは良いと思いますが、「そこはただの入り口、メインはこちら」
という所を押さえた上で展開しないと、「どれもイマイチ」となるかも
知れません。新作で人を引き付けられるのが一番良いと思いますが、
趣向が多岐に渡った現在では、それはなかなか難しいだろうなぁ とは思います。
ま、素人の戯言です(^^;
そういや、人工知能(AI)の定義って何？と思って少し調べてみるも、
意外と定義はあいまいみたい。例えば 将棋の思考ルーチンは、
人と対局はできますが、会話ができたりする訳ではありません。
IBMのワトソンもクイズには答えられますが、日常会話ができる訳では
ありません。自動運転制御も、主に画像認識とフィードバック制御で
行っているので、ある特定のアルゴリズムに基づいてその通りに
動いているだけと思います。そう考えると、ある入力データを元に
統計的な処理を施した結果から行動を決めるというアルゴリズムが
あったとして、膨大な入力データを元に統計的な処理を施した結果が
人の想像したものと違った為に、結果的に人の想像を越えた行動を行った
場合、それを知能的に優れているか？と問われると、なんか違うという
気がしたりも。
機械を使うと人にはできない速度でデータを処理できる場合がある為、
あたかも人を越えたように見える場合がありますが、それが知能的に
優れていると感じるのは単なる錯覚だと思う訳です。恐らくこの先、将棋で
コンピュータの思考ルーチンに人は勝てなくなるだろうと思いますが、
将棋が強くても人と日常会話ができる訳では無いよね？という
点が、人間を越えたように感じるのは錯覚と思う所以です。
という訳で、そもそも 知能って何？ってのが良く判っていないという事が
判った(^^;
早めに帰着。
TV-CMで見るスーパーマリオメーカー。表示性能的に制限がほぼ無い
(と推測される)と、結構な無茶ができるのだなぁと感心します。
ファミコンのように、横に4個以上キャラが並ぶとちらつくみたいな
のだと、無茶なデザインは難しいところかも知れません。
WBSで知った セルロースナノファイバー。覚えておこう。
そういやこれって、金型形成や3Dプリンタ的なもので形成可能なのでしょうかね？
加工が簡単なら使いではかなりありそう。回路基板への応用は進んでいるっぽい。
AM中に起床。
洗濯したり掃除したり。
浦沢直樹の漫勉(藤田和日郎)の録画を観たり。因みに今回は第二回で、
第一回(東村アキコ)は先週放送されてて見逃してます(^^;
さておき、「え？修正液(ホワイト)ってこんなに使うもの？！」ってのに驚きました。
浦沢氏が藤田氏の使う修正液を「魔法の道具」と称していたのですが、ペンと同じくらいに
修正液を使っていたのは衝撃的でした。
起きたら午後もいい時間。寝すぎ。
gdcビルド手順の更新と確認。概ね問題無さそうですが、手持ちコードの
中にx86_64-w64-mingw32ターゲットでコンパイルするとSegfaultで
ずっこけるものがあったり。
Program received signal SIGSEGV, Segmentation fault.
0x00000000005267ac in __mingw_pformat (flags=flags@entry=0, dest=dest@entry=0x22ead0, max=max@entry=511,
fmt=0x22eac6 "", argv=0x22e870 "\003", argv@entry=0x22e858 "")
at c:/crossdev/src/mingw-w64-svn/mingw-w64-crt/stdio/mingw_pformat.c:2112
2112 c:/crossdev/src/mingw-w64-svn/mingw-w64-crt/stdio/mingw_pformat.c: No such file or directory.
(gdb) where
#0 0x00000000005267ac in __mingw_pformat (flags=flags@entry=0, dest=dest@entry=0x22ead0, max=max@entry=511,
fmt=0x22eac6 "", argv=0x22e870 "\003", argv@entry=0x22e858 "")
at c:/crossdev/src/mingw-w64-svn/mingw-w64-crt/stdio/mingw_pformat.c:2112
#1 0x0000000000524519 in __mingw_vsnprintf (buf=0x22ead0 '\377' <repeats 200 times>..., length=<optimized out>,
fmt=<optimized out>, argv=argv@entry=0x22e858 "")
at c:/crossdev/src/mingw-w64-svn/mingw-w64-crt/stdio/mingw_vsnprintf.c:47
#2 0x0000000000523848 in __mingw_snprintf (buf=<optimized out>, length=<optimized out>, fmt=<optimized out>)
at c:/crossdev/src/mingw-w64-svn/mingw-w64-crt/stdio/mingw_snprintf.c:37
#3 0x00000000005bb56a in _D3std6format64__T11formatValueTS3std5array20__T8AppenderTAyaTyaZ8AppenderTeTaZ11formatValueFS3std5array20__T8AppenderTAyaTyaZ8AppendereKS3std6format18__T10FormatSpecTaZ10FormatSpecZv (w=..., obj=0, f=...)
at /usr/local/gdc031_20661_520_mingwcross/lib/gcc/x86_64-w64-mingw32/5.2.0/include/d/std/format.d:1660
#4 0x00000000005c3ee4 in _D3std6format66__T13formatGenericTS3std5array20__T8AppenderTAyaTyaZ8AppenderTeTaZ13formatGenericFS3std5array20__T8AppenderTAyaTyaZ8AppenderPxvKS3std6format18__T10FormatSpecTaZ10FormatSpecZv (w=...,
arg=0x22eea0, f=...)
at /usr/local/gdc031_20661_520_mingwcross/lib/gcc/x86_64-w64-mingw32/5.2.0/include/d/std/format.d:3205
#5 0x00000000005cb50b in _D3std6format69__T14formattedWriteTS3std5array20__T8AppenderTAyaTyaZ8AppenderTaTiTeZ14formattedWriteFS3std5array20__T8AppenderTAyaTyaZ8AppenderxAaieZk (w=..., fmt=..., _param_2=146, _param_3=0)
at /usr/local/gdc031_20661_520_mingwcross/lib/gcc/x86_64-w64-mingw32/5.2.0/include/d/std/format.d:530
#6 0x00000000005de249 in _D3std6string17__T6formatTaTiTeZ6formatFxAaieZAya (fmt=..., _param_1=146, _param_2=0)
at /usr/local/gdc031_20661_520_mingwcross/lib/gcc/x86_64-w64-mingw32/5.2.0/include/d/std/string.d:2799
#7 0x000000000040f962 in OpenGLFrame.OpenGLFrame.mouse(int, int, int, int) (this=0x15c0000, acs_stat=0, mb=1,
x=401, y=301) at OpenGLFrame.d:181
#8 0x000000000040dfc5 in OpenGLBase.OpenGLBase.proc(void*, uint, ulong, long) (this=0x15c0000, hwnd=0x300b1c,
msg=512, wp=1, lp=19726737) at OpenGLBase.d:148
#9 0x000000000045614f in WindowObject.WindowObject.preproc(void*, uint, ulong, long) (this=0x15c0000,
hwnd=0x300b1c, msg=512, wp=1, lp=19726737) at WindowObject.d:215
#10 0x00000000004544d2 in _WndProc (hwnd=0x300b1c, msg=512, wp=1, lp=19726737) at WindowBase.d:184
#11 0x0000000077939bd1 in USER32!TranslateMessageEx () from /cygdrive/c/windows/system32/USER32.dll
#12 0x0000000077933bfc in USER32!CallWindowProcW () from /cygdrive/c/windows/system32/USER32.dll
#13 0x0000000077933b78 in USER32!CallWindowProcW () from /cygdrive/c/windows/system32/USER32.dll
#14 0x000007fef4ee948e in glDebugEntry () from /cygdrive/c/windows/system32/OPENGL32.dll
#15 0x0000000077939bd1 in USER32!TranslateMessageEx () from /cygdrive/c/windows/system32/USER32.dll
#16 0x0000000077933bfc in USER32!CallWindowProcW () from /cygdrive/c/windows/system32/USER32.dll
#17 0x0000000077933b78 in USER32!CallWindowProcW () from /cygdrive/c/windows/system32/USER32.dll
#18 0x00000000004547a3 in _WndSubProc (hwnd=<error reading variable: Cannot access memory at address 0x40>,
msg=<error reading variable: Cannot access memory at address 0x48>,
wp=<error reading variable: Cannot access memory at address 0x50>,
lp=<error reading variable: Cannot access memory at address 0x58>) at WindowBase.d:209
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb)
printStatusbar( format("%d : %f", curbone, cast(double)(x - start_x)*PI/360.0) ) ;
↓↓変更↓↓
printStatusbar( format("%d : %f", curbone, cast(double)(cast(double)(x - start_x)*PI/360.0)) ) ;
$ cat format_real.d
import std.stdio ;
import std.math ;
void main()
{
writef("%f",PI) ;
}
$ x86_64-w64-mingw32-gdc format_real.d
$ ./a.exe
Segmentation fault
$ x86_64-w64-mingw32-gdc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gdc
COLLECT_LTO_WRAPPER=/usr/local/gdc031_20661_520_mingwcross/libexec/gcc/x86_64-w64-mingw32/5.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-5.2.0/configure --with-pkgversion='gdc-5 dadb5a3784' --build=i686-pc-cygwin --host=i686-pc-cygwin --target=x86_64-w64-mingw32 --enable-languages=c,d --prefix=/usr/local/gdc031_20661_520_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
Thread model: win32
gcc version 5.2.0 (gdc-5 dadb5a3784)
早めに帰着。
CygwinでビルドしたMinGWターゲットのgdcクロスコンパイラで
std/socket.oでシンボルが見つからずにリンクに失敗する事がある件。
binutilsをvenix1さんのパッチ入りでビルドしたものを使うように
した所、リンクに失敗しなくなりました。
i686-w64もx86_64-w64 のいずれもbinutilsをビルドすれば大丈夫な模様。
そんな訳でビルド手順を更新してみる事にしたり。
早めに帰着。
そういやGDCのバイナリ
の i686-w64-mingw32ターゲットのgdcは 「-lgphobos2 -lws2_32」を
付加しなくてもリンクに失敗しません。なにか違いがあるのだろうか？
と思い、クロス環境のライブラリをGDCバイナリのものと差し替えて
みたり、GDCバイナリと同じバージョン、同じconfigureオプションで
クロスコンパイラをビルドしてみたのですが、自分でビルドすると
やっぱり「-lgphobos2 -lws2_32」を付加しなくてはリンクに失敗する
場合があります。一体何が違うのだろう.......？
スターフォース。ゲーム設定をデフォルトにしておかないとオンライン
ランキングに登録されないという事に気づいたり。で、何度か
やってみる訳ですがやっぱり100万点には遠く及びません。
因みに今日時点でオンラインランキングの1位は 1億-100点
でカンストスコアが登録されていました(^^;
そういやスターフォースのカンストって今まで聞いたこと無かったなぁ？
と思ったのですが、ともかく すげぇ。
早めに帰着。大量に雨が降ったけど避難勧告出るほどか？とは思った。
そういやWingd3Dの開発版が2.0.1になっていたり。
早めに帰着。
調べ事をして終了。
早めに帰着。
スターフォース。5機設定でどうにか100万点超え。でも
しばらく超えられそうにない、マグレ感満載のプレイでした(^^;
たまたまスターフォースのスゲーのがプレイ動画ライブ配信されていたのを観たり。
最終的に1900万超えで2000万に少し届かずというプレイでした。
いや、いいもん魅せていただきました。
AM中に起床。
掃除したり。
スターフォースをちょろり。スコアが伸びません。
近年の 弾幕系のフルオート連射だと弾詰りを起こす事がほとんど
ありませんが、80年代のシューティングゲームは普通に弾詰りするし撃ち負け
ます。スターフォースは比較的、敵弾数が多いのですが、弾詰まりや
撃ち負けがあると弾を避けるのに支障をきたすという感じです。
とは言え、オンラインランキングの1位スコアは1300万点超え
になってたりしますので、上手い人には関係無いのかも知れません。
AM中に起床。
そういや最近のWACOMのタブレットはマルチタッチ対応になっている
ようなのですが、マルチタッチを使用する例がペイントツールとは独立
に紹介されていて、ペンタッチとマルチタッチが混在できるのか
イマイチ分かりにくい説明になっているようにも思ったり。
とは言え、マルチタッチ対応したペイントツールがあまり無いという
のも、そういう説明になっている原因の一つかも知れません。
で、思ったのですが、液晶マルチタッチタブレットと、非液晶マルチタッチタブレット
とでは、似てるけどできる事が全然違うんじゃないか？と思ったり。
| 操作 | 液マルチタブ | 非液マルチタブ | マルチタッチによるボタン操作やメニューパネル操作 | ○ | ×(*1) | スワイプやマルチタッチによるキャンバスのスクロール/回転/拡大縮小 操作 | ○ | △(*2) | ソフトキーボード操作 | ○ | ×(*1) | フリック入力 | ○ | 限りなく×(*3) |
$ cat mingwgdcfailed_test3.d
import std.stdio;
import std.string;
size_t testFunc(in void* p){
writef("Here is testFunc %08x %08x\n",&p,p) ;
return(0) ;
}
class Foo{
this(){
}
size_t FootestFunc(){
writef("Here is FootestFunc %08x\n",&this) ;
return(0) ;
}
}
void main()
{
Foo f = new Foo() ;
size_t function(in void*) tF=&testFunc;
size_t delegate() dg_footestfunc = &f.FootestFunc ;
tF(cast(void*)f) ;
testFunc(cast(void*)f) ;
f.FootestFunc() ;
dg_footestfunc() ;
}
$ gdc mingwgdcfailed_test3.d
$ ./a.exe
Here is testFunc 0028fbe0 00fb1fe0
Here is testFunc 0028fbe0 00fb1fe0
Here is FootestFunc 0028fbcc #←0028fbe0になるのが正解
Here is FootestFunc 0028fbcc #←0028fbe0になるのが正解
$ gdc -v
Using built-in specs.
COLLECT_GCC=C:\MinGW\i686-gdc-2.066.1_gcc5.2.0\i686-w64-mingw32\bin\gdc.exe
COLLECT_LTO_WRAPPER=c:/mingw/i686-gdc-2.066.1_gcc5.2.0/i686-w64-mingw32/bin/../libexec/gcc/i686-w64-mingw32/5.2.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: /home/build/tmp/build/.build/src/gcc-5.2.0/configure --build=x86_64-build_unknown-linux-gnu --host=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/home/build/tmp/install/i686-w64-mingw32 --with-sysroot=/home/build/tmp/install/i686-w64-mingw32/i686-w64-mingw32/sysroot --with-local-prefix=/home/build/tmp/install/i686-w64-mingw32/i686-w64-mingw32/sysroot --enable-languages=c,c++,d --with-arch=i686 --disable-shared --with-pkgversion='crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 20150830-2.066.1-dadb5a3784' --with-bugurl=http://bugzilla.gdcproject.org --enable-__cxa_atexit --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --with-gmp=/home/build/tmp/build/.build/i686-w64-mingw32/buildtools/complibs-host --with-mpfr=/home/build/tmp/build/.build/i686-w64-mingw32/buildtools/complibs-host --with-mpc=/home/build/tmp/build/.build/i686-w64-mingw32/buildtools/complibs-host --with-isl=/home/build/tmp/build/.build/i686-w64-mingw32/buildtools/complibs-host --with-cloog=/home/build/tmp/build/.build/i686-w64-mingw32/buildtools/complibs-host --with-libelf=/home/build/tmp/build/.build/i686-w64-mingw32/buildtools/complibs-host --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --enable-threads=win32 --disable-win32-registry --enable-target-optspace --disable-nls --disable-multilib --enable-long-long
Thread model: win32
gcc version 5.2.0 (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 20150830-2.066.1-dadb5a3784)
2015/09/04
早めに帰着。
あまりの眠さに急速停止。
早めに帰着。
プロ遊の下に
「MinGWターゲットのクロスGDCをCygwinでビルド」
を置いてみました。御参考まで。
早めに帰着。
鳥人間コンテスト。40kmいけるか？と思ったのですが、32km時点で
あと8kmは無理な感じがしたり。結果、歴代記録の36kmにちょっと届かず。惜しい。
36km折り返し帰還に初めて成功した時にも
書きましたが、
休まずにずっと回し続けなくてはならない訳ですから、
相当な筋力と体力が必要だと思います。逆に、最低2時間
漕ぎ続けられなくては帰還は無理だとも言えるかも知れません。
そろそろエンジンとなる人間への対策が必要なのかも。
因みに、以前
人力飛行の世界記録を調べた時、116kmを4時間飛行した
という事だったので、そこまでは必要無いにしても
何かしら特別なトレーニングが必要なレベルになっているの
かも。
早めに帰着。
MinGWターゲットのクロスGDCをCygwinでビルドする手順をまとめようと
しているのですが、Org-mode 8.3.1が なかなかに仕様が変わっていて
突っかかりどころ多数。うまくExportするのにorgソースが
読み辛くなるのは なんだか本末転倒です。