脳log[2011-06-02～]

最終更新: 2011-06-04T20:36+0900

♪ [SakuraEditor] 文字の幅。代替表示。色分け・強調。

画像の通りに、メイリオUIをインストールしてから日本語文字(Consolasにリンクされたメイリオ)が半角になる。メモ帳もそう。素のサクラエディタでは半角表示の日本語に全角のマス目を割り当てて字間に謎の空白が表示される。画像でそうなってないのは CNativeW::GetKetaOfCharを、文字コードの範囲によらず常にフォントを通して字幅を得るようにいじったから。性能に大いに悪影響を与えるだろう。気にならないけど。で、それだけだと Deleteキーを押したときにキャレットと離れた位置の文字が消えるようなことが起こる。そういうときはキャレットの左側に□で表示された全角空白があったりする。(半角で表示される)全角空白を(半角で表示される)□と表示する view/figures/CFigure_ZenSpaceが□を描画した後にカーソルを無条件で 2進めるために CNativeW::GetKetaOfCharの返す値との間に齟齬を生じていた。文字の幅や高さをコードポイントから決めることはできない。それは代替表示や部分強調も絡めてビューが決めること。

最終更新: 2011-06-11T02:05+0900

♪ [SakuraEditor] BugReport/82 - SakuraEditorWiki 正規表現検索の不具合

ここに犯人がいます。言い訳すると、これは見逃してもしかたがないと思うの。(補記だし存在しない機能だし)

 補記 3. Perl 5.8.0と比較して存在しない機能

 + \N{name}
 + \l,\u,\L,\U, \X, \C
 + (?{code})
 + (??{code})
 + (?(condition)yes-pat|no-pat)

 * \Q...\E
   但しONIG_SYNTAX_PERLとONIG_SYNTAX_JAVAでは有効

bregonig.dllは ONIG_SYNTAX_PERL_NGを使ってるみたいだから \Q...\Eは有効。bregexp.dllは \Q...\Eをサポートしていない。

パッチはこれ。>regex_trick_coping_with_qeescape.patch(13.3KB, 2011-06-01)

テストケースはこれから整理する。(パターン内でのコンテクスト×エスケープシークェンス×正規表現ライブラリ)

 @2011-06-02

テストマクロを書いた。>test_regex_trick.js(5.0KB, 2011-06-02)

そうすると、\c\\ みたいなパターンに対応できていないことが新たに判明した*。ちょっとだけ修正したパッチはこれ。>regex_trick_coping_with_qeescape.rev2.patch(13.3KB, 2011-06-02)

手もとでは bcc32で作成した sakura.exe(1.6.6.0 with bregonig-1.45)と VS2008EEで作成した sakura.exe(2.0.2.0 with bregonig-2.02)、ともに Revision 1922ベース、ですべてのテストに成功する。逆に、パッチなしだと期待した通りに失敗する。

 @2011-06-10

掲示板>1571

コミット>r1923

最終更新: 2017-09-15T10:23+0900

♪ [tDiary] 同カテゴリのセクションへのリンクを表示するプラグイン(sections_of_a_category.rb)。

なんというか……ばっちい(だから非公開(書き直すつもりがないので観念した))。だらだら書き下すとこうなるのね、っていう。申し訳のように抜き出したカスタマイズポイントもうまく分離できなかった記憶がある。たんに切り取って別の場所に貼り付けただけだろう、と。svn logを見てみたら 2009年3月に書いたものらしい。最初はセクションごとに表示する仕様で、それだと日記を分断して邪魔なので一日の最後に表示するオプションを付けたとか。……logによれば。とりあえずこの日記(tDiary-2.3.3.20091124, Ruby-1.8.7-p248)では動いてるみたい。

「カテゴリ[……]の他の日記」リンクの URLはこの日記に特有の、最新表示とカテゴリ表示をくっつけたもののだから他の日記では使えないね(それも非公開の理由)。

2007年や 2009年の日記のタイトルが 2011年のこの日記から参照できてるのは「プラグインが自由に日記データを取得できる手段を提供した」恩恵を my-exプラグインが受けているからじゃないかと推測してる。

 @2017-09 書き直した(リンクはそのまま)。

最終更新: 2011-05-30T23:46+0900

♪ www.junkudo.co.jpのショッピングカートが腐ってる。(Firefox4.0で見た場合。念のため)

「カートに入れる」の結果と「カートを確認」の結果、それらと注文処理に進んだときに表示される注文内容が一致しない。カートに入れたはずの本が入ってなかったり、注文に進むとカートに入ってなかった本が表示される。

