脳log[2009-09-23～]

最終更新: 2013-04-29T21:18+0900

♪ [SakuraEditor] 矩形選択を普通の選択と同じ操作感に。(Shift+○という操作を Alt+○に置き換えるだけ)

いままでは、Alt+矢印で矩形選択モードに入った後、Altを放して、それから選択範囲の拡大を(矢印で。Shiftは不要)行う必要があった。また、知らないうちに矩形選択モードに入ってしまっていて驚かされることも何度かあった。それら、Altを放す必要や知らぬ間のモード変更がなくなる。

2000年にはそのための布石というか、コメントアウトされたプレースホルダが用意されていた。そのおかげで、全くたいしたことはしてないのだけど、これまで放置されてきた理由なり原因なりを何か見落としてる？

 差分更新

easy_box_selection.rev2.txt (30.6KiB, 2010-04-13)

trunk2@1732に対する差分。

キー割り当ての初期設定の間違いを一つ修正。

折り返し行頭への移動が本当の行頭(改行文字の直後)への移動だったのを修正。

 @2013-04-27 Mocaさんによるパッチ

Sakura Editor / PatchUnicode / #449 矩形選択移動コマンドの追加

俺みたいにありもののコマンドで間に合わせるのでなく、足りないコマンドの実装までされています。

今思うと矩形選択しながらの、(折り返しでない本当の)改行単位での行頭・行末移動は不要だった気がする。プレースホルダはあったけど、使わないでしょう？ 改行単位の GoLineEnd自体は、矩形選択と組み合わせては使わないにしても、なくて不便だった(20120227p01.02)ので必要だけど。

残念なのは、既存ユーザーの sakura.iniには Alt+↑、Alt+↓、Alt+←、Alt+→に対する「矩形選択開始」の割り当てが既に書き込まれていること。勝手に設定を書き換えることはできないから、プログラムをアップデートしただけでは利便性の増した矩形選択に気付けない。関連するキー割り当てがデフォルトのときだけ書き換えてしまうのはありかもしれない。アップデート後１回だけ ini書き換えを実行するために、iniにフラグのための項目を増やすことが考えられる。WSHで独立したスクリプトを書く方がオーバーヘッドは少ないが、実効性は著しく下がりそう。別に隠れ機能でもいいけどね。よく使う人ほどこれまでの操作に慣れてるだろうから。ヘルプに２通りの操作があることを書いておけば気付くでしょ。でも、慣れてるけど不便だと思ってる人に気付いてもらえないなあ。俺みたいにリリースノートを嬉々として読む人間ばかりではないだろうし。

最終更新: 2016-03-05T00:30+0900

♪ [SakuraEditor][正規表現] 正規表現を使った検索・置換で、改行の意味を LFのみから CRも含むように。

経緯 > サクラエディタBBS[r7030]

差分 > fix_cr_handling_of_regex(下に修正版がある)

お試し > sakuraW.zip (547KiB)(下に修正版がある) (正規表現検索・置換を試すには bregonig.dll(Unicode対応版)が別途必要)

検索、置換を数度試したが機能しているみたい。ただ、$ が本当に改行の手前でマッチする関係で

^.*$

を空文字列に置換するという最初に提起されたケースでは、置換後の空行までが置換対象になってしまう(置換回数が 2倍)。目的に適う、より適切なパターンは

^.+$

あるいは、エディタの行置換機能を使っているのだから、もっと単純に

.+

で良い。

 @2009-09-24

