脳log[2010-06]

最終更新: 2011-01-02T16:45+0900

♪ [SakuraEditor] サクラエディタ。温故知新。

SAKURA Development BBS (ANSI)のログが 10ページ分しか閲覧できなくて、残念な思いをしていた。検索対象のリストに古い年月が存在していたり個別リンクが機能していたりするんだから、古いログが保存されているのは間違いないんだけど。Cyclamen(掲示板CGI)に関して言えば、記法のヘルプを見つけることもソースを見て記法を確認することもできない。ま、それはおいといて、

過去ログを見つけた。>http://groups.yahoo.co.jp/group/sakura-editor/files/User/bbs-log/

Subversionが最初からあった世代には考えられない開発スタイルがそこに！差分や変更したファイルを共有エリアに置いて掲示板で報告。大きな変更をした人が他の人の小さな変更をマージして最新版を管理したり。ともあれ、お宝ざくざくなので日曜日から喜々として読み進めている次第。(ログが 2007年9月で切れてるのが残念)

S:27,*,01/02/11,10:49,,
T:横スクロール時の動作
N:げんた
M:
現在のこのエディタはWM_HSCROLLが来たら横スクロール量を決定して画面全体を書き直す動作を行います。もし、画面全体を書き直す代わりに新規部分のみを書き直せば高速化すると思われるかも知れませんがそうはいきません。

なぜなら、このエディタは色分け情報をメモリ上に保持していないため、描画の都度行の先頭から調べて色を決定しているからです。その際キーワードの検索も行います。たぶん、これがかなりの処理を必要としているのだと思います。

横スクロール速度を劇的に改善しようと思ったら色分けを予め行ってその情報をメモリに保持するようにしないと難しいのではないでしょうか。

gdippを使っていると無視できないほどに強調されるので横スクロールが遅いことには気付いていた。これが書かれた当時のサクラエディタ(という名前ではまだないが)の遅さは今の PCスペックでは再現できないかもしれないけど、根は昔から存在していたよう。

S:114,*,01/03/02, 2:32,,
T:コントロールプロセスの起動方法
N:げんた
E:genta@i.am
M:
外部エディタを監視するプログラムからテキストエディタを使うとき、エディタが常駐していないと起動したプロセスは管理プロセスとなってエディタ画面は別プロセスで動作するため、編集終了の検出が正しく行えない場合があります。

自分が管理プロセスになるのではなく管理プロセスを別に起動して起動完了まで待機するような作りにできればこの問題が解決できるなぁと思いました。

タブモード(実装者は別の人)であっても 1ドキュメント 1プロセスだから Subversionのコミットメッセージをサクラエディタで編集できるんだけど、そもそもこういうことが考慮されていたからこそできるのだと確認。

S:1446,1440,02/02/01,22:27,,
T:Re2:正規表現置換の振舞い
N:げんた
M:
>..*\n$ でやってみたら削除できましたけど…？？？
よく見たら自分で何気なく変えたところだった．
本当に申し訳ない．
今は普通に動いています．

ただ，BREGEXPのせいなのか，^.*$ には先頭から改行コード \r\n の\rの部分までがヒットして\nが残ります．
^.*\n$ だと行全体にヒット．

「改行(.と$の動作に影響する)」= LF(0x0A)の指摘がこのとき既に。セルフリンク>20090922p01

S:1475,1474,02/02/05, 0:47,,
T:Re4: タイプ別設定に外部ヘルプと外部HTMLヘルプ新設パッチ
N:げんた
M:
ちょっと考え直してみました．

▼初期の私のアイディア
・CShareDataの役割＝単にDLL Sharedを得るためのクラス．

・タイプ別設定を共有メモリから追い出す．
そのために，タイプ別設定のアクセスをCEditDoc::GetDocumentAttributeに集約．
追い出した後の実装はCEditDoc，またはCEditDocに含まれる新規クラスで行うつもりだった．

共有メモリからタイプ別設定を追い出したい理由は以下の通り．
* タイプ別設定が足りなくなり，既に2回最大値を拡張している．
* タイプ別設定の領域を予め共有メモリに確保しなくてはならないので，上限の撤廃ができない．
* 初回起動時に使うかわからない領域全てを初期化するのは無駄ではないか．