何となくつかんだからくりはこう。「カートに入れる」ボタンを表示してる商品ページは状態を持ってる。その「状態」に依拠してカートに商品を追加したりカートの内容を表示したりするのだけど、そんな、ページを表示したときのカートの中身やログイン状況に依存した処理が正しいわけがない。こっちは(Amazon以外ではよくある)忘れっぽいショッピングカート対策として、買いたい商品のページを一個一個タブに開いていって、ゲストのカートに追加されないようにログインして、最後にまとめてカートに入れてるんだから。

1. ログインしてない状態で商品ページを表示して、
2. 他のページでログインしてから、
3. (ログインしてない状態で表示した商品ページから)カートに入れた

のが原因ぽい。偉大なる通販サイト Amazon様の解は、ログイン状態をキープし続ける(※)、だ。その上で、個人情報やお金に関する操作の前にパスワードを求める。アマゾンのログイン状態っていうのは OpenIDでも代替できるような、あるユーザーとあるユーザーを見分けるだけのもので特定の個人とは結びついていない(あるいは Windowsの UAC。普段の権限は低くしておいて必要に応じて昇格する)。ねぇ、なんで勝手にログインセッションを切ったりカートをすぐに空にしたりしたがるの？>有象無象のオンラインショップ。www.junkudo.co.jpは、ブラウザを閉じるまで有効って期限を明示してるだけマシだけど。不都合ばっかりじゃない。

※アマゾンのヘルプに

カートに入れたはずの商品がカートに入っていない

2.アカウントにサインインせずに、商品をカートに入れた

この場合は、サインイン後にあらためて商品をカートに入れてください。

ってあるけど、ログイン状態ログアウト状態を取り混ぜてカートを操作してもカートの中身は一貫性を保ってた(おかしくなったのは「カートを見る」ボタンに表示された商品数だけ)。アマゾンはほぼ常にログイン状態であることに頼ってるわけではなさそう。たぶんこういうことだ。

• ログイン状態でのカート(IN)とログアウト状態でのカート(OUT)が別々に存在する。
• カートINはアカウントにひもつけて永続化される。
• カートOUTはブラウザにひもつけて永続化される。(つまりブラウザの数だけ存在する)
• カートOUTの中身は可能なかぎり速やかにカートINに移される。(つまりサインインしたときにってこと)
• サインアウトするとカートINの中身は見えなくなる。(カートOUTの中身は移動済みなのでカートは空になったように見える。サインインすると中身は戻ってくる)

丸善＆ジュンク堂書店も同じような仕組み(ブラウザカートとアカウントカートとその間の商品移動)は持ってる。想定外だったのは、アカウントカートに商品を入れる(cart-account.png)でも、ブラウザカートに商品を入れる(cart-browser.png)でもない変な状態(cart-hatena.png)になるルートが存在したこと(でもそんなんタブでもマルチウィンドウでも当たり前にありうる操作だ)。想像するに、

1. ブラウザカートに商品を入れてみたけど、
2. どういうわけだか(嗤)もうログインしている。(アカウントカートに商品を追加すべきだった)
3. もうログインしているからブラウザカートの中身をアカウントカートに移す機会はない。
4. ログアウトするとブラウザカートの中身は消えてしまう。(ブラウザカートの中身は移動済みで空のはずだった)
5. おまけに、ブラウザカートに商品があるとログインしていてもアカウントカートの中身は見られない。(不適切な依存関係、誤った論理あるいは優先順位の錯誤)

ってところではないかと。

最終更新: 2011-06-12T18:07+0900

♪ [BAD BOY] ホイール、スプロケット、シフター、チェーン交換。

変化など。

 ハブ。SHIMANO WH-T565付属→SHIMANO Deore XT 黒(FH-M775-L)

ディスクローター・マウントを使う予定はないのだけど、黒はシルバーと違って一種類しかない(FH-M770-S相当が用意されていない)のでいらなくても付いてくる。ゴムのカバーが付いてるので想定された使い方。

「素早い駆動力の伝達を可能にするフリーハブボディ:爪がかかるまでの角度を減少」とのことで、空転させるとチチチチチチチチ細かく音がする。しかも音の質が変わっていて前より響く。

 スプロケット。BAD BOY 2007付属(Sunrace M63, 11-32 8-speed)→SHIMANO Deore XT 11-32 9-speed(CS-M770)

裏からの見た目は Sunraceの方が上。曲線で構成された相似形が少しずつ角度を変えて並んでた。

 リム。SHIMANO WH-T565付属→Mavic CXP33