「正規表現 - SakuraEditorWiki」を見ていて気付いた。\c[、\c]、\c$、\c. という制御文字のひとつを表すパターンが存在する。「鬼車 正規表現 Version 5.9.1」によれば \C-[、\C-]、\C-$、\C-.、\M-[、\M-]、\M-$、\M-. も存在しうる。\M-\C-[ なども存在しそうに思ったけど、これはこういう結果になった。

irb(main):001:0> /\M-\C-[/
SyntaxError: (irb):1: too short escaped multibyte character: /\M-\C-[/
        from c:/Program Files (x86)/ActiveScriptRuby-1.9.1/bin/irb.bat:20:in `<main>'
irb(main):002:0

制御文字なんて扱ったことがないからなあ(もはや relicだという認識)。対処の必要性がさっぱり感じられないけど……。

 @2009-09-25

一括置換で $ が CRLFの CR直前、LF直前、LF直後(正規表現DLLに与えた文字列末尾)の三カ所にマッチしてしまうとの指摘 >サクラエディタBBS[r7039]。

逐一、置換を実行した場合は問題ないことを確認していたのだが、一括置換はライブラリに全部お任せで、検索開始位置を調整することもできないから動作が違っていたのだろう。$ が CRと LFの間にマッチするのはわかっていたが、明示的に \r を食べた場合にだけ影響があると思っていた。一括置換なんてありふれた操作でそれが明るみに出るとは思いもせず。

急いで修正 > fix_cr_handling_of_regex.rev2、sakuraW.rev2.zip (547KiB)(さらなる修正版 rev3が下に)

初めて戻り読みを使った。なんとなく反則的な手段の気がして、使わないですむ方法をいつも考えるのだけど無理だった。これで bregonig.dll依存が決定的になった。[] の入れ子のことだけなら ] が見つかったときに charset_levelを一気に 0 にするだけで BREGEXP.DLL対応もできたのだが。

\C-X、\M-X というのは Ruby向けなのかも。サクラエディタ(+bregonig.dll)で \C-[ を検索しようとすると「premature end of char-class」というメッセージが出る。となれば、\cX だけが引っかかった小骨ということになる。

対処 > fix_cr_handling_of_regex.rev3、sakuraW.rev3.zip

<追記>bregonig.dllでは \c\X が \cX の意味になるとか。もう知らねー。</追記>

個人プロジェクトでもないと色々大変そう。ドッグフードでも食べながら様子見します。とりあえず反応だけ。

 ２．非対応となっているBREGEXP.DLL(ANSI版)への対処方法
 ANSI版とUNICODE版は別仕様としてしまうのか？

使用できる正規表現自体が別物なので BREGEXP.DLLは CBregexp::MakePattern()でよいかと。ユーザーを驚かさないための変更なので、. が \r にマッチすることを期待していた人以外に影響はないつもりでいる。

<追記>ANSI版+bregonig.dll向けのパッチを用意したので、別仕様は ANSI版+(BREGEXP.DLL/bregonig.dll)と Unicode版+bregonig.dllの間、または、 ANSI版+BREGEXP.dllと (ANSI版/Unicode版)+bregonig.dllの間のどちらでも選べる。BREGEXP.DLLのサポートするオーソドックスな(戻り読みをサポートしない)正規表現で、$を改行直後の行文字列終端にマッチさせない方法が見つからない限り BREGEXP.DLL対応は無理。</追記>

<追記>BREGEXP.DLL版も用意した。>_ANSI.rev2 >_ANSI.rev3</追記>

 ３．$ が改行なし最終行のEOF手前ともマッチするように改善すること
 $ を (?=\r\n?|(?<!\r)\n|(?<[^\r\n])$) に置き換える方法を試してみたけどエラーで動きませんでした。

肯定の戻り読みは (?<=) でした(なにせ使用経験がないもので)。気を取り直して、パターンを (?=\r\n?|(?<!\r)\n|(?<=[^\r\n])$)* に置き換えたところ、検索は予想通り、最終行がEOFのみの場合を除いて文書末にマッチするようになったのだけど、置換が行われない。(以前は行われていたのだろうか？ マッチのインデックスが文書の長さと同じ(=1つはみ出した状態)になっているはずだから特別な対処が必要なのだろう)

「以前は行われていたのだろうか？」< 行われていなかった。なら、(間違ってるけど)おいておこう。

 ４．検索強調表示が検索時の選択反転表示と一致すること
 $ を (?=\r\n?|(?<!\r)\n) に置き換えた版で $ を検索すると、改行文字自体は選択反転表示にはならない（マッチしない）のに検索強調表示されている。
 また、なぜか上方向検索では改行文字自体にマッチしたかのように選択反転表示になる。

$で検索したときに改行文字が強調表示されるのは、幅0のハイライトには意味がないので、実用面から今のように最低でも幅 1を保つべきだと思っていた。

上検索で改行が選択されてしまうのは間違いなので修正したい。これまでが、知らず $ が改行にマッチする仕様に依存していたのかもしれず、こういう修正は正しい方向に向かうためのものだと考えている。

修正した(rev4)。無限ループを避けるためにマッチ幅が 0のときに検索開始位置を特別にインクリメントするんだけど、そのタイミングが悪くて検索開始位置だけでなくマッチの範囲までがインクリメントされていたのが原因。

 ５．正規表現キーワードでの $, . 指定も検索・置換と挙動が一致すること
 現状、正規表現キーワードには $, . に検索・置換でやっているような細工が入っておらず、素の正規表現ライブラリ挙動になっている模様。
 検索・置換時の . の細工（[^\r\n]への置換）が追加されると、今よりも差異が大きくなって混乱しそう。

すでに書いたように、. が \r にマッチすること、$ が CRLF の真ん中にマッチすることを期待していた人(いるのか？)以外は違いに気付かないだろう。

\r\n$ みたいな書き方をしていた場合にマッチしなくなる。このケースはなくはないかも。

 ６．検索・置換や正規表現キーワードの複数行対応への順応性

ノーチェック。sフラグが含まれる( . があらゆる文字にマッチするようになる)ときには . を置き換えないようにする、mフラグが含まれない( ^、$ が行頭、行末にマッチしなくなる)ときには $ を置き換えないようにする、とか？

>fix_cr_handling_of_regex.rev4、sakuraW.rev4.zip

2ch民は 1.6.5.0をつかうのね。♥マークはいらないんだ。Consolasも使いたくない⁑んだ。(これは俺の理由だけど) r1663を使おうぜ。

 @2009-09-28

Unicode版Revision1662>http://sakura-editor.svn.sourceforge.net/viewvc/sakura-editor?view=rev&sortby=date&revision=1662

Ansi版Patch>http://sourceforge.net/tracker/?func=detail&aid=2869238&group_id=12488&atid=312488

勘違いしていた。Unicode版のサクラエディタで使用できる正規表現ライブラリは bregonig.dll(Unicode版)だけだ、という事実がいつの間にか、bregonig.dllは Unicode版専用だ、という思い込みにすり替わっていた。

だったら、採用の可否はともかく、Ansi版(trunk2の (Release|Debug)_Ansiビルドのことでなく trunkのビルド産物のこと、だろう)向けのパッチを作成する意味はあるわけだ。CBregexpのインスタンスがその寿命を通じて 1つの DLLだけを扱うのであれば、コストを初回に払うだけで、処理の振り分けを行うことができる。どっちかな？

>>> DLL初期化時に呼ばれる仮想関数がありました。(そのたびにチェックを行えばいい。実際は 1回しか呼ばれないだろう)

CheckRegexpSyntax() は癌だ。検索ボタンを押すたびに DLLのロードからはじめて、文法をチェックしたら使い捨てるって何事。文法チェックは Compile()で十分。その後の Match()のための準備にもなってちょうどいい。もろもろの手順を共通化したいのなら引数として CBregexpを受け取るべきだ。正規表現のチェックをしたい(=正規表現を利用したい)部分ではもちろん CBregexpなりなんなりをすでに持っているだろう。CheckRegexpSyntax()がこんな重量級のローカル変数をもつ必要はない。無効な検索パターンを履歴に追加したくないがために、検索の主体でない検索ダイアログが利用しているのかもしれないけど。

 @2009-09-29

やっつけで一応。これで昨日書いた「コストを初回に払うだけで、処理の振り分けを行うことができる」が事実になった。昨日の段階では、検索ボタンを押すたびに DLLがサポートする文法をチェックする関数が実行されていた(初回どころではない)。これでもまだ、検索ボタンを押すたびに Compile()が 2回走るのは変わっていない。

• stop_abusing_cbregexp
• stop_abusing_cbregexp_ANSI

おまけとして、bregexp.dllだけが sakura.exeの隣にある状態でエディタを起動し、その後 bregonig.dllを配置したとき、検索ダイアログでは 「bregonig.dll Ver....」と表示され、bregonig.dllしかサポートしない戻り読みを使用しても正規表現エラーにはならないものの、実際の検索には bregexp.dllが使用されるためだろう、戻り読みが機能していればマッチするはずの条件でもマッチ無しになってしまう、こういう、説明もややこしい起こりづらい状況が起こらなくなる。(文法チェックと実際の検索が CBregexpの同じインスタンスによって行われるようになるから)

本当は CBregexpが CDllHandlerを継承するのをやめて分離して、1つの CDllHandler(DLLインスタンス)を多数の CBregexp(BREGEXP構造体)から参照するのがいいのかも。もっといえば、BREGEXP構造体もコンパイル済みパターンとマッチ結果に分離したい。サポートする文法の情報はもちろん DLL付きの情報。CDllHandlerは汎用的すぎるから、その任には、CDllHandlerを継承したいまの CBregexpから BREGEXP構造体だけを追い出したものを充てればいい。

いまの CBregexpは InitDll()を呼び出されて、途中で違う正規表現ライブラリを読み込まされたとき、コンパイル済みの BREGEXP構造体を正しく解放できるのだろうか？

 @2009-10-01

BREGEXP.DLLでも . と $ を置き換えるようにしてみた > fix_cr_handling_of_regex_ANSI.rev2(下に rev3)

副作用があって、XYZ(CR)(LF) という行に対して XYZを検索すると XYZ(CR)(LF) がマッチする。マッチ結果が改行に隣接しているとき、改行がマッチに含められます。$を検索すると (CR)(LF) がマッチするのは以前からの通り。ここが変わらないのは、一括置換での過剰な置換を防ぐ手立てがこれしか BREGEXP.DLLからは与えられていない、ということ。

ついでに気になった、\r\n を検索したときステータスバーに 1 bytes selected. と表示されるのを修正。>fix_selection_area_and_selected_byte_count_ANSI 選択領域が中途半端なサイズだったのも直った。それもこれも CLayoutが EOLの長さを常に 1とカウントしていたせい。マッチ範囲が勝手に 1切り詰められていた。

表示としては ↵ も ⇠ も ⇣ も同じ一字だから CLayoutのすることにも一理あるのかもしれない。それなら改行文字の部分の選択領域をせめて全角幅にして検索結果のハイライト部分と大きさをそろえよう。

ANSI版の View関連のソースを見てたら気が遠くなる。Unicode版で

• CRLFを全角幅で表示
• CRLFの CR、LFのみハイライト、選択
• LF、CRの全角表示、全角幅選択(or半角幅ハイライト)
• 行頭マッチ(^)でキャレット描画

あたり、なんとかならんかな。検索結果の選択範囲とハイライト領域のずれが気になる。

 @2009-10-03

ANSI版を BREGEXP.DLLと組み合わせているときに、不必要に改行が検索結果に含まれてしまう場合を rev2より大幅に減らした。意地悪なパターンを与えられたときにどうなるかは把握しきれていない。

> fix_cr_handling_of_regex_ANSI.rev3(rev2と rev3にバグ発覚。rev4へ)

fix_cr_handling_of_regex_ANSI.rev4

どういうバグだったかというと、一括置換をしたときに改行や行文字列末尾付近で過剰に置換が行われないように、戻り読みが使えない BREGEXP.DLLのときは検索パターンと置換文字列に細工を施すのだけど、検索パターンの置き換え方がまずかった。

 誤: /A|B/ -> /A|B((?:\r\n?|\n\r?)?)/
 正: /A|B/ -> /(?:A|B)((?:\r\n?|\n\r?)?)/

選択 | の結合順位は一番低いのでした。

バグは CBregexp.cppを好き勝手にいじっていた結果をテストしている最中にたまたま見つかった。

• メンバ関数に constをつけたり
• 正規表現フラグを指定する引数の型を intから専用のものに変えたり
• CBregexp::IsLookAhead(const char *pattern)が内部状態を変更して、CBregexp::Match()の結果に意図しない影響を与える可能性を排除したり

していた。これは単なる自己満足。

 @2009-10-04

不必要に選択範囲が改行にかかっていたケースををさらに減少。> fix_cr_handling_of_regex_ANSI.rev5 検索パターンが LF直前や文字列末尾に幅0マッチしそうなときにだけ細工を行うことにした。なんというか、盆栽趣味？

バイナリ>sakura.zip

 @2009-11-25

AINI版では LFCRの LFと CRの間に幅0マッチしそうなときも細工を行わないといけないだろうな。やらないけど。(LFCR？なにそれ？という立場)

最終更新: 2011-03-25T01:34+0900

♪ [SakuraEditor] シンボリックリンクを開いたとき、更新通知の無限ループ

そして素朴な疑問。選択肢が 4つあるんだけど

• 再読込(&R)
• 閉じる(&C)
• 以後通知メッセージのみ(&M)
• 以後更新を監視しない(&N)

閉じるをクリックしても予想に反してエディタは閉じられないのと、(延々と表示され続けてもおかしくない)通知メッセージはどこに出ているのか？

 @2010-07-08 補足。

シンボリックリンクを開くと、ショートカットファイルを開いたときと同じようにターゲットファイルの内容がエディタに表示される。そして他で何もせずとも、最初に必ず更新通知ダイアログが表示される。だから「再読込」を選ぶと読み込み後にまた更新通知ダイアログが表示されることになって無限ループ。「閉じる」(=ダイアログを閉じる=更新を無視する)を選ぶと今度はターゲットファイルが本当に更新されたときも察知できなくて永遠に黙る。

対策は、シンボリックリンクを開いていることを意識して、常に(ファイルの読み込みと更新監視で共通して)ターゲットファイルの更新時刻を調べるようにすること。

っていうほど単純でもない。更新日時だけ特別扱いしたらファイルの属性に一貫性がなくなる。更新監視部分でだけターゲットファイルの更新日時を比較するのが影響範囲が最小だけど更新日時を保存するメモリ領域をどこかの管理下に用意しないといけない(だれが管理する？もちろん CEditDocのメンバの CAutoReloadAgent)。一番面倒がないのはシンボリックリンクのターゲットをたぐってそのファイルを開いたことにすること(ショートカットと同じ)。なんとなくこれが嫌なのはカレントディレクトリが変わってしまうこと。他にもいろいろあると思う。ショートカットでなくシンボリックリンクを使うのは、ターゲットファイルがそこにあるようにアプリケーションをだましたいときだから、サクラエディタも(今はタイムスタンプ取得方法の一貫性のなさからかおかしなことになっているうえ、だまされているせいで更新の監視ができていないが)上手にだまされてほしい。

 @2010-07-08 更新通知ダイアログがわかりにくい

• 「閉じる」って何を閉じるの？
• 「以後通知メッセージのみ」「以後更新を監視しない」って結局再読み込みするの？しないの？

ので、こうした(improve_fileupdatequery_dialog.patch)。

わかりにくいと感じてるのは俺だけじゃなくて、sakura-dev:3014で wmlhq氏が書いている。

なお、更新通知ダイアログはわかりづらいようなので、次のようにしてください。

----------------------------------------
<!> このファイルは別のプログラムによって変更されました。

読み直しますか？
----------------------------------------
 [ ]今後、ステータスバーに通知する 
 [ ]今後、通知しない 
----------------------------------------
[はい] [いいえ]
----------------------------------------

日記を書く段になって見直したんだけど wmlhq氏のメッセージのほうが良い。

• 「更新の監視をやめる」という俺のメッセージは不正確だから。(タイマーは常に動いていて、タイムスタンプの比較をしなくなるだけ)
• 通知メッセージがステータスバーに表示されることがわかる。
• サルでも答えられる Yes/Noクエスチョン。

最終更新: 2011-04-09T17:30+0900

♪ [LS-WSGL][VGF-WA1][Songbird] LinkStation Miniにプレイリストを置いて、VGF-WA1で再生。

プレイリストの書き方がわからなかったので実験した。MediaLibraryという共有フォルダをつくって、これをメディアサーバーの公開フォルダに設定している。これがフォルダ階層。

MediaLibrary
├Genre
│└Artist
│ └Album
│  └Title.mp3
├Playlists
│└pl1.m3u
└pl2.m3u

メディアサーバーのデータベースを Webインターフェイスから更新しただけでは VGF-WA1のメニューに素直に反映されなくて、VGF-WA1でブラウズしてるうちに項目が増えていって、いつのまにか「プレイリスト」メニューの下に pl1と pl2が表れていた(だから早々に駄目だと判断してはいけない)。

pl1.m3u に書いた中で再生可能だったのがこれら。

../Genre/Dido/no angel/06.THANK YOU.mp3
Genre/Dido/no angel/01.HERE WITH ME.mp3
MediaLibrary/Genre/Dido/no angel/05.ALL YOU WANT.mp3
/MediaLibrary/Genre/Dido/no angel/02.HUNTER.mp3

pl2.m3u で有効だったのはこれ。

Genre/Dido/no angel/01.HERE WITH ME.mp3
/MediaLibrary/Genre/Dido/no angel/02.HUNTER.mp3

実際のところ、引用符で囲ったもの以外は全て認識された。

試してないけど

../../../../../Dido/no angel/01.HERE WITH ME.mp3

とか

Dido/no angel/01.HERE WITH ME.mp3

とか書いても認識されそうな気が今はしてる。

VGF-WA1はプレイリストもシャッフル再生してくれる。リストの曲を全て再生すると、次のリストに移動する。良い。

 Songbirdでエクスポートしたプレイリストを LinkStation Miniに認識させるために。

 プレイリストの文字化け

Songbirdの Playlist Export Tool (ver.0.1.1.14)でプレイリストをエクスポートしたら文字が化けている。「KMKM :: Firefoxのjavascriptでローカルファイルにアクセスする方法まとめ」のやり方を丸コピしたら Shift_JISでも UTF-8でも化けずに書き出すことができた。試したのだが、LinkStation Miniの PVConnectは UTF-8の日本語パスを理解する。

 曲のパスの形式の違い

Songbirdでエクスポートしたままではリスト内の曲のパスが \\server\で始まるネットワークパスだが、このプレイリストはそのサーバー(NAS)に置くものなので相対パスに置換する。

 Case Sensitivity

Media Player Classicはプレイリスト内の曲を、エンコーディングの違い(Shift_JIS、Unicode)、パスの形式(ネットワークパスと(厳密な)相対パス)の違い関係なく再生してくれるが、LinkStation Miniは Songbirdがエクスポートしたプレイリストを一度も再生してくれていない。

最後の壁は Songbirdでエクスポートしたプレイリストに含まれるファイルパスの英字が全て小文字になってしまっていること。LinkStation Miniのメディアサーバーは大文字小文字を区別する。

Playlist Export Toolは特別な処理は行っていなくて、関連するのはこれだけ。itemLocというのが曲のパス。

var aaa1;

var itemLoc;

	aaa1=theMediaView.getItemByIndex(i).QueryInterface(Components.interfaces.sbILibraryResource);
	itemLoc=aaa1.getProperty(dataSource+"contentURL");
	if(nsIIOService.extractScheme(itemLoc)=="file"){
		itemLoc=nsIFileProtocolHandler.getFileFromURLSpec(itemLoc).path;
	}

どこで大文字小文字の情報が失われてしまったんだ……。(プロパティ:"http://songbirdnest.com/data/1.0#contentURL"の時点でもう失われているのだろう)

• Playlist Export Toolのソースは LFと CRLFが混在している。
• どういうわけかエクスポートするプレイリストを選ぶ画面で、すべてのプレイリストが二重化している。エクスポートされる内容は全く同じ。

「Songbird (under Windows) saves filenames in the internal database as lower-case」なんて書いてる人もいるなあ。Windows限定でどうして情報を捨てるようなことをするのか。ネットワーク越しに、ディレクトリエントリを読むことで(二重苦)、スクリプトが反応してないよダイアログを出しつつも元のファイル名を復元することはできたけど、パスも復元しないと……。無駄だなあ。

でもやった > Songbird_PlaylistExportTool_0_1_1_14_utf8_encode_and_exact_path

サーバー名とその下の共有名は復元できなかった。それらは親ディレクトリがないから列挙するには別の方法が必要。どうせ相対パスにするときに置換されてしまう部分なのでこれ以上は知らない。

なぜ？なぜ VGF-WA1のプレイリストメニューに表れない？ 数曲分、手書きしたときはうまくいったのに。

プレイリストのファイル名から日本語部分を削ったら見えた。でもこれは曲数を 6曲まで絞り込んだファイル。Songbirdからエクスポートした完全なプレイリストは再生できてない。曲数に上限があったり、NGワードがあったりするのか。

ファイルパスの 1つ前の行を削ったらその曲は見えるようになった。表示用のデータの扱いに問題でも？

#EXTINF:205,MAHO堂 - おジャ魔女でBAN^2 << この行
../Anime/[おジャ魔女どれみ] おジャ魔女でBAN^2 (MAHO堂).mp3

無効なファイルパスは無視してくれるから、あってもなくてもいい情報のために曲が見えなくなってるとは思わなかった。

長かった……。

 こうしておけば無難だということのリスト

• プレイリストのファイル名に日本語を使わない。
• 日本語を含むプレイリストは UTF-8で保存する。
• プレイリストには音楽ファイルのパスしか書かない。
• パスはプレイリストファイルからの相対パスにする。
• パスの大文字小文字は忠実に守る。

最終更新: 2009-09-05T04:50+0900

♪ 「実行中のコンピュータに PS/2 キーボード/マウスを装着すると認識されない」

そりゃあそうでしょ、PS/2なんだもの、と思ったんだけど

この問題を解決するためのモジュールは、Windows 2000 日本語版サービスパック 3 以降に含まれております。

ええー。

最終更新: 2009-09-04T06:13+0900

♪ [買][COSMOS]["ダイヤテック マジェスタッチNキーロールオーバー カナなし 黒軸 FKBN108ML/NB"]

5日遅れて衝動買いした Excellioに遅れること 3日、Majestouch(黒軸=Linear) が到着。

20090830p01で書いたように、Excellioを USB->PS/2変換コネクタ経由で繋いでみてから M/Bがおかしくなって PS/2ポート(マウス用=緑色)に繋いだトラックボールが使えなくなっていた。そしてこのキーボードも……。ところが、BIOSセットアップでのことをふまえてマウスとキーボードを入れ替えて繋いでみたら、どちらも使えた。色の組み合わせが違っていて気持ち悪いけど、それだけなので使えて幸い。問題が起こったついでだからと BIOSをアップデートしてたんだけど、それでは解決しなかった。

出尽くしていて目新しい感想もないので箇条書きで

• 4mmのストロークは驚くほどは深くない。むしろこれが普通。
• キータッチは重い。努力の必要なく底付きが避けられるほど。Realforceみたいなのをバチバチ叩かないための打ち方矯正キーボードではないか。
• Home、End、Insertキーの配置をローテートしたらキートップが凸凹に。ステップスカルプチャに困った。
• 今見たら 10万円 PCだった VALUESTAR付属のキーボードもステップスカルプチャになってた。キーの角を斜めに押しても擦れて引っかかったりしない。3000円ちょっとで買った単体キーボード(マウスとのセット品)よりいいものだったのだ。(代わりのキーボードは最初から手元に……)
• カサカサシャコシャコと軸が擦れる感じは、パンタグラフ+ラバードームに劣る手触り。
• スタビライザがチャリチャリうるさい。(6つのキー)
• ゴム付きで重たいので分厚い本も押さえられる。
• タイプしていて前よりうるさいとは思わない。むしろ静か。キートップが安っぽい音を響かせたりせず、抑制された音。

Excellioと甲乙付けがたいけど、コストパフォーマンスは Excellioの方が 3倍良い。パンタグラフに違和感がなければ、箱つぶれ Excellioおすすめ。

資料 > スイッチ・キートップガイド構造

最終更新: 2010-06-22T11:46+0900

♪ [C++] 型。var。

初歩の初歩ですよ。

vector<int> v(99);
for(int i = 0; i != (int)v.size(); ++i) {
}

みたいなのがあって(俺が書いたんじゃないよ)、ひょっとしたらキャストがなくても問題ないのかもしれないし、それがないと警告(符号付きと符号なしの比較がうんたらかんたら)が出るのかもしれないけど、(int)って書きたくないよね。static_cast<int>()にしろっていう問題でもなくて。iの型を unsignedにするのも若干のアドホック感がある(なんのための typedef)。かといって v.size()の戻り値の型(vector<int>::size_type？)をコピってくるのも嫌だね。たとえば(そんなキーワードはないけど) varを使って

vector<int> v(99);
for(var end = v.size(), i = 0; i != end; ++i) {
}

みたいに書きたいし、コンテナの型を何度も書く代わりにそこにある、型付けされた変数を使ってこう書きたい

list<int> l(99);
for(type(l)::iterator it = l.begin(); it != l.end(); ++it) {
}

C++のことだし方法はあるはずだけど……。(typedef list<int> hoge; はコンテナの型(hoge)を見つけてこないといけないのは同じだし、俺俺タイプをいちいち命名したくもないし)

 @2009-09-08 varではなく auto

■_ をち

2chにはせいぜいautoマンセーと0b論争がお似合い

1. auto！ まさか……この響きは……(C++0xの文脈で自動変数のわけはないし)。
2. 検索で最初に見つかった > C++0x - auto - Faith and Brave - C++で遊ぼう
3. 日付が 2007年。そんなに前から。全然 C++のこと知らないね。

 @2010-05-12 type(l)::iteratorの方も……

N2971: Core issue 743: decltype(...) name qualifiers

delctypeをnested-name-specifierで使えるようにする変更。簡単に言うと、delctype(T)::typeということができるようになる。
これは、日本から送った意見だ。だからどうということはないのだが。何を隠そう、信仰と勇気で有名なあの人が発見した問題だったはずだ。

「信仰と勇気で有名なあの人」って、すぐ上で autoに関してリンクしたとこの中の人でしょう。decltypeが、varに対する autoのように自分の希望をかなえてくれる本物のキーワードだってことは C++0xに関する記述を断片的に目にするにつれ知っていたけど、最初から名前を修飾する目的に使用できたわけではないとは知らなかった。行動を起こした人がいるのだ。これはもう足を向けて寝られない。