追い出しのアイディア
* タイプ別設定はそれぞれ外部ファイルに用意する．
* 設定ファイルは必要に応じて読み込まれる．
* 変更は現状通りダイアログボックスで行う．
* 変更されたらすぐにファイルに保存し，設定変更Broadcastメッセージを投げる．
* Broadcastを受け取ったら該当タイプを使用しているか確認．
* 使用していたらファイルから再読込し，設定を更新する．

>各種設定が共通設定だろうが、タイプ別設定だろうが、気にせずとりあえずCSettingMediatorに問い合わせたり、設定を依頼するだけでよくなったら便利だなぁと思っています。
なるほど．これは良いと思います．最終的には設定情報がどこに格納されているのかも意識する必要が無くなるので，これは私のアイディアと矛盾しません．CEditDoc::GetDocumentAttributeで取得するのをDLLSHAREからCSettingMediator経由に変更すればタイプ別設定のカプセル化の場所が移動します．

私の初期アイディアと組み合わせると，追い出した後の実装というのをCSettingMediatorに依頼することになるでしょう．タイプ一覧の設定，指定タイプの取得，更新などファイルへの書き出し・読み込みタイミングもCSettingMediatorが管理すれば良いような気がします．

上記内容を納得した上で私が確認した限りでは特に問題はないように思います．

---
実装に入る前に設計に対する議論を行うことは有意義だと思います．これまでは議論する相手がいなかったので...(;_;)

タイプ別設定を共有メモリから追い出すアイディアが既に出ていた。

設定の場所を隠蔽するクラスも構想されている。それのメリットとして自分が考えているのは、

1. 実行ファイルに埋め込まれたデフォルトのタイプ別設定
2. 基本設定
3. 拡張子に応じたタイプ別設定

の 3を、2との差分とすることで基本的な設定の共通化(基本設定による)を図りつつ、設定の読み出しを一本化できること。

S:1606,*,02/02/16, 2:26,,
T:ssrc_2002-02-11_p1
N:hor
M:
ssrc_2002-02-11 からの変更箇所です。ご参考まで。
(省略)
□その他のその他
    ・[Ctrl+Home]or[Ctrl+End]後に[Down]or[Up]したときの挙動を見直し・・・以下変更個所
       １.矩形選択中に[Ctrl+Home]or[Ctrl+End]して[Down]or[Up]したとき以外は普通にカーソル移動
       ２.選択を解除したあとは普通にカーソル移動
(省略)

ファイルの先頭へ移動するコマンド(Ctrl+Home)が「通常は、(0, 0)へ移動。ボックス選択中は、(GetCaret().GetCaretLayoutPos().GetX2(), 0)へ移動」というコメント付きで故意におかしな動作をするのはこのへんが理由だったのか。(細かいことを言うと、このときの実装は Ctrl+Homeで 0行0桁に移動した後、↓で 1行(Ctrl+Home前の)X桁に移動する、というもので、いまの実装はすこし後にでてくる)。ファイルの先頭に移動という一つの名前に異なる機能を実装するのはやめて欲しい。利用者視点の「使える」動作なんだろうけど、自分なら Alt+Ctrl+Homeを「(矩形選択)ファイルの先頭行に移動(※未実装)」に割り当てるなどして対処する。

S:1759,*,02/03/23,11:01,,
T:バックアップごみ箱問題
N:みく
M:
ネットワークドライブまたはリムーバブルドライブのファイルを
ごみ箱に放り込むとOSの仕様により消滅してしまいます。
バックアップしたつもりがされてないという現象を避けるため、
これらのドライブの場合はごみ箱に放り込まないようにしました。

次回版にでも取り込んでください。


どうしてもごみ箱に放り込みたい場合は、
「指定のフォルダに作成する」でフォルダにローカルドライブのフォルダを
指定し、さらに「バックアップをごみ箱に放り込む」を指定してください。
（指定のフォルダにごみ箱を直接指定することはできません）

最近見かけたリムーバブルメディア上のファイルのバックアップをゴミ箱に放り込めない問題が 2002年に指摘されている。

自分はバックアップは Ctrl+Sに割り当てた JScriptマクロで Subversionに保存してる。差分バックアップでありながら過去の版を ViewVCで簡単に見られるのが利点。マクロでやってることのエッセンスは以下の通り。