リムの幅が細くなった。ひとまわり、サイドの厚み×2ぐらい。リムテープはシュワルベの水色 18mmが苦もなくぴったりはまった。タイヤも初めてタイヤレバーなしではめられた。空気圧は 80から 90くらい(単位不明)にしてるが、WH-T565のリムテープには何の問題も見当たらなかった。

リムが細くなったのでブレーキシューが届かなくなった。厚みの違うカラーを入れ替えてパッド(舟)を近づけた。そろそろ(アームはそのままで)ブレーキパッドだけでも TEKTROから換えようか。

 スポーク。SHIMANO WH-T565付属(RH straight (2.0) bladed, LH straight (2.3) bladed)→DT Champion 1.8

WH-T565にはやらしい(bladed)スポークが付いてたよ。知らなかった。反フリー側はラジアル組みだし、することはしてたんだ。翻って新しいホイールのスポーク。耐久性を犠牲にして色気をだすつもりはなかったのに 1.8mmになってしまった。2.0mmだったら折れても「寿命かな」で済むけど、意に反して 1.8mmになった以上たぶんに悔いが残るだろう。

 シフター。BAD BOY 2007付属(SHIMANO Alivio SL-M410 8-speed)→SHIMANO SLX SL-M660 9-speed

ワイヤーを巻き取るレバーの軸がハンドルバーから遠くなった。どちらも一気に三段シフトダウンできる仕組みなのだが、SLXの場合レバーが弧を描くというよりどんどん遠ざかっていってしまうため、レバーがハンドルバー手前に飛び出すように取りつけ角度を工夫しても指の長さが足りなくなる。必須の機能というわけではないけど、2.8目盛りくらいまで押し込んでから「やっぱり無理」とレバーを戻したのでは無駄。指の当たる面が凹(Alivio)から凸(SLX)になって非常に押しにくい。俺は摩擦力に頼ったデザインは嫌いだ。巻き取りレバーを近くに持ってこようとブレーキレバーの内側に設置するとリリースレバーとブレーキレバーが一緒に指にかかってしまう。2-wayリリースのためか知らないけどトリガーが大きくなってるし長すぎるし。

2-wayリリースって使い方がわからなかったけど、海外のサイトに thumb-thumb or thumb-triggerって書いてあった。リリースも親指でやろうってことなのか。

 チェーン。BAD BOY 2007付属(KMC 8-speed)→CN-HG50→CN-HG73

CN-HG73への疑惑を晴らしただけで CN-HG50が無駄になってしまった(20110429p01)。コネクトピン(5個入り約600円)を買えばまた使えるけど 8-speedをこれから使う機会はないだろうな。

 リアディレイラー。BAD BOY 2007付属(SHIMANO Deore)

そのまま使える。スプロケットが 8速から 9速になってロー側への移動量が足りなくなっていたので Lと書かれた方のネジを緩めて調整した。

 あぁ

リアディレイラーのプーリーをベアリング入り(無音)にしたい。ブレーキワイヤー(inner/outer)とシフトワイヤー(inner/outer)を新品にしたい。ワイヤーカッター高い。ブレーキの舟をテクトロから換えたい。シューも、雨の日に使うといっぺんになくなってしまう S70C(後ろに使ってる)や、長持ちするかわりにガシガシ リムを攻撃する M70R2(前に使ってる)の代わりを見つけたい。最近はタイヤ(700×28C)をみるたびに太いなぁなんて思ってしまう。ちょっと前まではこれが普通だと思ってたのに。次は Synapse Flat Bar 105に乗りたいぞ。

最終更新: 2011-05-19T13:48+0900

♪ [Ruby] lostと lots of? だとしても informationに lots?

7. In app code, never use force_encoding to convert BINARY data into a particular encoding. By the time you've reached app code, you have lost the information about which encoding is being used. Instead, find where the String came into Ruby, and fix it to set up the encoding based on the information it knows.

アプリケーションコードの場合、バイナリデータを特定のエンコーディングに変換するために force_encoding を決して使わないこと。アプリケーションコードをいじっているのであれば 使用されているエンコーディングに関する情報をたたくさん持っているはずである。 この場合、その文字列がどこからRubyにやってきたかを突き止め、わかっている情報に 基づいてエンコーディングを設定するように修正すること。

いまもって Ruby 1.9のエンコーディングに関するベストプラクティスがわからないので、すごくためになるリスト。7はこう理解した。

