出てからもう一度ではなく、出るまで待ったということもある。ATOK)がなくてもやろうと。その高速化だが、やってみたらもう驚くほど速くて、やれば出来るじゃんって感じ。デバッグ不足のままにリリースと言うことになる。ほんのわずかな部分の変更だから大丈夫だろうと高をくくる。真魚は極端に置換が遅いからこそ、一括でやらせるときは速い置換が必要だが、TEditorなんか、それほど置換が遅くないので、高速な置換を別に作る必要がない。よって、こういう部分を作ったのは初めてである。予期せぬバグは確かに怖いけれども。それに、一括でやっちゃうと言うことは、しおりを破壊することにもなる。これはたぶんつっこまれるかも知れないが、仕方ない犠牲としたい。アップデートパッチには、真魚などの文字列を扱うアプリには重要そうな変更がある。空の文字列と、文字列自体がヌルなのを区別するっていう仕様変更。それって今やる物じゃなくて、2005→2006でやるか次回でやれよな。.NETでの仕様にあわせたそうだが、あたしゃ.NET慣れしてるので大丈夫だろうけど、なにぶん、何もかもを一人で書いてるわけじゃなく、パクリ部分があるので、この仕様変更で、どこか深い部分にバグが生まれていないことを祈る。一応、英語版の発表があった時点で軽く確認はしてるが、十分ではないだろう。あと、鬼車がバグ修正とかでバージョンアップしている。真魚に添付しているDLLのバージョンは、真魚本体のバージョン情報で見れる。前回のバージョンはまだ2005とか書かれてたけど、2006になったみたいね。ブログみてみたら、UTF-16に対応して倍くらい遅くなった見たいに書いてある。速いから鬼車使ってたのに、これでもまだ倍も遅いのか。TRegExprも、ユニコードは遅いって書いてたけど、関係あるんだろうか。すくなくとも鬼車はTRegExprの何倍かのスピード出てるから大丈夫だが。Delphiのバグでやる気は失せてるんだが、やりたいことはある。一つは、フォントの履歴にフォントサイズまで含めたいって事。これを今やらない理由もあって、これも話せば長くなる。あと、ながーい文字列を再変換させると、FEPがギブアップする問題をどうするか。2005をちょっといじったので、色分けしたくなってる事。やろうと思えばToDoは尽きない。コメントするDelphiが今、ひどい状態だ。今朝、アップデート2が出ていたので、パッチ当てたのだが、そのパッチのせいではないと思うんだよ。今日は特にひどいけど、パッチ前から何度かそういうことがあったし。いろんなやる気が失せるほど、Delphiに侮辱されている。置換を行う関数から、必要なときに全置換へ移行するというような所だ。同じプロジェクトの別の部分をいじるのは問題を起こさないかも知れなのだ。何をすれば症状が出るのか、特定できないのでさらにまいっているのだが。その、新たに作ってる部分だが、ちょっと文字を打っては裏で何かやられている。1文字目はすぐにタイプと同時に表示されるが、2~3文字目は数十秒後。補完とかしたくてもしばらく待たないと受付けてくれない。通常にタイプしててもこの調子なのに、タイプミスすると直せるのが数十秒後。このストレスはあり得ない。10行くらいの部分を、try..finallyで括ったので、インデントしようとするが、スペース入力とカーソル移動だけなのに、全部やるのに何分かかるんだ。右クリックしてポップアップメニューは表示されても、そのポップアップメニューにフォーカスが行かないまま、スワップを待ち続ける。タスクマネージャーで見てみると、使用メモリは300MB以上。仮想メモリは、500MB以上になっている。スワップが落ち着いた状態に戻っても、150MBは使用している。真魚のプロジェクトを読み込んだ時点で110MB/130MBという驚愕の数字。デザイナの表示やデバッグ実行ではさほど数字は上がらないが、コードの編集や、編集の補助機能が動くことで、一気にメモリが消費される。あまりにとろくて、やらなきゃいけないことがやりたくなくなっている。良く確認しながらやらないとバグを含む確率が上がる作業なわけだから、いちいち作業をストップして気が散るのも迷惑だ。Delphiって、せっかく最近は落ちないようになったのに、今度はこれかよ。Delphiやめたい。いやたぶんね、真魚を開発して行くには、現在のメモリでは足りないのだろう。最近は2GBとか当たり前なのに、ウチはまだ512MBだもんな。256MBしか乗ってない嫁のVAIOをもターゲットにした真魚を開発するのに、512MBの開発環境でストレスがたまるというのはどうなのかと。今回のように、他に影響与えない部分をちょこっといじるのなら我慢できるが、もっと大がかりな変更したりするときはこのままじゃまずいよな。巨大な変換テーブルの持ちすぎだろうか。それとも素人特有のシンプルじゃないコーディングがまずいのか。メインフォームのユニットなので、それだけで4500行あるからか。いや、これは仕組み上、大きくなるのは避けられないのだがね。こんなDelphiじゃ、真魚というプロジェクト自体、もう潮時なのかも知れない。コメントする久しぶりにどう動けば正しいかの話だが、意見は割れそうだ。真魚にとっての正解を考える。このような文章がある。abcabcabcそして、正規表現で、¥n|^abc(半角で)を、defに置換させたとする。改行と行頭のabcが繰り返される上記の文章では、全部がマッチし、defdefdefdefdefに置換されるのが正しいのだろうか?いや、真魚ではこれは不正解だ。最初のabcは、行頭なので、置換はされるだろう。defabcabc次に、改行もマッチして置換される。defdefabcabcすると、二行目の行頭にあったabcは、一行目に移動して行頭でなくなっている。そのまま続けると、defdefabcdefabcとなる。これが真魚での正解だ。今、真魚に一括で高速な置換をやらせる部分を作るにあたり、どこまでを省略可能なのかを検討しているわけだが、Undoとか改行とか色分けとかの処理は省略できても、やはり上記のような問題で、開けたり詰めたりの作業はマメにやるしかないな。