>Editor.FileSave();
>svn up "working copy"
>copy /Y /B "filepath" "working copy/filename" );
>svn add "working copy/filename"
>svn commit "working copy/filename" -m "filepath" --force-log --non-interactive'

たかだかテキストファイルなので動画より小さく、ワーキングコピーもリポジトリも数百MiBにおさまってる。NTFSの圧縮属性を付けたらさらに三分の一にもなるし。

S:1980,*,02/04/30, 1:41,,
T:半角スペース表示
N:KK
M:
KKです。
一般掲示板の方で要望のあった
「半角スペースの表示を追加する」
パッチを書いてみました。04-27版へのパッチです。
DispSpc04-27.zip
(省略)

S:1982,1980,02/04/30, 2:12,,
T:Re:半角スペース表示
N:げんた
M:
小文字のoの下半分だけを使うという発想が何とも独創的 (^^)

いまの Unicode版も同じ実装。気付かなかった (^^) ちなみに、デフォルトの色は灰色だけど、これをテキストと同じ色にすると周りと同じ色で描画されます(コメント中の空白とかが)。

空白記号類は特に明示指定した部分以外はなるべく周辺の指定に合わせるようにしてみた // 2009.05.30 ryoji

ソースを見てないと気づかなかった。

S:2237,*,02/07/03,12:22,,
T:クラス、インターフェイスの整理
N:ボロぞうきん
M:
(省略)
1&2 1行の文字数が3万文字を超えてくると極端に遅くなるので、
行バッファを簡易gapped buffer方式に変更したかったけど、
内部のポインタを書き換え目的に使っている場所があり、
単純にconst化出来なかった。
(省略)

でました。gapped buffer

S:2278,*,02/08/23,20:29,,
T:正規表現ライブラリ
N:みく
M:
比較的新しそうな正規表現ライブラリとして、
こんなのもあるみたいです。

http://www.fides.dti.ne.jp/~oka-t/libraries.html

S:2959,*,03/07/21, 3:35,,
T:正規表現ライブラリの不具合
N:げんた
M:
http://www.fides.dti.ne.jp/~oka-t/history-2001.html
でPerlの正規表現の不具合について触れられていた．

試してみると確かに
::1234::5678901234567890::::1234567890::
888:
に対して
^([0-9]+|::)*$
で検索するとフリーズする．（よい子は真似をしないでください）

Perl 5.8ではフリーズしなかった．

リンク先が同じ。なんちゃってではなく真っ当な雰囲気がするなあ、と思いながらそのサイトをうろうろしていたら、未訪問のはずのリンクが何カ所も閲覧済みの色になっていることに気付いた。良いものは埋もれてしまわないのだ(忘れられるのは読み手(俺)の問題)。

S:2562,2559,03/02/11, 1:19,,
T:Re: マルチユーザモード（案）
N:もか
M:
▼ みくさん
>実行ファイル名を sakuram.exe とかに改名するとマルチユーザモードになり、
実行ファイル名を 任意の文字列1.exe などにすると文字コードがその数字の文字コード(この場合EUC-JPに)固定されるという機能があるから
(省略)

なんぞそれ>「実行ファイル名を 任意の文字列1.exe などにすると」

S:3140,*,03/09/15,11:53,,
T:色分けHTML出力
N:wmlhq
M:
強調キーワードなどを使って色分けしたソースコードをsakuraでもHTML/XMLで出力できたら、便利だろうな。「形式を指定してコピー(special copy)」で実装するとか。

<font size=10><pre>//<nobr>comment</nobr>
<font color="#576447">int</font> func();
</pre></font>

これは面白そう。もちろんフォーマットは

<style>
/*<![CDATA[*/
  .comment { color: green; background-color: white; font-style: oblique; }
/*]]>*/
</style>
<span class="comment">//コメント</span>

にするけど。HTML直打ちに近いブログに投稿する以外に、正規表現キーワードによる色分けのデバッグにも使える。(思い通りの結果にならないときに、見た目では判断できない違いが classによって区別できる)

