早めに帰着。
最後のhomeで久しぶりなフレンドと夜更かし。
気持ち早めに帰着。
Emacs突然死問題。スリープから復帰した時にうまく美人時計の画像に
アクセスできない状態にハマったのですが、ハング状態ではなかった為、
stop→startで復帰。死ぬ事にはならなかったり。
AM中に起床。
Emacs突然死問題。最終的に4つのEmacsで24時間美人時計を動かして、
どれも死ななかったり。convertを使わない方法は有効そう。
そんな訳で美人時計ELISPを
アップデートしてみました(Emacsでアクセサリを表示してみたくなった)。原因が判ってのワークアラウンド方法では無いのが
イマイチですが御参考まで。因みにshellが無いと使えませんので、
デフォルトは従来通りconvertを直接実行する方式に倒してあります。
掃除したり。
30時間くらいの所で4つのうち一つが死んだり。かなり落ちにくくは
なってますがやっぱダメか。そういや死ぬ時は
1 [sig] emacs-w32 15364 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 6, Win32 error 126
13539 [sig] emacs-w32 15364 proc_subproc: couldn't get proc lock. what 5, val 1
40006731 [sig] emacs-w32 15364 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,0), last 6, Win32 error 126
40007293 [sig] emacs-w32 15364 proc_subproc: couldn't get proc lock. what 5, val 0
80013609 [sig] emacs-w32 15364 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 6, Win32 error 126
80014698 [sig] emacs-w32 15364 proc_subproc: couldn't get proc lock. what 5, val 1
120018509 [sig] emacs-w32 15364 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 6, Win32 error 6
120036922 [sig] emacs-w32 15364 proc_subproc: couldn't get proc lock. what 5, val 1
AM中に起床。
Emacs突然死問題。昨日から今朝にかけて3つのEmacsで色々な方法の
画像リサイズをテストしていたのですが、どれも死んでませんでした。
もう少し試してみる事に。
因みに、150320版から、サポートしている組み込み画像表示機能を検査して
PNG,JPEG,GIFを切り替えるようにしたのですが、convertコマンドを使わない
とまぁまぁ面倒臭い感じだったり(^^;
因みに、PNGで表示する理由は減色を防ぐ為。Emacsの組み込みJPEG表示は
ハードコーディングで減色がONになっているからです(TANEは書き換えて
外していますが(^^;)。
netpbmはコマンドによって標準エラー出力に
メッセージを出力する場合があるのですが、それが悪さをして画像として
認識されない場合があるようです。この為、例えばGIFに変換するのに、
「djpeg -ppm | pnm scale -xysize %d %d | pnmquant -q 256 | ppmtogif」だとうまくいか
なかったので、
「 djpeg -ppm | pnm scale -xysize %d %d | cjpeg -quality 100 | djpeg -gif」
みたいな感じにしたりとか(^^;
散髪に出かけたり。日が暮れてからの予約しか取れなかったので遅くなったり。
Emacs突然死問題。4つのEmacsで12時間ほどconvertコマンドを使わない
方法で美人時計を動かしていたのですが死なず。ワークアラウンドの方法として
なんとか使えるか？という感じ。明日まで様子見。
MinGW-GDCのビルド。venixさんのパッチを手動で当てたのでそれが間違って
いないか確認したり。そういえば、ビルドはスクリプトが用意されている
のですが、それを見るとbinutilsは2.25を使用していて、binutilsの
mingw-tlsパッチは使用していなかったり。そういや
以前、CygwinでMinGWクロスコンパイルを
一番最初に行った際、binutilsは出来合いのものを使用して全く動かなかった
ので、binutils-2.23.1とtlsパッチを使ってビルドし直したらうまくいった
事があったのですが、この辺何か関係あるか？
遅めに帰着。
Emacs突然死問題。いくつかのEmacsを起動してテストしているのですが、
2日間死ななかったものと、数時間で死ぬものとがあり、もう何がトリガに
なっているのやらという感じ。
shellを介して画像のリサイズをする機能を少し拡張してconvertコマンド
以外の方法でリサイズする為の仕組みを入れてみたり。そんな訳で、
djpeg,pnmscale,pnmtopng を繋いでリサイズした場合のテストを加えてみたり。
これで死ぬなら子プロセス実行がトリガになっている事は間違い無いと
思われます。死ななければ convertコマンドの問題か、ツボが外れてて
大丈夫なだけかという可能性が考えられますが、苦肉のワークアラウンド
として使う事になるかも。
気持ち早めに帰着。
Emacs突然死問題。shを経由しても死ぬ時は死ぬようなのですが、
死ににくくはなっているような気も。もう少し様子見。
pixzというのを知ったり。
xzのマルチスレッド版です。これで-9を指定しても安心....と思いきや、
並列数を増やしたなりにメモリを必要とする為、32bitだと-9指定は
厳しいようです。あと、オリジナルのxzの-9と pixzの-9とでは、
pixzの方が圧縮後のファイルサイズが若干(2% ほど)大きくなるようです。
個人的な意見を言うと、部分取り出しを行わないソースアーカイブの
生成は tar.xzが手軽ではありますが、バックアップ目的でアーカイブ
するなら、部分取り出しのし易さを考えると7zの方が良いかな？とは
思います。
早めに帰着。
DMDの2.067.0がリリースされているもよう。GDCに来るのは当面先か。
その前にgcc-5.0が来るかも？
Emacs突然死問題。shを噛ますコードを少し整理したり。一晩耐えたのですが、
テスト時間が少ないのでもうしばらく放置。
そういや本日でへっぽこページは15周年を迎えました。
毎度見てくださっている方々に感謝いたします。
これからもよろしくお願い致しますm(_'_)m
気持ち早めに帰着。
Emacs突然死問題。昨日ロックを追加したコードでもSegfaultで死んだので、
競合とかはあまり問題ではなかった模様。そんな訳で、convertコマンドを
実行するにあたってshを経由するようにしたらどうか？と試してみたり。
しばらくほったらかし。
MinGW-gdcのビルド。コンパイルエラーで止まっていたのでソースを
直しながら進めたり。コンパイル自体は通ったり。make installして
テストコードをコンパイルすると、やっぱりいくつかパッチが足りなくて追加。
で、コンパイルできるようになりましたが、例のsegfaultするコードは
やっぱりそのまま。うむぅ。
気持ち早めに帰着。
Emacs突然死問題。そういや美人時計の非同期処理にdeferredを使用していますが、
一つのシーケンスが終了する前に次のシーケンスを投入したらどうなるんだろう？
と思ったり。例えば、毎秒 分単位の時間をチェックして、違っていたら
新しい画像を取得＆表示するという処理を行っていますが、画像の取得が終わる
までは分単位の時間は記録せず、画像取得処理を突き放していました。
もし何かしらの理由で画像取得＆表示に1秒以上の時間を費やすと、例え処理が
遅れているだけであっても、もう一度画像取得を行うようなコードになってます。
ここで二つの画像取得＆表示プロセスが同時に動くと、データ領域の更新や参照が
競合するのでは？と思ったり。そんな訳でセマフォを使ってロックを取ってから
非同期データ取得を実行するようにし、ロック中に次のデータ取得が行われた
場合はそのデータ取得はキャンセルするというようにして様子を見てみる事に
したり。
ぶつかる事ってあるのかなぁ？と思ったのですが、実際に動かしてみると
稀にぶつかるケースがあるようです(既にロックが取られている場合にデバッグ
メッセージを表示するようにしてみてました)。でもまぁ、複数のEmacsが
道連れになるケースを説明できる訳ではありませんが、何かしら動きに違い
が出るかなぁ？と思う次第。
MinGW-gdcのビルドを試したり。そういやMinGWだとlnはコピーと同等の
振る舞いをするのですが、Cygwinでは一応シンボリックリンクの扱い
になります。gdcはsetupスクリプトを実行するとgccのソースディレクトリに
シンボリックリンクでDのコンパイラやlibphobosのソースディレクトリが
追加されます。ところが、パスやファイルがシンボリックリンクだと
git形式のパッチがうまく当たらなかったり。沢山パッチがあるのですが仕方なく
ひとつずつどんなパッチか見ながら手動で当てたり。幾つかは
これでいけるか？とか、これ無くて大丈夫か？と思いながら
ひとまず当ててみたり。ビルドに時間がかかるのでmake 実行後しばらく
ほったらかし。
AM中に起床。
掃除したり。
Emacs突然死問題。もしやこいつのせいだったのか？という心当たりを一点思いついたり。
普段全く使っていないcmigemoですが、これは野良ビルドして/usr/local/bin
に置いてありました。これがCygwinのrebase対象になっていないというのに気づいたり。
emacs本体はlddで調べて/usr/local/binとか/usr/local/lib
とかのdllをリンクしていないのを確認していたのですが、子プロセス実行される
cmigemoまで確認していませんでした。普段は全く使っていなくて、用事があれば
enableにするかもしれないくらいの設定を行っていたのですが、list-processで
見てみると子プロセス実行はされているようです。そういえば、タスクマネージャー
で見ていて、emacsを全て閉じているのに何故かcmigemoプロセスがそのまま残って
いるのも不思議に思っていたなぁという心当たりもあったり。
そんな訳で完全にcmigemoを使わないようにして試してみる事に。
ただ、すぐに死ぬとかでなく、時限爆弾式にダメになったりするのかなぁ？と
いう気もしますので、ハズしているかも。
マンデルブロ集合の拡大アニメーション。3年くらい前に知った動画では1.0e100
くらまでの拡大率だったのですが、最近ではもっと深い所までを高解像度で
レンダリングしている動画があるようです。
例えばこちらの
「Mandelbrot Deep Zoom 10^4004 [2560x1440]」
はタイトル通り1.0e4004まで拡大したものが高解像度動画で公開
されています。1.0e3900以降少し変化が少なくなってくるのですが、
その到達先に初期模様が出てくるというのにはマジかと思いました。
それにしても、コメントにレンダリングに70時間かかった
(色々問題があって実働7日) と書いているように読めたのですが、
アニメーション枚数を考えると、70時間ではこれだけの解像度と深度で
レンダリングするのは無理じゃなかろうか？
とも思ったのですがどうなんだろう。
昼の再放送でやってたマツコの知らない世界。100万円のマグロ1本
(180cm/100kgくらい)から作れた握り寿司は(1つを1貫と数える方式で)
3050貫でした。1貫あたり平均327円(米代、握り手間代無し)。
平均でこれなので、希少部位が高いのもうなずけます。
Emacs突然死問題。cmigemoを完全に排除してもやっぱりsegfaultしました。
1 [sig] emacs-24.4.1 7844 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 6, Win32 error 0
728 [sig] emacs-24.4.1 7844 proc_subproc: couldn't get proc lock. what 5, val 1
40000116 [sig] emacs-24.4.1 7844 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,0), last 6, Win32 error 0
40000739 [sig] emacs-24.4.1 7844 proc_subproc: couldn't get proc lock. what 5, val 0
80000292 [sig] emacs-24.4.1 7844 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 6, Win32 error 0
80000622 [sig] emacs-24.4.1 7844 proc_subproc: couldn't get proc lock. what 5, val 1
120001628 [sig] emacs-24.4.1 7844 get_proc_lock: Couldn't acquire sync_proc_subproc for(5,1), last 6, Win32 error 6
120002236 [sig] emacs-24.4.1 7844 proc_subproc: couldn't get proc lock. what 5, val 1
AM中に起床。
Emacs突然死問題。結局、リサイズしないバージョンだと24時間以上死なず。
64bitではリサイズありバージョンでも12時間以上動かして死なず。
Fedoraで動かしても死なず。という事から、32bit-CygwinのEmacsで
リサイズ(convertコマンド実行)有りで動かした場合に変になると特定
してみたり。原因までは判らず。
まだEmacs突然死問題の原因は判っていませんが美人時計elispをひっそりと更新。
ご参考まで
(Emacsでアクセサリを表示してみたくなった)。
PS-Storeでたまたま見た「ピクセル」という映画の予告映像
(参考)。
RESOGUN
とか3Dドットゲームヒーローズ
を彷彿させます。
遅めに帰着。
Emacs突然死問題。リサイズを行わないバージョンの美人時計を
日中動かし続けたのですが、死なずに動いている模様。
もう少し様子見するとして、子プロセス実行に問題があるとすると、
Cygwinの何かを踏んでいると考えられます。
Cygwinで何か起こったと仮定すれば、複数のEmacsが道連れで変に
なるのも説明が付くように思います。
遅めに帰着。
Emacs突然死問題。美人時計(debug)の方だけでも死んだりハングしたり。
子プロセス実行に原因がありそうな予感。そんな訳で、画像のリサイズを
行わないとどうなるか見てみる事に。
そういやLinuxだとどうだろうと思い、Fedoraで動かしてみたのですが
何故か画像が表示されず。原因はdeferredのdeferred:url-retrieveという
関数を使う際は(require 'url)する必要があるのが抜けていた為。
Emacs-w32では勝手に読み込まれていたようで気づきませんでした。
美人時計をウインドウリサイズ追従対応してみたり。
早めに帰着。
Emacs突然死問題。朝は動いていたのですが、帰ってみたら死んでたり。
美人時計(本物）を動かしていたEmacsはSegfaultしてcoreダンプしてて、
22GBのファイルが出来上がってました。一応 gdbに食わせてみたのですが、
やっぱりサイズが正しくないっぽい。結局スタックは残っていなくて、
どこでずっこけたのかは判らず。
デバッグの為に作った、ローカルファイルを表示し続けるコードは
何故か釣られてハング状態だったり。結局5つのEmacsを起動していたの
ですが、
Emacs1(-O0) → 適当なファイルを開いていただけ。死なず。 Emacs2(-O2) → 美人時計(本物)起動。Segfaultでcoredump。 Emacs3(-O2) → 美人時計(本物)起動。Segfaultでcoredump。 Emacs4(-O0) → 美人時計(debug)起動。釣られてハング？ Emacs5(-O0) → 美人時計(debug)起動。死なず。
遅めに帰着。
Emacs突然死問題。昨日の夜、二つのEmacsを起動してほったらかしていたら
死んだのですが、片方が美人時計サイトへのアクセスをリトライで繰り返し
続けていたり。アクセスを繰り返す原因は、恐らく画像のリサイズの為の
ImageMagickのconvertコマンド実行に失敗しているんじゃないかと推測。
子プロセス実行に失敗しているのだとすれば、ローカルファイルを似た感じ
で表示すれば再現するのでは？と思い、最小限の書き換えでローカルファイル
の連続表示を行うようにしてみたり。という訳でテストに投入。
遅めに帰着。
Emacs突然死問題。ずっと起動していたけど死なず。
そのまま別の事をやってたらSegfaultしたり！でcoreダンプが
吐き出され始めたのですが、20GB以上のファイルを吐き出していた
ので、んな訳無いだろと思い dumperをkill。結局調べられず。
昼頃起床。
Emacs突然死問題。-O0バイナリを25時間動かすも死なず。うーむ。
一度WindowsUpdateを入れてから、昨日知ったcoreダンプ設定をして再度
32bit-自前パッチ(-O0)と32bit-rzl24oziパッチ(-O2)をで美人時計を
動かしてほったらかしに。
どれか一つが死ぬと他が釣られて死ぬという現象から、何か原因に繋がる
点って無いのかしら？と思ったのですが、心当たりは特に無く。
TVの録画機器を選択していたら、いつの間にかDLNA機器を選択できるように
なっているのに気づいたり。今まで観られないと思っていたのに(^^;
でも4k動画ファイルは観られませんでした。
Emacs突然死問題。全く死ぬ気配が無いので仕切りなおし。
普段使いを-O0に入れ替え。性能的なものを一応見とく感じ。
で、-O2で再ビルドしたバイナリをテストに投入する事に。これで再現しないと
もうよく判らん(^^;
そういやELISPで、CL(CommonLisp)パッケージってを使えば defstructって
関数を使えるようになって構造体を定義できるらしい。
ちょっと使ってみたのですが、メンバー変数へのアクセスなどは、
なんか記述量が多くて面倒臭いなぁ？と思ったりも。スクラッチバッファで
試した結果。
;; x,y,zをメンバー変数とするpoint_stという構造体を定義する
(defstruct point_st x y z) ;C-j
point_st
;; 二つのpoint_stの構造体変数をリストにしたplistを生成
(setf plist (list (make-point_st :x 100 :y 200 :z 300)
(make-point_st :x 400 :y 500 :z 600))) ;C-j
([cl-struct-point_st 100 200 300] [cl-struct-point_st 400 500 600])
(print plist) ;C-j
([cl-struct-point_st 100 200 300] [cl-struct-point_st 400 500 600])
([cl-struct-point_st 100 200 300] [cl-struct-point_st 400 500 600])
;; plistの最初の構造体変数のメンバー変数xを 100→700に変更
(setf (point_st-x (nth 0 plist)) 700) ;C-j
700
(print plist) ;C-j
([cl-struct-point_st 700 200 300] [cl-struct-point_st 400 500 600])
([cl-struct-point_st 700 200 300] [cl-struct-point_st 400 500 600])
1 (require 'cl)
2
3 (defstruct point_st x y z)
4
5 (defun testprint ()
6 (let ((plist (list (make-point_st :x 100 :y 200 :z 300)
7 (make-point_st :x 400 :y 500 :z 600)))
8 (aaa)
9 )
10 (setf (point_st-x aaa) 100) ; aaaは 構造体ではない
11 (setf (point_st-x (nth 0 plist)) 700)
12 plist
13 ))
AM中に起床。
Emacs突然死問題。コンパイルのオプティマイズレベルを-Oに下げたものでも
再現してました。
コンパイルオプティマイズレベルを-O0で試してみる事に。これで死ねば
gdbに乗せても死ぬんじゃないかなぁ？と思うのですが.....
因みに、突然死のトリガになっていそうなのは今の所 美人時計のみのようです。
emnekoは2日以上動かしていても死にません。
今更ですが、Cygwinでstackdumpではなく本物のcoreをダンプする方法があるのを
初めて知ったり(^^; 「export CYGWIN="$CYGWIN error_start=dumper -d %1 %2"」てな
感じでCYGWINという環境変数を設定すれば良いようです。
$ cat -n coretest.c
1 #include <stdlib.h>
2 #include <stdio.h>
3
4 int main()
5 {
6 int *p ;
7
8 p=NULL ;
9 testfunc(p) ;
10 return ;
11 }
12
13 int testfunc(int *p)
14 {
15 printf("%d\n",p[0]) ;
16 return(0) ;
17 }
$ gcc -g coretest.c
$ ./a.exe
*** starting debugger for pid 13016, tid 8700 #ここで一瞬別窓が開くが気にしない
$ ls -ltr
合計 9837
-rw-r--r-- 1 TANE None 181 3月 14 12:24 coretest.c
-rwxr-xr-x 1 TANE None 61808 3月 14 12:26 a.exe
-rw-r--r-- 1 TANE None 10003548 3月 14 12:26 a.exe.core
$ gdb -q -c a.exe.core a.exe
Reading symbols from a.exe...done.
warning: core file may not match specified executable file. #若干気にはなりますが....
[New Thread 0x1]
[New process 1]
[New process 1]
#0 0x004011ce in testfunc (p=0x0) at coretest.c:15
15 printf("%d\n",p[0]) ;
(gdb) where
#0 0x004011ce in testfunc (p=0x0) at coretest.c:15
#1 0x004011c2 in main () at coretest.c:9
(gdb) p p
$1 = (int *) 0x0
(gdb)
早くも無く遅くも無く。
Emacs突然死問題。gdb上で起動したら23時間ほどほったらかしに
したのですが再現せず。やはりそうなるか。何かしらバグっている
可能性があるのですが、Cygwinのアップデートと同じくgccのアップデート
とかも入れたのでどれも怪しい気がしてきます(^^;
コンパイルのオプティマイズを-O2から-Oに下げて試してみたり。
ジブリのかぐや姫。公開前の予告CMでは、オリジナルのかぐや姫
とは違う点があるかのような感じだったのですが、そういう訳では
なかったもよう。
あまりの眠さに急速停止。
遅めに帰着。
D-busを抜いてビルドしたEmacsでもSegfaultが再現したり。D-busは関係無い
ものと思われ。美人時計だけを起動してほったらかしにしておくと、1時間ほど
でSegfaultしていたため、美人時計がトリガの一端にあるのは間違い無さそう。
そんな訳でgdbに食わせて
起動(美人時計,スクラッチバッファ,メッセージバッファのみ)＆ほったらかし
にしてみる事に。
ただ、Emacs-w32をgdbにかけるとgdbの反応がイマイチになるというか、
むしろgdbに食わせたせいで動きが変になる事もある為、うまく
死ぬ瞬間を捕らえられるかは不明。
2時間ほど置いたまま、Web巡回などをしてても再現せず。
本当に何もしないと落ちるのか？
早くも無く遅くも無く。
昨日の夜、32bit-自前パッチ、32bit-rzl24oziパッチ、64bit-rzl24oziパッチ、
の三種類のEmacsを立ち上げたままにしていたのですが、何故かほぼ同時刻に
全てのEmacsがSegfaultで落ちていたり。何故！？
いくつか怪しいと考えられる候補を挙げて順に見ていく事に。
怪しいのは「美人時計」と「D-bus」。美人時計の方はそれ自体というよりも、
Webアクセスしたり画像のサイズ変更の為にプロセス実行したりしている点で、
何かを引き当てているのではないかと考えています。D-busの方ですが、
時々、get_proc_lockが云々でWin32 errorとかメッセージが出るときがありました。
D-busが関係しているケースがあったりもしたようなので、外してビルドしてみる
事に。因みに64bitの方にはライブラリを入れてなかったのでD-busは含まれて
いませんでした。そんな訳で条件を変えながらしばらく観察してみることに。
遅めに帰着。
Emacsを起動したまま放置すると突然死する件。トリガはまだよく分かりませんが、
数時間で死んでしまう模様。何がトリガになっているのか調べる必要がありそう。
Cygwinをアップデートしてから死ぬようになったので、Cygwinに原因があると
言いたい所ですが、パッチ(因みにIMEパッチは自前のもの)などがバグってて
今までたまたま死ななかっただけという可能性もあるのでなんとも。
ところで IMEパッチと言えば、巷では
話は戻って、今の所ほったらかしで死ぬ状況は以下のような感じ。
┌───────┬───┬───┐
│ │ 32bit│ 64bit│
├───────┼───┼───┤
│自前パッチ │ × │ 無 │
├───────┼───┼───┤
│rzl24oziパッチ│未検証│ ○ │
└───────┴───┴───┘
rzl24oziパッチでも落ちるようなら、Emacsだけは64bitへ移行する事を
考えようかと思ったりも。
Emacs上で「sort | uniq」する方法。最近知ったのですが、すぐに忘れて
しまうので覚書き。
undoも使えるので良いです。テキストを囲まずに、適当な位置をマークするだけ
にして、入力を必要としないコマンド(例えばlsとか)を実行すると、
マーク位置にコマンドの標準出力結果が挿入されます。
遅めに帰着。
調べ事をして終了。
昼前起床。
掃除したり。
termとIMEの相性の件。なんとなく原因が判ったり。
結論から言うとIMEパッチの構造上の問題だと思われます。
まず、以下のような状態から始めたとします。
ウインドウを分割して*scratch*とterm+を同時表示。このときどちらのウインドウもIMEはOFFの状態 ┌─────────────┐ │ │ │ │ │ │ ├─────────────┤ │[--] *scratch* │ ├─────────────┤ │ │ │ │ │ │ ├─────────────┤ │[--] term+ │ └─────────────┘
┌─────────────┐ │ │ │ │ │ │ ├─────────────┤ │[あ] *scratch* │ ├─────────────┤ │topコマンドで画面書き換え │ │ │ │ │ ├─────────────┤ │[--] term+ │ └─────────────┘
(defun w32-ime-sync-state (window)
(if w32-ime-buffer-switch-p
(progn
(with-current-buffer (window-buffer window)
(let* ((frame (window-frame window))
(ime-state (ime-get-mode)))
(cond
((and (not ime-state)
(equal current-input-method "W32-IME"))
(ime-force-on nil)
(run-hooks 'w32-ime-on-hook))
((and ime-state
(not (equal current-input-method "W32-IME")))
(ime-force-off nil)
(run-hooks 'w32-ime-off-hook))))))
(progn
(dolist (win (window-list))
(with-current-buffer (window-buffer win)
(w32-ime-mode-line-update))))
))
AM中に起床。
青黒白金ドレスの話。環境光をどう設定するかでどちらの色とも
解釈できると言ってましたが、画像のピクセル色が何色か？
という観点だけで見ると「青とカーキ」と答えた松嶋尚美が
正解だと思ったりも。
termとIMEの相性の件を少し調べてみたり。
実際の動きを観察する感じ、IME自体はフレームフォーカスを
失っても復帰可能なようです。例えば、確定せずにEmacsからIEとか他の
アプリに一時的に切り替えて、再びEmacsに戻せば確定されてない
ままになってます。また、拙作のemnekoやwireフレーム描画のような
リアルタイムにEmacs内の別ウインドウ描画を行うアプリを動かしても
再描画の度に変換確定する事はありません。この部分が先日
「termの作りの問題か？」と述べた部分にかかります。
term+はtermの上に乗っかっているようだったので、まずはtermを調べてみる事に。
term.elのterm-emulate-terminalという関数を調べてみたり。
どうやらselect-windowという関数を途中で実行しているのですが、
そこをひとまずコメントアウトしてみると、別ウインドウでのIME入力が
勝手に変換確定されなくなりました。で、term+もそれでいけるか？と思ったら
そっちはそっちでやっぱりダメ。でも、term+内のコードには
term.elのように select-windowを実行している箇所が無かったので、
term+特有の要素があるのかも。
調べてみるもよく分からず。select-windowが作用しているのは事実
なのですが、他にもwindow切り替え関数でIMEを確定してしまうケースが
ありそう。でも、単にselect-windowを削ってしまうだけでは副作用が
あってダメです。と考えると、IMEパッチの問題という事になるかも
知れません.....
IMEパッチ使わないとダメか？ 今ならIMEパッチは無くても、
変換するだけならAnthyとかで全然大丈夫だとは思います。
しかし、Meadowで慣れてしまったというのもあるのですが、それ以上にMS-IMEだと
変換時に簡単な国語辞典が表示される点を便利に使っているのかな
と思います(「越える」と「超える」どっちだっけとか
「計る」と「測る」と「量る」どれだっけみたいな)。
IME制御に網をかけて動きを観察してみたり。IMEを起動して文字を
入力すると、入力の度にWM_IME_COMPOSITIONというウインドウメッセージが
送られてきます。このとき、「lParam & GCS_RESULTSTR」が0じゃなければ
確定されたという事になるようですが、term+の画面更新時に別ウインドウ
で変換中にGCS_RESULTSTRが送られているようです。
キー操作していないにも関わらず、何故 GCS_RESULTSTRが送られてくるのか
判らず。
ウインドウメッセージの順番を調べたいと思ったのですが、
WM_IME_STARTCOMPOSITIONとかはどうやら常に流れているようで、
なんだか難しすぎです。WM_IME_COMPOSITION+GCS_RESULTSTR が
キー操作以外で送られてくる契機を知りたい訳ですが、
Web検索しても見つけられず。
尻尾の端を掴んだような。WM_IME_COMPOSITION+GCS_RESULTSTRが
送られてくる前にユーザーメッセージのWM_MULE_IMM_SET_STATUSが
流れてきてて、このメッセージを受けた時は問答無用でIMEのステータス
を変更しているようです。まだ確定していない状態でも、
ステータスを変更した時にWM_IME_COMPOSITION+GCS_RESULTSTRが
流れてくるようです。次はWM_MULE_IMM_SET_STATUSを流しているのは誰だ？
という所。
遅めに帰着。ずぶ濡れ。
寒さと眠さで急速停止。
遅めに帰着。
そういやCygwinでビルドした IMEパッチ入りのEmacs-W32で、
term+で起動したシェル上で リアルタイムに画面更新を行うような
topコマンドを実行したまま、別のウインドウでIMEによる
日本語入力を行うと入力文字落ちが発生します。正確には
term+ウインドウに描画更新が入ると、別ウインドウで入力中の
IMEが入力確定してしまう(例えば「あ」と入れて確定せずに
(波下線が表示されたまま)ほっとくと勝手に確定します)為、
続けて入力していると文字落ちしているかの様に見えるという
感じです。
Anthyで入力している時にはそういう事は起こりませんので、
IMEパッチの問題か？とも思ったのですが、term(term+ではない)の
作りの問題という気もしなくはありません。
そんな感じなので、時間のかかるmakeを画面を出しっぱなしの
まま、他の編集作業を行えません。仕方なくtermウインドウは
閉じたまま、他の作業を行うのですが、終わったかどうかを
ポーリングしなくてはならず地味に不便です。
気持ち早めに帰着。
CygwinのパッケージインストールでEmacsもアップデートされていたので、
野良ビルド版に入れ替え。
そういえば、
round関数がrange errorする件
(参考)は結局原因に辿り着けないままで、
今回アップデートしたcygwin1.dllでも再現します。
エラーすると色々止まるので、少し前から非数を検出したら0を返すように
対応してます。非数の反応が変わるのですが、非数になる事を期待する
ケースは稀だろうという事で、まぁ問題にはならないかな？と思ってます。
本当はどこかでデータが化けてるのだと思われるので、原因がはっきり
した方が良いのですが。
ちょろっとorg-modeのテストをしてたら、gnuplotのコードブロック
でgnuplotが見つからんと怒られたり。/usr/share/emacs/site-lisp/の下に
あった筈のgnuplot.elが無くなっていたためエラーになった模様。
site-lispのコピーを取ってあったのでそこから発掘して復帰。
何故無くなったのかは不明。
gnuplotで生成したグラフ画像の色味が変わった気がするなぁ？と思ったら
どうやらバージョンが5.0になった為のようです。
遅めに帰着。
Cygwinのパッケージインストールを始めた所、大量に更新されている為か
ちっとも終わらず。
遅めに帰着。
美人時計00:00画像取得問題。先日はリトライ回数が記録できてなかったので、
今日も確認。12回くらいリトライすれば取得できたという感じ。
取得可能になるまで数秒を要する模様。本当はサイトの方で気づいてくれると
良いのですが、ひとまずはこれで。
AM中に起床。
掃除したり。
ここ数週間、Emacsに関してあれこれやった事のまとめ文書を
「Emacsでアクセサリを表示してみたくなった」
に置いてみました。御参考まで。
美人時計00:00画像取得問題。リトライ10回では不足で、100回以内には
なんとか取得できるようでした。そんな訳で、
「Emacsでアクセサリを表示してみたくなった」
内のアーカイブを10回→99回にリトライ回数を増やした版にアップデートしました。
御参考まで。
それにしても、まさか美人時計でここまで遊ぶ事になるとは思いもよりませんでした(^^;