日付け越え前に帰着。
先日分割したNTEmacsパッチから、取り込むものと、取り込めないものとに
仕分けたり。取り込めない理由はMinGW特化になっててCygwinでコンパイル
できないから。仕分けだけで終了。
昼過ぎ起床。
録画消化したり調べ事をしたりぐうたら過ごして終了。
NTEmacsのIMEパッチには24.3向けに 20130503版というのがあるのですが、
それを使ってCygwinビルドを試してみたり。結果から言うとビルド失敗。
mbstring.hというヘッダを使用するようなパッチになっているのですが、
Cygwinには無いヘッダファイルの為、ビルドできないという感じに。
IME対応以外にもパッチが色々増えていて、差分が良くわからなかったので
パッチを分割するスクリプトを書いたりして差分を調査中。
朝から休日出勤。早くも無く遅くも無く。
いつの間にかメールが送信できなくなっていたのに気づいたり(^^;
送信サーバ名など、いくつか設定変更が必要になっていた模様。
日付け越え前に帰着。
調べ事をして終了。
遅めに帰着。
emacsの描画の様子を調べてみたり。1行スクロールや半ページスクロール
では、WM_PAINT→WM_EMACS_PAINTの流れでフレーム再描画が行われて
いるようです。しかし、フレーム全面を書き換えるような、
例えばend-of-bufferやbeginning-of-bufferで画面書き換えが必要と
なる場合、何故かWM_EMACS_PAINTのイベントが発生しません。
でもフレームは書き換わるので、なんで？と思ったり。
遅めに帰着。
調べ事をして終了。
日付け越え。
Web巡回して終了。
先日の高速化パッチではバッファサイズを4096byteのままにしていましたが、
4倍の16kbyteに増やしてみたり。速度的には14秒くらいまで縮みましたが、
これ以上は描画速度ネックになるみたい。因みに -nw では同じバイナリで
6.7秒になるようなので、完全にemacs-w32のウインドウ描画の遅さが見えてきた
感じかも。
昼前起床。
先日の速度改善の件。改善の理由が少し違っているかも。
延ばしていると思っていた間隔は実は縮めていたというのが一つ、
バッファを増やしてみたものの、そもそもバッファが満杯になるまで
使っていなかったという事がもう一つ。このため、描画間隔を
縮めていたのが少し効いていただけだったので、バッファの方は
増やしてもちっとも速度に変化がありませんでした。
で、読み出しの方ですが、最終的にはread()システムコールを
実行している訳ですが、毎回260byte程度しか読み出されず、
それが描画1回に対応する感じ。ここをもう少し溜めてから
描けば良い気がしなくもありませんが、emacs-24.3/src
ディレクトリをlsで表示した 合計約4100バイト程度の文字列が
デバッグプリントで目で追えるくらいの速度でしか表示されない時点で
遅すぎるという気がしたり。
emacs_read()(≒read())を4回実行してまとめて再描画してみる
ように変えてみたり。31401行あるsrc/ChaneLog.11をcatで表示した
速度を比べてみた結果、2倍速くらいまで改善したり。
lessとかを使ってもシャキシャキ感を感じるくらいになったのですが、
TeraTermの表示と比べてみるとまだ全然遅いです(^^;
4倍読みして2倍しか速くならないので、次のボトルネックに
引っかかっている可能性があるのかも。
そういや速度改善のついでに 文字落ちっぽい現象が少なくなった気も。
恐らく一回の読み出しの260byteくらいで切れてutf8シーケンス違反に
なっていたのが、1kbyteくらいまで読むようになった為、シーケンス違反に
なりにくくなった(確率が1/4になった)だけだと思いますが。
もう少しいじって、4096byteのバッファを使い切るまでemacs_read()を
続けるようなコードに変更してみたところ大分速くなりました(^^)v
結局、何もいじっていない元のコードよりも 8.3倍速になりました。
term+mux-new後、「time cat ChangeLog.11」のreal時間で比較 オリジナル : real 2m56.253s 高速化版 : real 0m21.043s TeraTermで開いたCygwin bashで「time cat ChangeLog.11」した結果(参考) TeraTerm : real 0m3.954s
昼過ぎ起床。
emacsの描画の様子をデバッグプリントを有効にしながら少し見てみたり。
普通のテキストエディットでは見た目が変わらなければスクロールしても
再描画しないような最適化の仕組みが入っているようです。
しかし、全画面書き換えが必要な場合でも、普通のテキストエディット時はせいぜい
キーリピート間隔でしか再描画は必要ありません。
そもそも全画面書き換えがどれくらいの速度で行われているかは判らず。
でもやっぱり、term+モードでの再描画間隔が短すぎる(==再描画頻度が高すぎる)
のが原因の一つにあるように思います。で、scroll-stepなどを変えてみたり
したのですが、term+画面ではこれが有効にならない模様。むぅ。
もう一度Fedora上のemacsをTeraTermを経由して -nw で起動した後、
term+を使用してみたのですが、この場合でも描画が速いです。
Cygwinのemacsも同じくTeraTermを経由して -nwで起動した後、
term+を使用したのですがやっぱり描画が遅い。なんとなくFedoraの方は
再描画間隔が短くなるような動きをしているようにも見えるのですが
よくわからず。
emacsのterm表示が遅い件。-nwの挙動から察するに、emacs-w32の再描画処理が
遅いのではなく子プロセスからの出力読み出しが遅いのでは？という点を疑い、
src/process.cを調べてみたり。ADAPTIVE_READ_BUFFERINGという仕組みがあるようで、
適当な間隔までバッファに溜めて読み出しを行っているようでした。
で、バッファ量を増やして待ち時間を延ばしてみたら
(即ち バッファに溜める量を増やす事で描画回数を減らす)、
少しだけ速度の改善が見られたり。
ほこたてのドリル対金属。
金属側は担当を変えての対戦となりましたが、ついに金属に穴が空けられ
てしまいました。金属の方は硬度が上がっているにも関わらず、ドリルの方は
磨耗が殆ど無かったという点で、今回は圧倒的にドリルの方が強かった
のではないかと思ったり。
午後から休出。遅めに帰着。
Web巡回したり調べごとしたり。
emacs-w32 on Cygwin と term+
の組み合わせで 使い始めて大分経つのですが、
やはり表示が遅いのがイマイチです。ついでに、日本語文字が
文字落ちしているかのように ところどころ化ける場合があります。
で、Fedora上の emacsでも同じように表示が遅く、文字化けしたり
するのかしら？と思い、term+を入れて試してみたり。
24.1の為か term+muxはエラーする為termのみの使用となりますが、
ちっとも遅くありませんし全く日本語文字化けもしません。
この速度なら不便を感じる事はほぼ無いだろうという感じでした。
そんな訳でemacs-w32には何かしら表示高速化の余地があるように思ったり。
遅めに帰着。
調べ事をして終了。
遅めに帰着。
「Grand Theft Auto V」の初日売上が8億ドル
(参考)。
すげぇ。IVの時は初日売上3.1億ドルで、
発売24時間で最も売れたゲームとしてギネスブック認定されましたが、
そのときの2.5倍以上です。未だにレーティングZのゲームがこれだけ
売れる理由は謎ですが。
「グラディウスを学習させてみた（１面）」という
動画。
画面を認識している訳ではなく、スタートから正確に操作を再生できる
前提で、死なないパターンを見つけ出しているという感じのようです。
ランダムな要素があるとダメだと思われますが 面白いです。
日付け越え前に帰着。
ちょろりWeb巡回して終了。
日付け越え。
ちょろり調べ事をして終了。
AM中に起床。
関東地方は明け方から午前中が雨風のピークだった模様。午後には雨は上がってました。
なんとかデキモノの痛みは引いた模様。
もそもそとコーディング。ちょっと変えれば大丈夫と思ったら
思い通りになってなくてあれぇ？だったり。
勘違いがあったのを修正したつもりがバグらかしてて、それを調べるコードも
バグらかしてて二重遭難してました。修行が足りません。
昼前起床。
org-modeの8.1.1が出ていたり。
元々更新頻度が高く、毎週x.x.1ずつバージョンが上がっているという感じ
だったのですが、8.0.4くらいから数ヶ月リリースがありませんでした。
ここ1ヶ月で再び更新頻度が上がっている模様。それにしても、org-modeって
ドキュメントの量がハンパないのですが、頻繁なバージョンアップの度にメンテ
しているのはすごいと思います。
ちょろりコーディング。
胸のデキモノが痛くて長時間起きていられず。
来年発売が予定されているらしい「ぷよぷよテトリス」。
ぷよぷよとテトリスとで対戦ができるらしい。
邪魔ぷよ自体は連鎖逆転に使える訳では無いぷよぷよよりも、
下手に積んでいないのであれば、邪魔ブロックが下から上がってくる
上に邪魔ブロックを一発逆転に使えるテトリスの方が、
有利じゃないか？と思ったのですが、そうでも無いのかしら？
昼前起床。
先日寝る直前に足をつってしまい、あまりの痛さにしばらく眠れ
ませんでした(^^; 起きてもまだ足が痛むレベル。ついでに
デキモノもできていて触ると痛いため、どんな体勢でも痛くて
死亡。
イプシロンロケット打ち上げをネットのライブ配信で見てみたり。15分ほど
遅れての打ち上げでしたが、うまくいったもよう。
NHK総合でも打ち上げの瞬間だけライブ放送していて、そちらの方が
映像的には数秒ほど早く届いてました。
打ち上げ後はGoogle earth上に飛行位置を表示して現在位置を示していましたが、
地球の表面を飛んでいるという感じ。高度1000kmくらいまで上がるようですが、
自分でも実際にGoogle earthで1000kmくらいの高度の表示を行ってみたところ、
意外と地球から離れている感は無いように思ったりも。まぁ、スペースシャトル
や国際宇宙ステーションも300km〜500km位の高度なので、それよりは
高い所を飛んでいる訳ですが。
因みにGPS衛星は高度 20200kmくらいを飛んでいるようで、これくらいの高度だと
丸い地球が見られるという感じです。こうしてみると、イプシロンロケット
って思ったほど遠くの宇宙に行ってる訳では無いようです。
もそもそとコーディング。
venix1氏のメンテしている
MinGW-GDCが
久しぶりにアップデートされていたり。gcc-4.8.1対応になっている模様。
まだx86_64対応は入っていないようです。
日付け越え前に帰着。
Web巡回して終了。
遅めに帰着。
Web巡回して終了。
早くも無く遅くもなく。
あまりの眠さに急速停止。
遅めに帰着。
Web巡回して終了。
遅めに帰着。
ちょろり調べ事して終了。
先日TVをつけたまま寝てしまったのですが、2020年の東京オリンピック
が丁度決定した時に目が覚めたり。
TV朝日で東京オリンピック決定後も生放送していたのをWeb巡回しながら
観ていたのですが、何気にTVの番組表で他局の欄をみていたら、午前7時頃
には ニュース系番組は「東京開催決定」の文字を含んだタイトルになっていたり。
地デジを介して送られてくる番組表ってほぼリアルタイムに更新されているんだ
というのに改めて気づいたり。
以前、
「All your base are belong to us」というフレーズの存在を知ったのですが、
このときはWikipediaだけを読んで、何か変な英語がウケたらしいくらいの
理解でした。Wikipediaの解説ではウケた理由のニュアンスがイマイチわからなかった
のですが、外部リンクの中に
「
"All your base " vs. "反省しる "」
というのがあり、この記事でウケたニュアンスを一発で理解できました。
録画してあった鳥人間コンテストを観たり。タイムトライアルが大幅に記録
更新。1km飛べる事が最低条件にも関わらず、成功率が上がっているのに
驚きです。ディスタンス部門は折り返しに成功したのが1機のみ。今回は
風が難しかったのか、いきなり失速するパターンが多かったようにも
思います。
ちょろりコーディング。
朝から休出。日が暮れた頃に帰着。
ちょろりコーディングしたりTV見たりしていたらあまりの眠さに急速停止。
遅めに帰着。
ちょろりコーディング。
早くも無く遅くも無く。
ちょろりコーディング。
遅めに帰着。
Web巡回して終了。
気持ち早めに帰着。
ちょろり調べ事。
早くも無く遅くも無く。
ちょろりコーディング。
AM中に起床。
Webで調べ事をしていたら、X68kの スターウォーズのオープニング等のデモ
シーンと映画の比較動画というのを知ったり
(こちら)。
当時、「良くできてるなぁ」とは思っていたのですが、まさかここまで
ぴったり合わせてあるとは思いもよりませんでした。今更ですが改めて
スゲーと思いました。因みに映画の方はいわゆるリメイク版の映像なので、
最後のデススターの爆発シーンはリメイク前の映像ならばむしろそっくり
かも知れません。
宮崎駿監督引退のニュース速報が流れてたり。