それにしてもこの wmlhq(自称)という人は……。掲示板の閲覧者はする～かが試されている(笑) 関わりたくはないけど知識とエネルギーは無視できないものがある。うまく操縦できる人がいればいいのかな。上から目線で仕切屋でイラッとする年寄り言葉を使ったりでこの人に指導される新人に同情するものの、悔しいかな、メッセージの国際化の手段に STRINGTABLE, MESSAGETABLE, gettextの三つを挙げたり、入力補完の高速化に bsearch, ハッシュ, dartsの三つを挙げたり、できないもんねえ。ちょっと前に WEB+DB PRESSで dartsっぽいのは見かけてたけども、わからなくて検索したし。

S:3300,3299,03/11/07,21:31,,
T:BREGEXP.DLL
N:かろと
E:karoto@infoseek.jp
M:
▼ もかさん
> Perl Artistic License
> "Freely Available" 内の  2.「バグ修正」か「移植」のための修正
> に該当しそうですが、どうでしょうか？

オリジナルのPerlの関数には、行頭から文字列を渡せるようになっていて、
BMatchEx()で、その引数にも値を渡せるようにしただけなので、
変更そのものは簡単なことで、「移植」なんて言うのもおこがましい程度です。


> 微妙に気になるのは、V1.0(VB未対応)で、Exportしてる関数が少ないのと、for SAKURA になってる... 

V1.0とV1.1の違いって、VB対応だったんですね・・知りませんでした。
Linux版のソースをもってきた関係上、VB対応部分は入ってませんでした。
というわけで、ExportしているVB用関数もありません。
Linuxソースなので、リソース関連のファイルは同梱されてなかったので、適当に作り、
本家のBREGEXPと異なることがわかりやすいように、「for SAKURA」ってのを入れました。（笑）
まずいでしょうか？

> #いい感じだと欲が出てくるもので、
> #ついでに改行コード周りもDLL側でやってくれないかなぁ（実はやってる？)

実は、同じ事を考えて、内部の以前Perlの関数眺めたのですが、改行は１文字(\n)だと
決めて処理している箇所があり、難しそうだなぁと思いました。

> #UTF-16にも対応してくれないかなぁ

ははは・・・さすがに対応済みのDLLを持ってきた方が早いかと・・

「改行は１文字(\n)」が「改行は１文字(\rの後ろではない\n, \r)」になるだけでも十分ではないのかなあ。

• lf_and_cr_as_eol.rev2.patch(2.4KiB)
• sakura(r1764_without_bregexp_trick).zip(497KiB, dllの違いをテストするために、検索パターンの置き換えトリックを行わないように変更したもの)
• $が行文字列末尾にもマッチする関係ですべて置換が置換しすぎる(上の zipファイル内の sakrua.exeに限った話)。BREGEXPは正しい処理をしているので、sakura.exeでの対処はやはり必要になる。($ が行文字列末尾にマッチしたのは無視すべきだが、空パターン (?:) が改行文字の後ろにマッチしたのは無視すべきでない。果たして両者を区別できるのか？)

• 調子に乗って hitEnd()に相当する機能を付けたら、複数行検索も

  1. 基本的に一行検索
  2. 改行文字の後ろまでマッチが続いていたり、hitEnd()が真ならバッファを確保して複数行検索モード

  みたいにしてできるかも。複数行検索モードの実装が面倒くさい上に BREGEXP for SAKURA限定機能なので C/Pは悪い。

• BREGEXP for SAKURAのマッチ仕様変更はこんなんで検出できる。

  bool dot_matches_cr() // falseになっていることを確認する。テストは sフラグOFFで行われる。
  {
  	BREGEXP* rxp = NULL;
  	const char* const szCR = "\r";
  	char szErrorMsg[80] = "";
  	const bool retval = 0 < BMatch("/./", szCR, szCR + 1, &rxp, szErrorMsg);
  	if(rxp != NULL) {
  		BRegfree(rxp);
  	}
  	return retval;
  }
  bool dollar_matches_before_cr() // trueになっていることを確認する。テストは mフラグONで行われる。
  {
  	BREGEXP* rxp = NULL;
  	const char* const szCR = "\r";
  	char szErrorMsg[80] = "";
  	const bool retval = 0 < BMatch("/$/m", szCR, szCR + 1, &rxp, szErrorMsg) && rxp->startp[0] == szCR;
  	if(rxp != NULL) {
  		BRegfree(rxp);
  	}
  	return retval;
  }

