昔の最近の出来事(2017.02)

2017/02/28

遅めに帰着。

mcalendarを少し弄って表示をカスタマイズできるようにしてみたり。

2017/02/27

早くも無く遅くも無く。

ちょろりコーディング。

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

2017/02/26

昼頃起床。

ぐうたら過ごして終了。

掃除したり洗濯したり。

突然思いついてちょろりコーディング。

2017/02/25

AM中に起床。

GDCその後。 大工事は一旦落ち着いた感じも。そして一気にDMDの2.07x系に追従 しているみたい。なんかMinGWターゲット向けに大分手を入れなくては 動かなくなりそうな予感(^^;

PS4で発売予定の「Horizon Zero Dawn」を予約注文してみました。 2015年のE3トレーラーでプレイ動画が公開されていたので、予告通り 2016年初めに出るのかな?と思っていたのですが、1年スリップした感じです (2016年度ならばギリ間違ってはいないですが)。楽しみです。

2017/02/24

早くも無く遅くも無く。

買って読めていなかったマンガ本を読んだり。
「それでも町は廻っている(16)」。本巻が最終巻です。 アニメ版から入った口ですが、 いろんなエピソードが混ざってて、全巻通して飽きる事が無い感じ だったように思います。そういやサイコロの絵のネタって1巻から あったんだっけ?と、読み直してて思ったり。
「ど根性ガエルの娘(1),(2)」。Web散策をしていてたまたま 知ったのですが、 その後発売されたハズのアスキー版1巻が入手できないまま 現在に至ってました。まさか10話で一旦アスキーでの連載を終了して、 その後白泉社に移籍して続いていたとは。そんな訳で要望を受けて 1,2巻同時発売という事になったみたい。3巻は今年の夏発売予定らしい。 「衝撃の第15話」とは?気になる。

2017/02/23

早くも無く遅くも無く。

拙作EmacsLISPのmcalendarですが、閏年判定結果の扱いがバグってて 常に2月29日が存在してました(^^; そんな訳でバグ修正版を置いてみました。 御参考まで。

2017/02/22

早くも無く遅くも無く。

調べ事。

2017/02/21

早くも無く遅くも無く。

ちょろり調べ事。

2017/02/20

気持早めに帰着。

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

2017/02/19

AM中に起床。

TokyoDemoFest2017。昨日は観る時間が取れなかったのですが、 今日は少しだけ観る事ができたり。当初スケジュールよりも 時間が大分押していたこともあって、DemoCompoは観られず。 Pouetの方にはアップロードされている ようですが、今年のcombined demoは1本だけだったのかしら? wild demoとかは後日アップロードされるのかも。
※後日追記:他のもアップロードされてました。

掃除したり洗濯したり。そしてちょろりお出かけ。

1年ほど前からアナログの落書きに0.9mmシャープペン( ぺんてるのグラフギア500) を使ってるのですが、グリップが真鍮製なので「若干重いなぁ?」と思いながら 使ってました。もう少し軽いのが欲しいなぁと思い、探してみると軽くて 安いのがあったのでそれを買ってみたり。そういやメーカーが判らんなぁ? と思い調べてみると、「プラチナ万年筆株式会社」という所の 商品だった模様(参考)。 知らなかったのですが、結構古くからあるメーカーらしい。
ついでにシャープペンシルのWikipediaを 読んでみると、今ある0.9mm~0.3mm芯の太さって全て1970年より前から存在 している事を知ったり。0.9mmや0.7mmなんて知ったの割と最近なのですが(^^;

2017/02/18

昼前起床。

約1ヵ月(35日)ほどWindowsが再起動無しで動いていたのに加えてEmacsも ずっと動いていたのですが、急にプロセス制御がおかしくなって 制御不能になった為、Emacsを強制終了しました。ここまでは たまにある事なので良いですが、 その後再び立ち上げようとしたらjavaコマンドが見つからないという 旨のメッセージが出てEmacsの起動が途中で止まるようになったり。 確かにjava.exeへのパスが無くなっているのですが、そもそもjavaの パスなんてどこに通っているのか意識した事無いので、何が変わったのか 判らず。仕方ないのでWindowsを再起動したのですが、それでも状況が 変わらず。なんでだ?
仕方無いのでパスを調べて追加してみた所 Emacsを起動できたり。 因みにjavaコマンドを要求しているのはpuml-modeの初期化の中でした。 外部コマンド依存が高いとこういう時にちょっと困るという感じなの ですが、まぁ shellが無いとダメとか言い始めるとキリが無いので こういうものだという事で。

そういや「PS Now」の一部デバイスのサービス終了する話。 今あるデバイスのうち、PS4以外は店じまいという感じみたい。 丁度サービスが始まる直前のメモで 定額で遊ぶ人はほとんど居ない状況になるのでは?と書いたのですが、 結果としてどんな感じだったのかしら?とは思ったりも。 検索してもサービス終了のニュースサイト以外のコメントなどは あまり見当たらず。

MinGWの標準入出力が遅い件。 C言語の以下のようなコードでMinGWとCygwinとで比べてみたり。

$ cat -n stdin_stdout_test.c
     1  #include <stdlib.h>
     2  #include <stdio.h>
     3
     4  #define BUFSIZE (8192)
     5
     6  int main()
     7  {
     8    FILE *ifp, *ofp ;
     9    char *buf ;
    10
    11    ifp=stdin ;
    12    ofp=stdout ;
    13
    14    buf=malloc(BUFSIZE) ;
    15    if( buf==NULL ){
    16      printf("Memory Allocate failed.\n") ;
    17      exit(1) ;
    18    }
    19
    20    while(-1){
    21      size_t size ;
    22      size=fread(buf, sizeof(char),BUFSIZE,ifp) ;
    23      if( size==0 ) break ;
    24      fwrite(buf, sizeof(char), size, ofp) ;
    25    }
    26
    27    return(0) ;
    28  }

$ gcc -O2 stdin_stdout_test.c

$ gzip -dc ./testdata.csv.gz | time ./a.exe | wc -l
1.67user 1.96system 0:17.87elapsed 20%CPU (0avgtext+0avgdata 502784maxresident)k
0inputs+0outputs (2138major+0minor)pagefaults 0swaps
10000000

$ i686-pc-mingw32-gcc.exe -O2 stdin_stdout_test.c

$ gzip -dc ./testdata.csv.gz | time ./a.exe | wc -l
0.01user 0.00system 0:25.94elapsed 0%CPU (0avgtext+0avgdata 275456maxresident)k
0inputs+0outputs (1230major+0minor)pagefaults 0swaps
10000000

MinGWの方が遅いです。また、Cygwinのtimeコマンドでは全然判りませんが MinGWの実行バイナリの方はCPUを100% 使用します。Cygwinの方だとCPU は20% くらいしか使用しません。殆どがファイル(パイプ)のアクセス なので、CPUは食わないのが妥当だと考えられますが、MinGWは そういう感じではないようです。

再びD言語で以下のようなコードを書いて調べてみたり。

$ cat -n stdin_stdout_test.d
     1  import std.stdio;
     2  import std.string;
     3
     4  int main()
     5  {
     6    File  infile=stdin ;
     7    const bufsize=8192 ;
     8    char[] BUF=new char[bufsize] ;
     9
    10    while(-1){
    11      char[] buf=infile.rawRead(BUF) ;
    12      if( buf.length==0 ) break ;
    13      stdout.rawWrite(buf) ;
    14    }
    15
    16    return(0) ;
    17  }

$ i686-pc-mingw32-gdc.exe -O2 -frelease stdin_stdout_test.d

$ gzip -dc ./testdata.csv.gz | time ./a.exe | wc -l
0.00user 0.01system 0:18.22elapsed 0%CPU (0avgtext+0avgdata 275200maxresident)k
0inputs+0outputs (1237major+0minor)pagefaults 0swaps
10000000

あれ?! MinGWのgdcなのに MinGWのgccのそれよりも速いぞ? そしてCPU使用率も50%くらいでした。C言語のそれと変わらないか 遅くなるのが期待値だったのですが、なんだか訳が分からなくなってきました。

2017/02/17

気持ち早めに帰着。

MinGWクロスgdcの標準入力読み込みが遅い件。 とあるコードのコンパイル後の実行時間をi686-pc-mingw32, i686-w64-mingw32, x86_64-w64-mingw32 とで比べてみたり。結果は以下の通り。

使用コンパイラELAPS対DMD ELAPS比
i686-pc-mingw32-gdc6:23.843.795
i686-w64-mingw32-gdc8:14.724.891
x86_64-w64-mingw32-gdc4:41.142.779
dmd_2.073.01:41.151.000

MinGWの標準入力は遅い、もしくは標準出力が遅い、もしくはその両方という気がしてきたりも。

2017/02/16

気持ち早めに帰着。

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

2017/02/15

気持ち早めに帰着。

D言語での動的配列の初期値と確保について調べたり。以下のようなコード とその実行結果。

$ cat -n ddim_test.d
     1  import std.stdio;
     2  import std.string ;
     3  import std.array : appender, uninitializedArray;
     4
     5  void main()
     6  {
     7    char[] buf;
     8
     9    buf.length=0 ;
    10    writef("%d  is null:%6s   length:%s\n",__LINE__,buf is null,buf.length) ;
    11
    12    buf.length=10 ;
    13    buf[0]='0' ;
    14
    15    buf.length=0 ;
    16    writef("%d  is null:%6s   length:%s\n",__LINE__,buf is null,buf.length) ;
    17
    18    char[] buf2;
    19    char[] dst ;
    20
    21    auto app=appender(buf2) ;
    22    dst=app.data ; writef("%d  is null:%6s   length:%s\n",__LINE__,dst is null,dst.length) ;
    23
    24    app.clear() ;
    25    dst=app.data ; writef("%d  is null:%6s   length:%s\n",__LINE__,dst is null,dst.length) ;
    26
    27    app.reserve(128) ;
    28    dst=app.data ; writef("%d  is null:%6s   length:%s\n",__LINE__,dst is null,dst.length) ;
    29
    30    app.put('0') ;
    31    dst=app.data ; writef("%d  is null:%6s   length:%s\n",__LINE__,dst is null,dst.length) ;
    32
    33    app.clear() ;
    34    dst=app.data ; writef("%d  is null:%6s   length:%s\n",__LINE__,dst is null,dst.length) ;
    35
    36    return ;
    37  }

$ i686-pc-mingw32-gdc -O2 -frelease ddim_test.d

$ ./a.exe
10  is null:  true   length:0
16  is null: false   length:0
22  is null:  true   length:0
25  is null:  true   length:0
28  is null: false   length:0
31  is null: false   length:1
34  is null: false   length:0

通常の配列では、最初は null になってて、長さを'0'にしてもそれは変わらないようです。 一旦伸ばした後、再び長さを'0'にするとnullではなくなります。
std.arrayの中にあるappenderというのが良い感じに配列を伸ばしてくれるようで、 それについても見てみました。最初はnullで、clear()を実行してもnullなのですが、 予め予約域を設定するとnullじゃなくなり、以降clear()してもnullに戻る事は 無いようです。
以上の動作はDMD 2.073.0でも同じようです。

readln()のMinGW向けに使用していた実装では以下のようにしてました。

private size_t readlnImpl(FILE* fps, ref char[] buf, dchar terminator, File.Orientation)
{
:中略

    buf.length = 0;
    for (int c; (c = FGETC(fp)) != -1; )
    {
        buf ~= cast(char)c;
        if (c == terminator)
            break;
    }
    if (ferror(fps))
        StdioException();
    return buf.length;
}

この場合、bufがnullの状態から始まった場合、いきなりFGETC()の戻り値が-1だったら bufはnull且つ長さ0となります。
所が、bufを適当に伸ばしておき、最後に読み込んだ量に応じて長さを縮めるような コードにした場合、bufは長さ0の場合でもnullになる事はありません。 これが stdin.readln()の実装においては具合が悪く、

import std.stdio;

void main()
{
    string line;
    while ((line = stdin.readln()) !is null)
        write(line);
}

のコードの場合、標準入力がEOFに達したとしても、 stdin.readln()がnullを返す事が無くなる為、無限ループに陥ります。 これが改良した(つもりの)readln()が上手く動かない原因でした。 ただ、DIGITAL_MARS_STDIOのreadln()の実装では、最初にapp.reserve(128)でリザーブ領域を 割り当ててるので、上手く動かないのが正解のようにも思えるのですが(実際に移植して動かなかった訳ですが)、 そういう訳では無い?ようです。
で、対応方法ですが、最終的にバッファの長さが0になった場合は bufにnullを突っ込んで長さは0を返すようにすれば意図通りに動作した のですが、なんか釈然としない気も。そして多少は早くなった気も しますが、劇的な改善という感じではなかったり。それが一番ガッカリ。

2017/02/14

気持ち早めに帰着。

MinGWクロスgdcを使うとstdinからの読み込みが遅い件。 libphobosのそれらしきコードを眺めていたところ、readln()の実装において、fgetc() で得た文字を 配列の結合で一文字ずつ繋ぐコードになっていました。 DIGITAL_MARS_STDIOとかではstd.arryaのappenderというものを 使っているようで、どうやら配列を高速に伸ばす感じになって いそうだったので、そのまま移植してみたのですがうまく動かなかったり。

2017/02/13

遅めに帰着。

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

2017/02/12

AM中に起床。洗濯したり掃除したり。

時々deviantARTの数人の絵描きさん から関連付けられたタグなどを頼りに、その他の絵描きさんの作品を 眺める事があります。今まで特に意識した事無かったのですが、 意外と東南アジア圏出身/在住と思われる人が居るなぁと思ったり。 大分前に「Anzu Hizawa(アンズ・ヒザワ)」 というマンガ家さん(deviantARTのページ) の存在を知ったのですが、この方はインドネシアの人でした (現在は天空の城に住んでいるようです(^^; 冗談なのか、高層マンション的 な所に住んでいる例えなのかは不明)。 さておき、多少の地域色は感じられるものの、国によらずレベルの高い人は 居るものだと思ったりも。

Webを散策していたら「 世界のおもちゃ・鉄道模型メーカー・ゲーム開発会社」というページを知ったり。 ゲーム開発会社のページを眺めていて、日本やアメリカの数が異常に思えたりも(^^; 日本のは情報が得られやすいという理由で大小よらず挙げられている為、他より 多く見えるという可能性はありますが、それにしても人口の比率に対してどうなんだ? とは思います。逆に韓国ってこんなもんなんだっけ?というのが意外に思ったりも。 もっと多いのかと思ってた。ハードプラットフォームの有無に関係しているのかも? とは少し思ったりも。そう考えるとワールドワイドで見た場合、PCやスマフォは 最もオープンなプラットフォームと考えて差し支えないのかも。当たり前と言われれば そうかも知れませんが。

2017/02/11

AM中に起床。

散髪ついでにおでかけ。

Rust。split()が速いという事で他はどうかと調べているのですが、 なんかやっぱり直観的に使えなくて辛いです。String型と&str型の 違いが今だに区別できなかったり(型の違いで文字列を連結するのに '+'が使える/使えないの違いがある)、(regexとかgetoptsとか)標準ライブラリ じゃない為ちょっとしたテストの為にいちいちcargoでプロジェクトを 構成してライブラリをインストールしなくてはならなかったり、 Webのコードを参考にしたらライブラリのインターフェースが変わってて ハマったり。実行時性能が悪ければ即 挫けてしまう所かも。

逆にD言語のsplit()をもう少し速くできないものなのか? と思ったりも。RustもD言語もネイティブコンパイラなので、 原理的には同じ性能を出す事は可能だと思うのですが....

D言語でcsv形式をsplit後、再び分割したフィールドを結合して出力 をするコードで、何ネックなのかをWindows上で調べ直したり。ざっくり以下の ような感じ。

因みに、「gzip -dc test.csv.gz | ./test_program.exe > /dev/null」 で調べてみました。例えばtest_program.exeがネックになっている場合、 test_program.exeのCPU使用率に対して前段のgzipのCPU使用率は減ります。 split()を使うと、test_program.exeは1CPUを100% 使うのに、gzipは1% 以下 のCPU使用率になったりします。そして行数を数えるだけのコードに 書き換えると、手前のgzipも後段のtest_program.exeも100% 使用率に なります。これはこれでイマイチです。 行数を数えたりするwcコマンドだと 手前のgzipは100% ですが、 wc自身は数% のCPU使用率になります。この場合はgzipの展開がネック と言えます。

2017/02/10

早めに帰着。

調べ事。

2017/02/09

気持ち早めに帰着。

先日知った「TI-99/A4」関連の動画に 「Dragon's Lair on TI-99/4A (Proof of Concept)」 という動画があったのですが、 そういや「ドラゴンズレア」ってどんなゲームだっけ?と思い調べてみたり (参考Wikipedia)。 LD(レーザーディスク)ゲームだったのか。 完全攻略動画だけ を見ていると難しさがイマイチ伝わらないですが、絵の状況から 判断して操作するというのは大分無理があるような気も。 そういや以前、怒り新党で すぐ死んじゃうゲームの一つに ファミコン版のドラゴンズ・レアが 挙げられていたのを思い出したり。クリア動画を探してみたら ありました( NES Longplay [440] Dragon's Lair, Dragon's Lair Speedrun (0:06:56) NES, TAS HD: Dragon's Lair (NES) by Kirkq in 03:53.6 )。 最後のはTASなので除くとして、なんか簡単そうにやってますけど、 見切った動きがなんかスゲーかも。 90年代に発売されたのもあってか、よく見ると絵は良くできている ように思ったりも。

2017/02/08

気持ち早めに帰着。

調べ事。Rustでカンマ区切りのcsvファイルを扱うのにsplitを 使って実行速度を調べていたのですが、なんかヤケに速い気がする。 あるコードのFedora上での実行時間比で、ざっくり 「Rust : D(+gdc) : perl = 0.5 : 2.5 : 3.0」という感じ。 D言語の残念さ加減から言うとかなりイケてる気がします。

Pouetで最近のパーティーの作品を眺めていたところ、 とあるOldSchoolデモ「Don't mess with Texas」 で、「TI-99/4A」というマシンの存在を知ったり。 何故か日本語のWikipedia が存在していたので読んでみたところ、1981年1月にリリースされた ホームコンピュータとの事。因みに、 PC-6001が1981年11月、ぴゅう太が1982年8月、ファミコンが1983年7月 という世代関係です。 CPUはTI(テキサス・インスツルメンツ つまり自社)のTMS9900 (参考Wikipedia) という奴で、大分変わったアーキテクチャの 16bit CPUみたいです。 これの上位互換であるTMS9995は ぴゅう太のCPUらしいです。 という情報を踏まえた上で デモをもう一度観てみると、とんでもない 絵が出ているように思えます。

任天堂 SwitchのTVCMが流れ始めているな。

2017/02/07

気持ち早めに帰着。

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

2017/02/06

早くも無く遅くも無く。

ちょろり調べ事。

2017/02/05

昼前起床。

掃除したり洗濯したり。

「ONEPIECE(84)」。利害関係がガッチリ固まってしまってて、どうやって 打開するんだ?という感じに思ったりも。まだまだ続きます。
そういや今巻表紙に、ヴィンスモーク姉弟のカラーイラストが載って いますが、レイジュがピンクずくしなのは TANEの思っていた脳内カラーとは 違ってたかも。Pixivで検索しても、黄色髪が多いのはサンジと姉弟だから という所が大きいかも。

2017/02/04

AM中に起床。

ドラマの「スーパーサラリーマン左江内氏」。回を追うごとに くだらなさが増しているように思えるのですが、なんか観てしまいます(^^;

ちょろり本屋に。ギャラリーフェイクの33巻が出ていたので買ったり。 そして、家に帰ってから 32巻を買っていなかったというのに 気づいたり。なんてこった。

2017/02/03

気持早めに帰着。

眠くて死亡。

2017/02/02

遅めに帰着。

Rustを少し触っているのですが、全く直観的に使えません。 また、Webの例をそのままコピペしてもコンパイルエラーになるしで、 標準入力から読み込んで、行番号付けて標準出力に表示するだけの コードを書くのにすったもんだしている感じです。 この 扱いにくさは何なのだろう。

2017/02/01

遅めに帰着。

調べ事をして終了。


TOP PREV