(文字列のエンコーディング情報が失われた)末端コードで、(その場で必要とされるエンコーディングに基づいて場当たり的に) force_encodingしないこと。その文字列の来歴をたどって一番根っこ(※ライブラリの修正が必要かも)で正しい情報(※ないのなら慣習に従うか、その不完全なプロトコルを捨てる)に基づいて force_encodingすること。(末端コードで必要に応じて行うのは encodeだったり encode!)

最終更新: 2011-05-16T15:33+0900

♪ モノ、ジ、トリ、……

モノ、ジ、トリ、テトラ、ペンタ、ヘキサ、ヘプタ、オクタ、ノナ、デカ。 理科の教科書の巻末にギリシャ文字と並んで紹介されてたのを何とはなしに覚えてしまった。リンピョウトウシャカイジンレツザイゼンとか寿限無みたいなものか。わりと使われてるので記憶が強化されて忘れられない。

これ、そうかな？ってのを挙げていってみよう。

 一 mono-

モノマー。モノラル。モノリシック。モノポリー。

 二 di-

ジクロロベンゼン。ジアゾ基。ジレンマ。ダイオキシン。ダイオード。ダイアミター？(ダイア・ミーターではなかったのねん)

 三 tri-

tribool. トリプレット。トリオ。トリトン(トリトーンや海のトリトンは違うかも)。トライアスロン。トライリンガル。トライアル……は違うか。

 四 tetra-

テトリス。テトラポッド。テトラパック。ネオンテトラ……はどうかな？

 五 penta-

ペンタゴン。ペントミノ。ペンタックス？

 六 hexa-

ヘキサデシマル。ヘックスレンチ。

 七 hepta-

無い。Septemberとか関係ないかな？無理かな？

 八 octa-

オクトパス。オクターヴ。オクトーバー。オクテットストリーム(1byte=8bitsのときバイトストリームと同じ？)。オクタヴィアヌスはどう？

 九 nona-

無い。nineとか neunの源流っぽいかなー？ 検索したら nonet(九重奏)だって。

 十 deca-

デシリットル？。デケイド(アクセントはデ)。デカスロン。デシマル。

 (番外) 少 oligo-

オリゴ糖。オリゴペプチド。

 (番外) 多 poly-

ポリマー。ポリゴン。ポリペプチド。ポリエチレンテレフタラート(PET)。ポリノミ……アル。ポリリン酸。日本ポリグル株式会社(TV(ガイアの夜明け)と新聞(GLOBE)で見た)。

nona-は使われてるのに気付いてない可能性が高そうだけど、ヘプタの(特徴的な音と比べた)影の薄さときたら。

最終更新: 2011-05-10T18:49+0900

♪ [SakuraEditor] Re: 正規表現による複数行検索対応（簡易版）

 GetCountOfDividedStringW()はいけてない。

どういう関数？>「改行のエスケープシーケンス（'\\'+'n'）で区切られる文字列の個数を数える（WCHAR版）」

使われ方>「複数行指定方法の改善（正規表現パターンの行数とダイアログ設定値の大きい方を採用する）」

• \rに対応していない。
• LFの直書きに対応していない。(CRの貼り付けはできなかったのでとりあえず LFだけ)
• 量指定子に対応していない。
• \x0D\x00\x0A\x00や \x{0D}\x{0A}に対応していない。
• [\s\S] や \s, [\w\W] や \W, . (sフラグONのドット)に対応していない。

これだけ対応していないなら「正規表現による」というより、\nというエスケープシーケンスにだけ対応した普通の検索といったほうが当たってる。正規表現ライブラリに今以上の機能(hitEnd)を求めないのなら、これが最大限度の対応なのかもしれないが……。GetCountOfDividedStringWには期待せず、ダイアログで 100とか設定しておけば大体はうまくいくのかもしれない。

 CMultiLineSearch::GetCompensationLengthには脱帽。

どういう関数？>「０文字マッチや改行文字の途中を考慮した置換文字数の補正値を取得する」

なぜ必要？>ドキュメントの操作がビュー経由でしか行えないため、ロジック単位で行った検索をレイアウト単位に変換してから置換を実行しなければいけない。置換関数の中ではレイアウト単位をロジック単位に変換して……といったことがもちろん行われるわけで……ムキー、ってなことを 20100907p01.03に書いた。

とりあえずロジック単位で置換範囲を指定できる置換関数をどこかに作ろうとして、20100709p01の複数行置換の実装は止まっている。CMultiLineSearch::GetCompensationLengthを使うアプローチはこれまでのやり方を踏襲するもので、置換範囲と置換文字列をレイアウト単位境界にそろえてから置換関数を呼び出す。計画倒れよりできあがってる方が偉い。