正規表現に関連して、ログからこんな URLも見つけ出してきた。

• JRegex内部解説(menbers.at.infoseek.co.jp)
• jperlの正規表現ルーチンメモ pregcomp編(www.kt.rim.or.jp)

「COOLなURLは変わらない」ということを、リンク切れを発見するたびに思い出す。この二つの URLはもちろん今も有効。

S:3521,*,04/04/03, 0:28,,
T:有効なカーソル位置の謎
N:もか
M:
あと、有効なカーソル位置ってどの範囲なのか、いまいちわかりません。
私が認識している動作は、フリーカーソルモードか、矩形選択中・終了後の位置としてEOFにまつわる位置だけに絞っても、
1. [EOF]だけの行(データの終端は改行)は行頭以外却下。
2. [EOF]だけのレイアウト行(データの終端は普通の文字)は行頭以外却下。
 不思議なのは、レイアウト折り返し時はインデントされないし、カーソル座標表示も変かも。。
3. 普通の文字の後ろについた[EOF]より後ろ（正確には右側かつウィンドウ折り返し線より左側）は有効。
で次の行（EOFマークの次の行だから存在していない行）は不正。

あと、矩形選択で、折り返し位置にカーソルを移動しようとしても、行頭に飛ばされてしまって、最後の1文字が選択できません。
ただし、EOFの表示のみ折り返される場合は、選択できてしまいます。
選択できるようにすると、今度は、論理座標との双方向変換の1対1対応が保証されなくなるので、たぶんこまります。

後半はこれ(20091026p01)関連。なんかもう、ほとんどの問題は既出だという気がしてきた。その都度解決できていれば出てこないはずなのに……。

S:3752,*,04/09/27,17:34,,
T:改行コードが食い違う
N:もか
M:
上書き保存したファイルとエディタが保持しているデータで、改行コードが異なることがあります。

1. 名前をつけて保存で、改行コードを変換する指定で保存
2. リロードされた後、入力改行コード指定により、1.で指定した改行コード以外を選択
3. 改行を入力
4. 上書き保存。このとき、2.で指定された改行コードで保存される
この時点でリロードされないので、保存したファイルと、エディタ上のデータで食い違いが発生します。

同様に、Shift_JIS以外では、ファイルとエディタ上のデータで、実際には異なる(=リロードするとデータが変わる)ことがありますが、
こちらは下手にリロードすると、保存時に文字化けした場合は修正するチャンスを失うことになります。

S:3753,3752,04/10/02,12:21,,
T:Re: 改行コードが食い違う
N:げんた
M:
現象を確認しました．
要するに名前を付けて保存で指定したコード指定がその後の上書き保存でも生きているのが問題というわけですよね．そもそも保存時のコード指定がメンバ変数としてずっと保持されているのが不思議な気がします．
でも改行コードなんか気にしないで，他の文書からコピーしたものを保存したときに常にコードが統一されて欲しいという人もいるかもしれない．かといって保存の都度reloadするのは無駄ですし．

・保存時のコード指定は保存しない
・毎回コードを指定して上書きしたい人はマクロで対応してもらう
というのでいいように思います．

これなんかも、すでに自分で遭遇してる現象なんだけど、ずっと前に確認されていたってわけだ。

他にも、「アウトライン解析のプラグイン化」という語がログのごく初期に登場していたり、正規表現ライブラリが最初は jre32.dllであって、BREGEXP.DLLへは GPL化を目指したときに移行した*のだとか、sakura_core.dll(なにそれ？)だとか、正規表現のパターン区切りとして //k が入力必須で面倒だったり、//k を自動付加するようにしてみたけどまだ \ にエスケープが必要だから @ や % などパターン中に使われていない文字をセパレータにしてみたらどうか、とか(いつ 0xFFに決まったんだろう？)、意外な発見(とどこかで見たような問題が)がざっくざく。

最終更新: 2012-10-27T00:23+0900

♪ [SakuraEditor] サクラエディタの正規表現キーワードを SHJS相当にしたい。(その二)

その一(20090808p03)がだらだら長くなったのでいったん切って、ここに続ける。

 @2010-06-10 バグ発見。

