最終更新: 2018-06-06T13:48+0900
テキストエディタ Mery はシングルプロセス型のタブエディタだから、svn や git のコミットメッセージを編集するためには工夫が必要らしい。工夫でなんとかなるということである。
このプラグインは C# で書かれてる。秘訣がこれ>「.NETプラグイン開発キット - MeryWiki」 DotNetLib.dll のソースが読みたいよね、ていうかこれもユーザー投稿なの？
で、プラグインを Mery2.6 の 64ビット版で試してみたんだけど、動かないのはここに書かれていた通り>「【要望】Gitの編集」
再コンパイルするだけで動くんじゃないかという気もするんだけど C# はさっぱりなので、思いつきで名前付きパイプを使った方法を試してみた(プラグインもパイプも初めて！)。「プラグインソフトウェア開発キット」の C/Basic プラグインを骨組みにして必要なところだけ書き換える感じ。
.NET プラグインの方のヘルプには OnEvent を上書きするとアイドルイベントまで捕まえてしまうからできるだけ個別のイベントハンドラを実装するようにって書いてあるんだけど、C プラグインのスケルトンには OnEvent ハンドラしかなかった……。
こうなりました>MeryRelay2.zip(あとの方に新しいのがある)。64ビットコンパイラってただで手に入るのかな。Vista 時代の SDK には付属していて、それしか手元にないんだけど。
ポイントはただひとつ。PIPE_NOWAIT は罠であるということ。PIPE_WAIT と FILE_FLAG_OVERLAPPED を指定すれば非同期に待てる。雰囲気で PIPE_NOWAIT を指定すると待てども返ってこない。
あ、パスの区切り文字の置き換えを忘れてる(でも試したら Mery2.6は / 区切りに対応してるぽい)。それとタスクマネージャーでコマンドライン列を表示するとわかることだけど、Mery.exe のコマンドラインなのにその内容が「"MeryRelay2Exe.exe" "file.path"」みたいになってるはず。少なくとも Vista ではそう。Mery.exe が気にしてないみたいだからいいかなって、最大限に手を抜いた。そんなわけでコマンドラインは一切操作も解釈もしていないので複数ファイルのドロップもできるんだけど、どのファイルがひとつだけ選ばれて監視されるかは運です。最後にもうひとつ。短い時間で連続してリレイ経由でファイルを開くと監視が漏れるかもしれない。ていうかたぶん漏れる。バックアップ中とかウィルススキャン中だと短時間でなくても漏れるかもしれない。
結局ロックファイルでシリアライズしつつ中身で情報をやりとりするのが一石二鳥なのか？ くやしいので Mutex にする。zip を差し替えておいた。これで次のようなバッチファイルにも対応する。
start "" "MeryRelay2Exe.exe" a.txt start "" "MeryRelay2Exe.exe" b.txt start "" "MeryRelay2Exe.exe" c.txt start "" "MeryRelay2Exe.exe" d.txt start "" "MeryRelay2Exe.exe" e.txt start "" "MeryRelay2Exe.exe" f.txt start "" "MeryRelay2Exe.exe" g.txt
無駄にクラス化するなど>MeryRelay2_class.zip<不細工な車輪を再発明してでもDLLサイズを縮めるなど。
依然こういうバッチファイルには対応しないはずだ。
start "" "Mery.exe" a.txt start "" "Mery.exe" b.txt start "" "Mery.exe" c.txt start "" "MeryRelay2Exe.exe" d.txt start "" "Mery.exe" e.txt start "" "Mery.exe" f.txt start "" "Mery.exe" g.txt
正しく d.txt を開いていたタブが閉じられるのを検知できるかは運次第。ここにはトレードオフがあって、これに対応しようとするとコマンドラインを解釈せざるをえないが、Mery が解釈するコマンドラインに対していかなる前提も置きたくないというのがある。それで今のように、最初に応答したタブと無差別に関係を結ぶようになってる。
ところで本家 MeryRelay.exe は最初のバッチには対応しないけど次のバッチには対応している。自分のと逆である。
最初に INVALID_HANDLE_VALUE があり、その次に NULL があったと。INVALID_HANDLE_VALUE が 0 でないから、0 が有効なハンドルになることがあるのかと疑っていたが、実際のところどうなのだろう。INVALID_HANDLE_VALUE を使う関数の方が古いらしいから、ないとは言えないよね。ハンドルクラスのデフォルト値・無効値の扱いに困るんだよ。ないと言って。
「INVALID_HANDLE_VALUE and NULL - Google グループ」
同じ疑問を持つ人が。そして、CloseHandle を実装する側から考えてみると値が NULL で有効なハンドルはありえないでしょって答える人と、これまでの経験で問題がなかったとしてもドキュメントに沿った慎重な振る舞いを勧める人と。
俺はもちろん、問題が生じるまで単純な対処法を選ぶ>20180308。
従来.netのDLLをアンマネージから呼び出すためにはCOMとしてレジストリ登録して、COM経由で呼び出すのが一般的ですが、当然Meryからはこのような呼ばれ方はしません。
これを解決するために、アンマネージのブリッジ用DLL(C++で書いてるみたいです)があって、これがMeryから呼ばれる。
ブリッジDLLにはMeryから呼ばれるインターフェイスがすべて実装されていて、呼ばれたらマネージDLLに転送して、そちらで目的の処理を実行。 という手順をとっているようです。
「再コンパイルするだけで動くんじゃないかという気もする」とは書いたけど .Net には CPU を限定しない AnyCPU ビルドというのがあるらしく、ks さん本人のものと思われるブログでもそれが言及されていた。なのにどうして 32ビット版限定プラグインになってしまうのかな、と。その種明かし。
MeryRelay プラグインには MeryRelay.dll (160 KB) と MeryRelay/MeryRelay.dll (6 KB) という２つの同名の DLL ファイルが含まれていて、たぶん大きい方がアンマネージドのブリッジであり、32 ビット版 Mery からプラグインとして見えるもの。
svn 連携、git 連携にしろプラグイン作成にしろ、いろいろ方法があるもんですね。
暴走を阻止するため、全てのループに回数上限を設定する」■これは自然と意識してる。タイムアウトを設定せず無限に待つとか、条件が成立するまで無限ループするとか、ループの終了条件が32ビットなり64ビットなりの表現のうちのひとつだけであるとかは、書いていて不安になる。
最終更新: 2018-04-28T11:31+0900
sourceforge.net の変節は耳にしてる。当時は、そのうち osdn.net へ移行するんだろう、そうしたら自分のアカウントは無効になるからパッチ投稿だけ継続しようか、音沙汰のない人間にリポジトリの鍵を預けっぱなしにしておくなんてリスクだからちょうどいいんじゃないの、って気楽に考えていた。せめて支持は表明すべきだった。正当性をもった移行だと認められて人が付いてこなければ、結果的に個人フォークや不成功に終わった乗っ取りと同じことになるのだから。
移行先は名前が挙がってる GitHub より osdn.net の方がずっといいだろう。GitHub は開発者にはおなじみだろうが、掲示板が動かないことにはバグ報告も質問も途絶えてしまう。ただの利用者に英語の画面を使わせたり発言するのにアカウント登録を求めたりするのは、門前払いに等しい行為だよ。
いくつか問題が挙げられてるが、移行してからなんとでもなることを無視すると、究極的には人の問題が残る。開発者の問題が。すでに活動していない人であっても、かつて主要な貢献をしたその名前がリストされていることが、プロジェクトの正統性を裏付けるという側面があるだろう。２年前は誤解していたけど、今こうしてほとんど人が去ったプロジェクトの現状を目の当たりにすると、お願いして名前を掲載させてもらいたい立場であることがわかる。この現状で過去を清算するような移行は、プロジェクトにとって致命傷になりかねない、と思う。
開発の活発化を企図するなら、個人個人でリポジトリを持って自由にコミットできる Git の採用が必要だと思う。登録された開発メンバーという意味ではなく開発ができる利用者個人という意味ね。git svn コマンドのおかげでプロジェクトのリポジトリが Subversion であっても自分の Git リポジトリを持てることを考えると、よりカジュアルにフォークできる GitHub 上の Git リポジトリが本当に必要なものだという気もする。GitHub にプッシュされた私家版パッチは見えるし、Pull Request もあって本家取り込みもやりやすいだろう。
こうなると osdn.net への移行がわからなくなる。けどたぶん考える前に行動することが必要なんだと思う。sourceforge.net に留まり続けるプロジェクトは見捨てられたプロジェクトなんだと、俺はもう受け取るようになっている。移行してしまえば、少なくともそう決めてしまえば自分はついて行くし(「こっち来んな」って？)、チケットの移行など手を動かすこともするんだけど、問題は自分が「ついて行く」人間であって引っ張っていく人間ではないことなんだな。sourceforge.net のサクラエディタプロジェクトに対して自分ができることって svn commit だけだというのもあるし。