2011年06月16日 (木) [Vista] Explorerの FullRowSelectを解除する方法があったとは知らなかった。デスクトップを詳細表示にするみたいに勝手にやらないといけないのかと思ってた。何が困るってマウスでファイルを複数選択するのがすごく面倒。代償のつもりかしらないけどチェックボックスによる選択は無視するとして、XP以前のようにできなくはないけど「名前」列がすべて文字で埋まってるともう無理。そして、ファイル名ってのがタグを貼り付けるのに一番有効な場所だったりするわけで……。>～ lolipuni ～ ｜ 20110616
2011年06月14日 (火) Subversionメモ。リビジョンには二つあって、「あるパスで指されるファイルがリビジョンNのときにそうだったもの」を指すのが普通のリビジョン。「あるリビジョンのときにあるパスにあったファイル」を指すのがパスリビジョン。両方を指定することもできる。パスリビジョンを省略するとパスは HEADに基づいて決定される。リビジョンを省略するとパスリビジョンと同じ数字が使われる。未来に渡って今見てるのと同じものを参照しようと思うとパスリビジョンの方をこそ指定しないといけないと思う(あってる？)。
2011年06月13日 (月) ワットチェッカーは高すぎて手が出なかったけど、知らぬ間にワットモニターなるものが。ワットモニターの、ワットチェッカーと比べていいところ。小さい。ソケットが下出し(見やすい場所に設置したときに場所をとらない)。安い。難しい数値が出ない。数値が小さいときはコンマ一桁まで表示される(これは良し悪し。ぱっと見で 35Wか 3.5Wかわからない)。精度は変わらない(悪くなってない)みたい。いろいろ可視化できるのが楽しみ。特に PCってのは 30Wも 300Wもわからないし、状態による変動も大きいので知りたかった。電気代が(ちらほら聞こえてくる数字と比べて)高すぎるんよね。
最終更新: 2011-06-17T23:19+0900
♪ [COSMOS] 部屋を見まわして電気製品依存関係リスト
コンセントを必要とするもの。
- 液晶モニタ(MDT243WG) 42W(1.8W)
- ミニコンポ(CMT-SE3) 23W(0.3W)
- パソコン(COSMOS) 126W(2.5W)
- スキャナ(ScanSnap S1500)
- 外付けHDD(玄蔵X4)
- ゲーム(PLAYSTATION3)
- ゲーム(PlayStation2)
- コントローラー(GT Force Pro)
- パソコン(COSMOS) 126W(2.5W)
- ミニコンポ(CMT-SE3) 23W(0.3W)
- ルーター(WZR-AGL300NH) 4.5W-6.3W
- NAS(LinkStation Mini 1TB) 6.W-8.W
- プレーヤー(VGF-WA1) 5.1W(2.3W)
- プレーヤー(AVLP2/G)
- NAS(LinkStation Mini 1TB) 6.W-8.W
- 空気清浄機(MC75KJ7-W) 4.5W 6.5W 11.9W 21.8W 60.3W
- 扇風機 28.5W 39.1W 48.0W リズムは間欠運転。
- 充電器(携帯電話 W53S)
- 充電器(ニッスイ単3/単4 4本)
- 充電器(Walkera CB100 リポバッテリー) ※もう使ってない
- 充電器(NintendoDS) ※もう使ってない
- 充電器(iPod) ※もう使ってない
- 充電器(Rio SU30) ※もう使ってない
パソコンの消費電力に影響するものを抜き出すと
- パソコン(COSMOS)
- CPU(PhenomⅡX3 720BE)
- メモリ(DDR3 2GiB)
- メモリ(DDR3 2GiB)
- GPU(Radeon X1600)
- HDD(HGST 250GB)
- HDD(Seagate 500GB)
- HDD(WesternDigital 1TB)
- DVDドライブ
- FDD ※ケーブル未接続
- Raidカード(Highpoint RR2302)
- 電源(Seasonic M12 600W)
- 12cmファン(CPUクーラー)
- 12cmファン(ケースファン)
- 12cmファン(ケースファン)
- 12cmファン(ケースファン)
- 12cmファン(ケースファン)
- 10cmファン(VGAクーラー)
- 10cmファン(VGAクーラー)
- 8cmファン(システムファン)
- 8cmファン(システムファン)
- USB接続ゲームパッドアダプタ
- 無線マウスレシーバー(MX610)
ファンが多いが夏は60℃を超える。夏以外は 60%-800rpmで回してる。天井部の 12cmファン 2基のうち片方は止めて塞いでしまっていいかもしれない。3つの内蔵HDDも SSD 1つ(システム,プロファイル,リポジトリ)と HDD 1つ(テンポラリ,システムバックアップ,物置)にまとめられる。最低 3TBないと 1つにまとまらないのが問題なんだけど。SSDも、ゲームや SDKをインストールしてると 100GB以上欲しくなるので高くって買えない。やつらは絶対価格カルテルを結んでる。
@2011-06-14 さっそくワットモニターで計ってみた。
簡単な結果は上のリストに書き込んだので補足をば。
MITSUBISHI MDT243WG
ブライトネスにより 42Wから 98Wの間で変化する。スタンバイは 1.8Wで仕様(2W以下)通り。黒背景で -2W。白背景で +2W。明るさが最重要因子で 50Wの差を生む。コントラストは最大にすると目が痛くなるほどだが 5Wの違いしか生まない。
SONY CMT-SE3
S/PDIF接続。ボリューム 11/30。音のあるなしほぼ関係なく 23W。スタンバイは 0.3Wで仕様(0.3W以下)通り。
PC(COSMOS)
アイドルで 117W。S3で 2.5W。S4で 1.2W。USB接続のゲームパッドアダプタに PS2コントローラを接続してるとアイドルに +3W。x264 1280×720 270MiB/24mの動画を MPC(+ffdshow)でフルスクリーン再生すると +16W。PCSX2-0.9.8でミンサガをプレイすると +42Wから +57W。1コアフルロードで +36W。2コアだと +49W。3コア全部だと +62W。Songbirdで mp3を再生すると +5W。普段の使用形態における消費電力の最頻値は 126Wあたり。ユーザーがアクティブだと 140Wくらいになる。
一瞬で起動するわりにこの PCのスタンバイは電力消費が低い。だがアイドルはもっと下げたい。PC+音+画面でふだん 200W弱をコンスタントに消費している。ファンを 2つと HDDを 2つ減らしても 10Wから 20Wの削減にしかならないだろうな。グラフィックカードをオンボードにするのが単体で一番効果がありそう。まあ、790FX-GD70には載ってないんだけど。CPUとメモリの電圧を下げてみようかな。
NAS(LinkStation Mini 1TB)
ONで 6W台から 8W台。OFFで 3.3W。仕様は平均約10W/最大13W。
プレーヤー(VGF-WA1)
再生が 5.1W。スタンバイが 2.3W。無線ONでのスタンバイは 3.1W。電源断からのスタンバイは 1.6W。
電気カーペット
半面 330W。両面 660W。
Panasonic VIERA 32型 液晶
リモコンでOFFにすると 16.3W(オレンジ色のスタンバイ)。バックライトを変えると 77.7Wと 110Wの間で変動する。
電気料金
定常的に 26.2Wを消費している。21円/kWhだと 376円/月。25円/kWhだと 470円/月。実際はパソコンを結構な時間起動してるので……。
外のメーターが回ってるから居留守だ、ってな古典的推理があるけど、ウチは戸締まりして出かけるときに見ても回ってるよ。普通に。
2011年06月12日 (日) 「ユニコード戦記─文字符号の国際標準化バトル」(小林龍生) なんだウニコードじゃないのか(せめて UNICODEにしてよね)。
最終更新: 2013-11-24T02:49+0900
♪ [SakuraEditor] 選択範囲の復元。
GreenPad, Alphaは復元されない。復元する派にもいろいろある。
メモ帳「UNDOで挿入された文字が選択状態になる」「キャレットは常に選択範囲末尾」
選択状態の復元ではない。キャレットの直前/直後の文字の削除を UNDOしても選択状態になる。
Mery「UNDOで(入力や削除時点での)選択範囲が復元される」「キャレットの位置も復元される」
これ理想。(@2013-11-23 2.1.6から 2.2現在まで、矩形選択後文字入力をアンドゥすると矩形で再現すべき選択が線形の選択になってる。これは理想ではない)
Firefox4のテキストエリア「UNDOで(入力や削除時点での)選択範囲が復元される」「キャレットの位置は常に選択範囲末尾」
惜しい。キャレットの位置が復元されないということは、選択範囲を延長できる方向が問答無用に決まってしまうということ。
SakuraEditorと TeraPad「選択範囲は復元されない」「キャレットの位置は復元される」
最初はメモ帳の動作をまねて CDeleteOpeの UNDOと CInsertOpeの REDOに文字列選択処理を付け加えたらいいかと思ったが、メモ帳と違い挿入や削除の連続した操作がひとまとめにされないのと UNDOバッファが無制限なせいで、連続する一文字削除(入力)操作の UNDO(REDO)がすごくくどい。CDeleteOpeと CInsertOpeの直前に CSelectOpe(新設するクラス)を挿入するのが Meryと同じ挙動になって使いやすそう。(前にも Meryが選択範囲を復元してくれるのが良いと書いた>20091117)
とりあえずこんな感じ。>undo_selectarea.rev1.patch(4.5KiB, 2011-06-11, trunk2@1923ベース)
view/CEditViewへの依存を COpe.cppから view/CEditView_Command_New.cppへ移した。>undo_selectarea.rev2.patch(4.2KiB, 2011-06-12, trunk2@1923ベース)
COpe派生クラスの実装と再生は同じ場所で行ったほうがいいような気がするが確たる考えはない*。view/CEditViewと COpeは COpeの機能から考えたら必然的に仲良しさんだから依存関係なんて気にする必要ないぜ、というなごみんの声も聞こえたが現状はそうでもないのでためらう。今 COpe属はただの構造体として扱われてるので、それに従ってロジックをコンストラクタの中から呼び出し側に移した。呼び出しごとにコピペしてね。
削除し忘れたけど「CSelectOpeがあれば CMoveCaretOpeはいらないかもね。」というコメントは正しくない。CSelectOpeは今のところキャレット位置を保存せず、その場所には適当に選択終点を代入してる。Ctrl+Aで全選択したときにキャレットが動かないので、選択始点・終点とは別にキャレット位置を覚えておかなければいけないが、今はそうしてないので CMoveCaretOpeが必要。
不要にした。>undo_selectarea.rev3.patch(4.9KiB, 2011-06-12, trunk2@1923ベース)
@2011-06-15 矩形選択範囲の削除をアンドゥしたとき
復元された選択範囲が正しくない。文字がない部分に選択範囲を広げられないためだ。それは、COpe属がすべてロジック単位(wchar_t列に対するインデックス)で情報を保存してるからで、その理由はたぶん、折り返し方法が変わっても対応できるようにだろう。TeraPadの readmeか何かで折り返しを変更するとアンドゥ情報がリセットされると読んだことからの類推。どうしようか。選択範囲なんてクリティカルな情報じゃないから、矩形選択時はレイアウト座標で情報を持っておくことにすれば大体はうまくいく、ってことで済ませていいんじゃないだろうか。
CLogicRangeや CLayoutRangeはコピーコンストラクタがあるから共用体のメンバになれない(C++98では)。CLogicRangeを CLayoutRangeに置き換えただけのコピペクラスを作るのか……。上のパラグラフで書いたことだけど、どっちを選んでも一長一短なのだし、矩形選択だからっていつでも選択終点がフリーカーソル状態ってわけでもない。できるだけ余計なことはしない方向で(やめとこ)。でもでも。
@2011-06-15 あれ？「常時選択範囲」って何だ？
選択始点の型がどうして CLayoutPointでなく CLayoutRangeなのか。答えがここにある。
@2013-10-18 矩形選択文字入力のUNDO
矩形選択して選択した全ての行に文字を挿入するということをよくする。ABDと入力・挿入していって、間違えた、Ctrl+Z、Cと操作したいのだけど、Ctrl+Zした時点で矩形選択が解除されてるのでその後の Cはキャレットのある行にしか挿入されない。残念だ。
「残念だ」と
矩形選択挿入/インデントを UNDO/REDOしたときにも選択状態を復元する>undo_selectarea.rev5.patch(13.1KiB, 2013-10-18, trunk2@1923ベース)
テストはしていない(ｷﾘｯ でも自分用の sakuraW.exeには取り込んだので今日から使用中。
「呼び出しごとにコピペしてね」とは上の方で書いたが、CSelectOpe(ロジック単位の方)を作成するヘルパー関数をやっぱり用意した方がいいかもしれない。座標変換が煩雑なので。CEditViewに依存するので COpe.{h|cpp}に置くことはできないが、CViewCommander_New.cppと CEditView_Command_New.cppから利用したい。どこに置けるだろう。CViewCommander_New.cppには Command_INDENTがある。CEditView_Command_New.cppには CEditView::DeleteDataと CEditView::InsertData_CEditViewがある。Command_INDENTから呼び出される CEditView::InsertData_CEditViewで選択範囲の記録ができれば、ヘルパー関数の設置と利用は CEditView_Command_New.cppだけで完結する。それができないのは CEditView::InsertData_CEditViewがお節介にも選択範囲内のテキストを削除してくれるから、インデントを実現するために Command_INDENTが選択範囲をクリアしたり再設定したり小細工を弄する必要があって、Command_INDENT内でしか選択範囲を記録できないからだ。飛躍。エディタ(ドキュメント+ビュー)はプリミティブな操作と情報(検索、置換、選択、キャレット、ステータスバー、ダイアログなどなど)だけを提供して、各種コマンド(インデントとか検索とか)はそれらの操作を組み合わせるスクリプト(カスタマイズしやすい。オプションや好みを反映しやすい。依存されない(されにくい))であってほしかった。という感想は、CEditView::InsertData_CEditViewのようなフルスペックで融通の利かない大きな関数を、一部の機能を無理矢理引き算して利用するような状況から生まれてくる。
UNDO/REDOコマンド関数が Command_CANCEL_MODEを呼び出す部分に書いたコメント
Command_CANCEL_MODE()は主に範囲選択のクリアと選択ロックの解除を行う。 範囲選択のクリア(再描画あり)を行うと CSelect(L)Opeで範囲選択を復元したときにちらつく。 かといって、CSelect(L)Opeが含まれていないときは従来通りクリアを行いたい。 どうするか。再描画なしでクリアする。方法は Command_CANCEL_MODEに redrawフラグを渡すこともできるが Command_CANCEL_MODEの中身をコピペしてフラグだけ書き換えることにする。
範囲選択を解除する必要があるのは挿入/削除操作(CInsertOpe/CDeleteOpe)の都合かも知れない。それらの Opeの再生部分に Command_CANCEL_MODEを移動するのが３番目の方法(選択のキャンセルに伴ってキャレットが移動させられないか注意)。そもそも(出た！)、Viewに挿入/削除を行う範囲を指示するパラメータが、独立した CViewSelectなり CLayoutRangeのインスタンスではなく、ユーザーから可視の選択範囲を意味する Viewのメンバ変数でもあるから、描画のフラグをオンオフしながら選択範囲をあれこれ操作しなければいけないってのが面倒の根本。Viewにはユーザーから呼ばれるものとしてそういうメンバ変数と結びついた関数があってもいいが(※)、その関数が利用するものとしてもう少し粒度の細かい汎用性のある関数が欲しい。※良くない。そういう、メンバと結びついたコンテクストフルな関数をコマンダーに置いて、汎用性のある関数を Viewに置こうという方向で分離が進んでいたのかもしれない。
COpeで一番に改善が必要なのはメモリ確保の戦略だという気もする。1単位の UNDO/REDOのためにひとつの COpeBlkとひとつ以上(４以下くらい。CSelect(L)Opeでサンドイッチすると＋２)の C*Opeのインスタンスが newされるという現実をなんとか。
COpe派生クラス(CInsertOpe/CDeleteOpeとか)の再生の前後でキャレット位置を復元するのは COpe共通のタスクとして実装されている。前後の選択範囲の復元も COpe共通のタスクにしてしまってよいかも。そうすると選択範囲のクリア、範囲の設定、テキストの挿入/削除、範囲のクリアという CInsertOpe/CDeleteOpeの手順と CSelect(L)Opeサンドイッチがひとまとめになって、空間効率も処理手順も無駄がなくなる。派生クラスの種類が減ってサイズが同じになるならメモリ戦略の実体も一本化できそう(まあ、やらないんだけど)。
@2013-10-20 選択モード(SelectingLock)も復元すべき？
そういうのはまとめて CViewSelectのコピーコンストラクタと代入演算子の仕事ではなかろうか。できるかな。そして、もしそういう操作が Viewの外に公開されてるなら CViewSelectのインスタンスを通して Viewの選択状態を変更できる setterの存在が期待されるわけだ(Viewのメンバの CViewSelectのメンバの m_sSelectを直接書き換えるとか主権侵害言語道断)。
* @2013-10-18 COpeに本物のポリモーフィズムを導入するとかいうこと。そうすると COpeの派生クラス(CSelectOpeとか)の新規導入が UNDO/REDOの実行者から不可知のまま行えるようになる。
2011年06月11日 (土) 「右半分は URL表示の避難先として予約されていました(20110416p01)」と書いた Firefox4の、亡きステータスバーの代わり。マウスポインタをよけるばかりに、フォーカスやフォーカスを持ったリンクを隠してやんの。お粗末様。
2011年06月10日 (金) 「「三大」 - みねこあ」新しく三つあげるのはしないけど、既存の三つがいけてないのはすぐわかる。どれも目的でなく手段や結果でしかない。その三つを聞いても OOPが何者なのかわからない。OOPの精神が伝わらない。そういうわけで唯一生き残った「ポリモーフィズム」も俺にはわからない。それは必要に迫られて使うけれど、あえて推す理由は？ 複数のタイプを対象にした目的を同じくする利用側の(ソース)コードを一つにできること？「カプセル化」を言い換えるなら抽象化の他に「自律性」はどうだろう。そして C++のクラスでは、実装の詳細をカプセル化(アクセス制限や不可視化)して抽象を提供することはできるけど、並列実行世界での自律を保つには不十分なんだよね。複数の実行軸に貫かれる C++のインスタンスはいっぱしのオブジェクトではなくしょせん傀儡なのですよ。指向する中心にあるとはいえない。
2011年06月09日 (木) 「Appleに殺されてしまうひと達まとめ、あるいはプラットフォームに依存するということ - yifeの日記」Appleは OSからデバイスからエコシステムまで握ってやりたい放題じゃないか。独占的な立場を利用してるといって OSと分離させることはできないの？それとも印象に比してまだまだ俺みたいに他人事(ひとごと)で済ませられる人も多いのかな。
2011年06月08日 (水) Coders at Workにあった定型質問の一つ。全員が全てのコードを共有し変更するのか、一部の人が所有し変更するのか。オブジェクト指向、クラスベースでやるなら所有者がいた方がいいと思ってる。一人二役でやるにしてもクラスの利用者視点と実装者視点を切り替えることは絶対に必要。クラスが何に依存し何を提供し何を提供しないのかを決めるために。切り替えられないと癒着する。担当者が別だと被使用クラス対使用クラスがそのまま人間対人間のやりとりになって自然に適切な距離が保てそうな。スピードは遅くなるだろうが。
2011年06月07日 (火) 「bron250beta1.7z (148,135bytes) : 次期バージョン向けβ版（\R, \K, \X などに対応）」 このダウンロードサイズはさすがの 7-zip。どのパターンも知らないので調べた。\Rは改行全般(CRLF,CR,LF,VT=垂直タブ,FF=書式送り,NEL=NextLine,LS=LineSeparator,PS=ParagraphSeparator)にマッチする。文字クラスの中では使えない。\Kは、これより左のパターンにマッチしたものをマッチ結果から除外する。戻り読みより使いやすい(けど \Kの左右なんてくくりは簡単にアクセス可能にできるんだからマッチの利用法に制限のある状況専用)。\XはUNICODE複合文字の並びにマッチするとか。基底となる文字＋オプションでウムラウトや丸囲みみたいなものの並び、だろうか。Unicodeに対応した . みたいなもの。ハングルの合成用の字母の並びはたぶん違う(よね？)。### なんちゃって hitEndを付け加えてるからアップデートは少し面倒。### ちゃんとドキュメントあるし。bregonigでは \R=(?>\x0D\x0A|[\x0A-\x0D])だから NEL,LS,PSにはマッチしない(鬼車自体が USE_UNICODE_ALL_LINE_TERMINATORSを定義しないと NEL,LS,PSを改行とみなさない)。\Rだけでもそうだけど \r\Rも CRLFにマッチする。
2011年06月06日 (月) いつからだろう、viewvcがコミットログの rXXXXをリンクにしてくれてる。そういうふうにして参照してきたから嬉しい。
最終更新: 2011-06-06T23:39+0900
♪ [SHJS] 色分けを確かめてみるページを作った。
http://vvvvvv.sakura.ne.jp/shjs/test.html?lang=JavaScript;theme=golden
Firefox 4.0.1でだけ、なんとか、動くことを確認してる。サンプルソースはそのページの初期化スクリプト。JavaScriptの色分け(sh_javascript.js)と Rubyの色分け(sh_ruby.js)だけ、オリジナルの shjs-0.6とは異なる。
2011年06月05日 (日) Cannondale BAD BOYを見つけたのって、たぶん中学生のときから使ってる財布のせいだ。それを何かの折にネットで検索した。2003年頃。
最終更新: 2011-06-05T22:03+0900
♪ [SakuraEditor] 固定長のタイプ別設定って
タイプ別設定一覧ダイアログの見せ方だけで、並べ替えたり可変長に見せかけて(実は上限は30で変わらない)削除・追加を受け付けたりできるよね。
それが行われるとファイルタイプを選択するツールバーボタン(リスト)のアイテムの並びも考えないといけなくなるけど。
2011年06月04日 (土) 「痛いニュース(ﾉ∀`) : 外人 「なんで日本では○が正解でチェックマークが不正解なの？意味不明」 - ライブドアブログ」 スペック表で、あるフィーチャーが存在するかどうかを示すのに✕印が使われていたりすると相当に迷う。もちろんそれは日本のサイトではない。✕や✓はどちらも否定でネガティブで打ち消しだという認識があるからなあ。考えたことなかったけど、○と正しいことの間に文化的なものでない繋がりってないのかな。
2011年06月02日 (木) ATOK2009の補完はいまいち。一度入力した単語は二度と最後まで入力したくないのに、一度は候補に出てきた単語がどんどんどんどん忘れられていく。あと、最長の候補が最初から出てこない。同じ文章を再入力するときでも、末尾の一語だけしか補完できないなんてことがよくある。
最終更新: 2011-06-04T20:36+0900
♪ [SakuraEditor] 文字の幅。代替表示。色分け・強調。
画像の通りに、メイリオUIをインストールしてから日本語文字(Consolasにリンクされたメイリオ)が半角になる。メモ帳もそう。素のサクラエディタでは半角表示の日本語に全角のマス目を割り当てて字間に謎の空白が表示される。画像でそうなってないのは CNativeW::GetKetaOfCharを、文字コードの範囲によらず常にフォントを通して字幅を得るようにいじったから。性能に大いに悪影響を与えるだろう。気にならないけど。で、それだけだと Deleteキーを押したときにキャレットと離れた位置の文字が消えるようなことが起こる。そういうときはキャレットの左側に□で表示された全角空白があったりする。(半角で表示される)全角空白を(半角で表示される)□と表示する view/figures/CFigure_ZenSpaceが□を描画した後にカーソルを無条件で 2進めるために CNativeW::GetKetaOfCharの返す値との間に齟齬を生じていた。文字の幅や高さをコードポイントから決めることはできない。それは代替表示や部分強調も絡めてビューが決めること。