ひどい。「/*」を入力して後ろの行がコメント色一色になったとする。つづけて「*/」を入力しても後ろの行がコメント色のまま。たぶんこれが関係する。

行をまたぐ色分けに問題があって、たとえば一画面に収まらない長大な複数行文字列があったとして、何度も上下にスクロールしたり改行を入力したりするだけで色分けが変わってしまっていた

本当にそうなら、泥縄式バグ潰し無間地獄へ突入ですな。消火行為が点火に直結した効率のいいマッチポンプだもん。

まさしく > たぶんこれが関係する。

そのときの変更にこんなコメントが添えられているのを発見した。「IsInsideKeyword()から呼ばれたときは精算したらダメっぽいのでコメントアウトして様子を見る。」様子見の結果はダメでした。さあ、どうしよう。

別の場所で不必要にキャッシュを無効化している部分を厳密に処理したら直ったっぽい。キャッシュの有無で結果が変わるはずないんだけど……。(さらなる追求が必要。でもそれは問題が見つかってからにする)

 @2010-06-13「キャッシュの有無で結果が変わるはずないんだけど……」

変わりうる。一行の色分けは一時(いちどき)に、他の行の色分けを挟んだりせずに終わらせなければいけない。正規表現キーワードは各行の行頭がどういう状態か(コメントの中か？とか)を覚えているキャッシュの他に、ある行を中間まで処理したマッチング結果を持っており、先ほどはこれをキャッシュと呼んでいた。そいつは、次の IsStartOfKeyword()呼び出しを待っている宙ぶらりんな状態。期待していた呼び出しがくる前にクリアされたら結果がおかしくなる。マッチングを中間で止めざるをえないのは、他の色分けに先食いされた文字をマッチに利用してしまわないように。

最終更新: 2016-11-30T10:20+0900

♪ [SakuraEditor] 行削除って便利。

標準では Ctrl+Shift+E。俺は Ctrl+Deleteに割り当てた。

で、使ってるとスクロール位置がずれるのが気になってくる。深いディレクトリで GREPすると表示される結果の大部分が定型のパスだけになるから、違いを見分けるためにはパス末尾のファイル名とマッチした行が見えるように右にスクロールする必要がある。そして、目当てのものではない行を Ctrl+Deleteで削除していくんだが、行削除後にキャレットの行頭からの桁位置は保たれてるんだけどスクロール位置がずれる。画面の真ん中にいたと思ったマリオが次の瞬間背景とともに右端に移動していたようなもんだ。これがうっとうしい。

削除前に一瞬、行全体が選択されるように見えるので、このときにスクロール位置が変わってしまうのかと思って「行選択->選択範囲削除」の流れを変えて、範囲選択に依存しない削除方法を採用したのがこれ>improve_delete_line.patch(5.2KiB)

実際は削除に使っている ReplaceData_CEditView()というコマンドがキャレットの位置調整を行っていたのが原因だったから、削除方法は選択範囲の削除のままでもよかったかも。ともあれ、行全体を選択する操作がちらつくのとスクロール位置がずれるのがなくなった。(ReplaceData_CEditView()がやっているように再描画の必要な範囲を求めたりせずビュー全体を再描画してるから環境によっては画面全体がちらつく可能性がなきにしもあらず。「画面キャッシュを使う」とか DWMがなんとかしてくれることに期待。どうせ 1画面50行のうち削除された行より下は元からすべて再描画対象だしー)

 @2010-06-21 タブやタイトルバーに変更フラグが表示されるように修正した(rev1.1)。

improve_delete_line.rev1_1.patch(5.5KiB)

フラグ自体は立ってたけど描画が行われていなかったというミス。

最終更新: 2010-06-25T21:23+0900

♪ [COSMOS] SpeedFan 4.41beta11が Fintek71889Fに完全対応してる。

SpeedFan 4.40からのアップデートで、MSI 790FX-GD70というマザーボードの SYSFAN1と SYSFAN3のコントロールが、BIOSからだけでなく SpeedFanからもできるようになっている。以前はできなかった(20090601p01)。これですべてのファンの回転数の取得と制御が Windows上で可能になったわけで、まったくありがたいことです。

4.41betaの更新情報によると 4.41beta5からみたい。

Beta 5 ..., adds full support for Fintek F71889F,...

