まぁ、DelphiというかBDS 2006の日本語版アップデートパッチが出そうだったので、
出てからもう一度ではなく、出るまで待ったということもある。
今朝出てたから、置換の高速化（痴漢の拘束か by ATOK）がなくてもやろうと。
その高速化だが、やってみたらもう驚くほど速くて、やれば出来るじゃんって感じ。
いや、やってみたらと言っても、さっき考えてさっき作ったばかりであって、
全くのデバッグ不足のままにリリースと言うことになる。
でもたぶんほんのわずかな部分の変更だから大丈夫だろうと高をくくる。
真魚は極端に置換が遅いからこそ、一括でやらせるときは速い置換が必要だが、
TEditorなんか、それほど置換が遅くないので、高速な置換を別に作る必要がない。
よって、こういう部分を作ったのは初めてである。
初めてだからこそ予期せぬバグは確かに怖いけれども。
それに、一括でやっちゃうと言うことは、しおりを破壊することにもなる。
これはたぶんつっこまれるかも知れないが、仕方ない犠牲としたい。

アップデートパッチには、真魚などの文字列を扱うアプリには重要そうな変更がある。
空の文字列と、文字列自体がヌルなのを区別するっていう仕様変更。
それって今やる物じゃなくて、2005→2006でやるか次回でやれよな。
.NETでの仕様にあわせたそうだが、あたしゃ.NET慣れしてるので大丈夫だろうけど、
なにぶん、何もかもを一人で書いてるわけじゃなく、パクリ部分があるので、
この仕様変更で、どこか深い部分にバグが生まれていないことを祈る。
一応、英語版の発表があった時点で軽く確認はしてるが、十分ではないだろう。

あと、鬼車がバグ修正とかでバージョンアップしている。
真魚に添付しているDLLのバージョンは、真魚本体のバージョン情報で見れる。
前回のバージョンはまだ2005とか書かれてたけど、2006になったみたいね。
ブログみてみたら、UTF-16に対応して倍くらい遅くなった見たいに書いてある。
そうか、速いから鬼車使ってたのに、これでもまだ倍も遅いのか。
TRegExprも、ユニコードは遅いって書いてたけど、関係あるんだろうか。
すくなくとも鬼車はTRegExprの何倍かのスピード出てるから大丈夫だが。

でだ、Delphiのバグでやる気は失せてるんだが、やりたいことはある。
一つは、フォントの履歴にフォントサイズまで含めたいって事。
これを今やらない理由もあって、これも話せば長くなる。
あと、ながーい文字列を再変換させると、FEPがギブアップする問題をどうするか。
先日Visual Basic 2005をちょっといじったので、色分けしたくなってる事。
やろうと思えばToDoは尽きない。

Delphiが今、ひどい状態だ。
今朝、アップデート2が出ていたので、パッチ当てたのだが、
そのパッチのせいではないと思うんだよ。
今日は特にひどいけど、パッチ前から何度かそういうことがあったし。
いろんなやる気が失せるほど、Delphiに侮辱されている。

今やってる作業は、全置換を行う関数を新たに一つ作り、
置換を行う関数から、必要なときに全置換へ移行するというような所だ。
おそらく、今この部分を編集するのが問題なのであって、
同じプロジェクトの別の部分をいじるのは問題を起こさないかも知れなのだ。
何をすれば症状が出るのか、特定できないのでさらにまいっているのだが。
その、新たに作ってる部分だが、ちょっと文字を打っては裏で何かやられている。
1文字目はすぐにタイプと同時に表示されるが、2～3文字目は数十秒後。
補完とかしたくてもしばらく待たないと受付けてくれない。
通常にタイプしててもこの調子なのに、タイプミスすると直せるのが数十秒後。
このストレスはあり得ない。
10行くらいの部分を、try..finallyで括ったので、インデントしようとするが、
スペース入力とカーソル移動だけなのに、全部やるのに何分かかるんだ。
既存関数に渡す引数の意味を忘れたので、定義部分を表示して確認しようと、
右クリックしてポップアップメニューは表示されても、
そのポップアップメニューにフォーカスが行かないまま、スワップを待ち続ける。

タスクマネージャーで見てみると、使用メモリは300MB以上。
仮想メモリは、500MB以上になっている。
スワップが落ち着いた状態に戻っても、150MBは使用している。
起動時は5MB/50MBという、あり得る程度のメモリ使用量だが、
真魚のプロジェクトを読み込んだ時点で110MB/130MBという驚愕の数字。
デザイナの表示やデバッグ実行ではさほど数字は上がらないが、
コードの編集や、編集の補助機能が動くことで、一気にメモリが消費される。

あまりにとろくて、やらなきゃいけないことがやりたくなくなっている。
良く確認しながらやらないとバグを含む確率が上がる作業なわけだから、
いちいち作業をストップして気が散るのも迷惑だ。
Delphiって、せっかく最近は落ちないようになったのに、今度はこれかよ。
つーかもう、Delphiやめたい。

いやたぶんね、真魚を開発して行くには、現在のメモリでは足りないのだろう。
最近は2GBとか当たり前なのに、ウチはまだ512MBだもんな。
でも、256MBしか乗ってない嫁のVAIOをもターゲットにした真魚を開発するのに、
512MBの開発環境でストレスがたまるというのはどうなのかと。

今回のように、他に影響与えない部分をちょこっといじるのなら我慢できるが、
もっと大がかりな変更したりするときはこのままじゃまずいよな。
やっぱり巨大な変換テーブルの持ちすぎだろうか。
それとも素人特有のシンプルじゃないコーディングがまずいのか。
あるいは、メインフォームのユニットなので、それだけで4500行あるからか。
いや、これは仕組み上、大きくなるのは避けられないのだがね。

こんなDelphiじゃ、真魚というプロジェクト自体、もう潮時なのかも知れない。
あぁ困った困った。

久しぶりにどう動けば正しいかの話だが、意見は割れそうだ。
あくまで、真魚にとっての正解を考える。

まず、このような文章がある。

abc
abc
abc

そして、正規表現で、￥ｎ｜＾ａｂｃ(半角で)を、defに置換させたとする。
これは、改行、または行頭のabcにマッチするわけだから、
改行と行頭のabcが繰り返される上記の文章では、全部がマッチし、

defdefdefdefdef

に置換されるのが正しいのだろうか？いや、真魚ではこれは不正解だ。
まず、最初のabcは、行頭なので、置換はされるだろう。

def
abc
abc

次に、改行もマッチして置換される。

defdefabc
abc

すると、二行目の行頭にあったabcは、一行目に移動して行頭でなくなっている。
そのまま続けると、

defdefabcdefabc

となる。これが真魚での正解だ。

今、真魚に一括で高速な置換をやらせる部分を作るにあたり、
どこまでを省略可能なのかを検討しているわけだが、
Undoとか改行とか色分けとかの処理は省略できても、
やはり上記のような問題で、開けたり詰めたりの作業はマメにやるしかないな。