Historyで見られるように

4.39-added full support for Fintek F71889F, even at unusual addresses

4.39から完全対応を謳っていたのは秘密だ。

 スタートアップログ

Win9x:NO  64Bit:YES  GiveIO:NO  SpeedFan:YES
Scanning ISA BUS at $0290...
SuperIO Chip=FINTEK F71889F
Scanning AtiIgp SMBus at $0B00...
F75387 found on SMBus at $2E
F75133S found on SMBus at $36
Scanning ISA BUS at $0600...
F71889F found on ISA at $600
Found Hitachi HDT725050VLA360 on AdvSMART
Found ST3250410AS on AdvSMART
Found WDC WD10EADS-00M2B0 on AdvSMART
Loaded 4 events

違いは

F71882F found on ISA at $600 (reported by SpeedFan 4.39β7)

だった部分が

F71889F found on ISA at $600 (reported by SpeedFan 4.41β11)

になっていること。

 SpeedFanでの表記と M/Bの対応。回転数制御可否。

 電圧も表示が変わってる

12Vがきちんと 12Vある。

最終更新: 2010-06-26T01:41+0900

♪ [SakuraEditor] メニューコマンドの点々。

https://sourceforge.net/tracker/?func=detail&aid=3002900&group_id=12488&atid=1013762#artifact_comment_4019898

たんなる自己弁護に終始するのでここに書くけど、

• 俺の態度が「現状が最高」と誤解された部分は、張っていた予防線の内幕ばらしに過ぎない。防衛線に余裕をもたせていたというだけのことで、誤解された部分を攻撃材料に使ってはいない。
• パッチ(現状への変更)を基準にして意見したら、現状支持が目立つのは当然では？
• パッチを基準にせず、現状の「印刷プレビュー...」の点々を削るようにも意見できたはずだけど、そのときはガイドライン(間違いようもなく、PrintPreviewには付けんな、って例示してある)を未読だったのと最初に参考にしたのが WordPadだった(「印刷プレビュー...」になってる)のでできなかった。
• 現状の「アウトライン解析...」と「ウィンドウ一覧...」の点を削るように意見しなかったのは、もう書いたように、アウトライン解析というのは名前から推測されるように解析を行うのが主目的のコマンドというだけでなく、関数を一覧にしてその定義にジャンプするためのものだと自分でも思っていたから(むしろそちらが主目的)。定義にジャンプするのが「primary/intended action」だとするなら、表示される解析結果はコマンド実行に必要な補足情報をユーザーに選んでもらうためのダイアログとなり、まさしく点々を付ける理由になる。
• 現状が基本的に納得できる点々の付け方だった。moca_skrさんのコメントでそれはみくさんの仕事だと紹介されているが、そのときの基準「操作が確定しないものには"..."を付ける」というのは「...はクリックしただけではコマンドが未遂*のものに付いている」という自分の理解と違わないのだから。

• 他アプリケーションを見ても、...の使い方はかなり恣意的な様です

  だからこそ俺はガイドライン(を紹介するコラム)を紹介したし、MSのアプリしか参考にしてないし、俺判断が入り込まないようにできるだけ緩くガイドラインを適用⁑してはみだした部分だけを指摘したつもりだけど、それでも現状最高うぜーと思うならガイドラインに従って反論してほしいと思う(もちろんガイドライン不採用というのも一つの選択肢として残ってるけど)。

別コメントへの反応。ダイアログのモーダル/モードレスと点々には関係がないと思う。検索ダイアログがモードレスだとモーダルに比べて、ダイアログを表示してからでも検索文字列を編集テキストからコピーしてきたり、スクロールしてテキストを確認しながら検索条件を練ることができて便利、ぐらいの違いしかないのでは。

ああ、いやいや、モードレスであることで違う使い道ができる。コマンドの目的(できれば名前も)が変われば点々の必要性も変わる。

• 「検索...」->「検索ウィンドウ表示」
• 「アウトライン解析」->「アウトライン解析結果表示」

ツールパレットを表示するコマンドには点々が付かない(これは既定事項)。サクラエディタの検索画面はモードレスだし勝手に閉じないようにも設定できるので、メインウィンドウの横に置いてツールウィンドウとして利用することができる。その場合「検索...」コマンドは「検索ウィンドウ表示」コマンドとして振る舞っている。モーダルだった以前と違い多目的コマンドなのだが点々はいかがすべき？という内容だったのかも。

こうなると複数あるかもしれないコマンドの使途ではなく、コマンドの名前から主目的を一つ判断して点々の有無を決めることになるだろう。してみると「コマンド名に『アウトライン解析』を選んでいるからには、点々を付けるべきではない」と主張すべきだったかもしれない。解析結果がモーダルダイアログに表示されていたときでも同じ(点々を付けるべきではない)。

「指定行へジャンプ...」のアウトライン版に相当するコマンド名を採用したときには点々を付けるべきだが……と考えながら思い立って「指定行へジャンプ...」を実行したらメモ帳のそれより大きいダイアログが表示された(初めて見た)。場所をとってるのは PL/SQLのコンパイルエラー行を選択するためのもの。先を越された。アウトライン解析結果を参考に特定の行にジャンプするのが目的なら、こういうアプローチもありでは？(やっぱり専用画面の魅力には負ける気もするが)

 @2010-06-25

アウトライン解析ってその結果をジャンプだけでなく色分けや補完にも使いたくなるから、「アウトライン解析」っていう名前のコマンドは消えてもいい。

最終更新: 2010-06-26T01:04+0900

♪ [無題]

 レンタルサーバ リソース使用状況

びびった。<meta name="robots" content="noindex,nofollow" />を理解できない baiduspiderを拒否してからはそれ以前の半分以下の 10分、20分が普通だったのに 2時間超えてる。スパムコメントが大挙して押し寄せたときも 2時間の大台にのることはなかったし、スパムコメントが届いているわけでもない。死に損ないのプロセスがあったのかなあ。ちょくちょく、ライトプランでは使用できない PHPプロセス[php-cgi (php-cgi-mysql5.1)]が自分の権限で動いてるのを見つけるくらいに、リソースの使用状況を確認してるけど初めてだ。

crawl-XXX-XXX-XXX-XX.naver.jp - Yeti/1.0 (NHN Corp.; http://help.naver.com/robots/)

が 24時間かけて 3380件(2.34pages/minuteのペース)アクセスしてたのが原因。延々とカテゴリページを過去にさかのぼって取得してる。新顔のクローラでもないのにどうして突然？

原因はこの日記に固有の、最新表示に似せたカテゴリ表示に search_control.rbを対応させるのを忘れていたことなのでさっさと修正した。

最終更新: 2010-07-05T02:41+0900

♪ gdippを 0.7.6から 0.8.1へアップデート。

0.8.0の変更点にこんなんがある。

Support DirectWrite. Since the minimum system requirement of DirectWrite is Windows Vista, gdipp is no longer available in Windows XP.

サクラエディタで文字が表示されるまでの時間が二呼吸は遅くなるけど、文字がつるっつるのえろえろになるんだから仕方がない。つぶつぶがたがた文字よさようなら。

Firefox3.6.6に使うと文字が選択範囲に入ったときに位置がずれる。文字として存在しない空白が表示されたりもしてる。0.7.6では違ったはずだが。Firefoxに gdippを適用して嬉しいことのひとつは日本語の oblique表示が美しい(というか、まともである)こと。

DirectWriteを rendererに選ぶと文字を太らせられないのだろうか。ちょっと線が頼りないのだけど。

gdipp_loader_32.exeが、引数として与えられたプロセスが終了するまで終了しなくなってる。WaitForSingleObject(pi.hProcess, INFINITE);してるんだから必要なことなんだろうけど残念。

gdipp_loader_32.exeは第一引数(任意の exeファイル名)のディレクトリをカレントにして exeを起動するけど、そのせいで exeに渡される二番目以降の引数が相対パスだったときにファイルを見つけられない。例えば次のようなのが失敗する。

Desktop>"C:\Program Files\gdipp\gdipp_loader_32.exe" C:\Windows\System32\notepad.exe file_on_desktop.txt
# Notepad can't find file_on_desktop.txt

こちら(↓)が成功することを考えると、上は期待はずれの結果。

Desktop>C:\Windows\System32\notepad.exe file_on_desktop.txt
# O.K. Notepad opens file_on_desktop.txt