1. mumurik
  2. xyzzy

Wiki

Clone wiki

xyzzy / 雑記

2012/09/10

21:37

先ほど当初xyzzy関連作業を終えるフラグにするつもりだった受託案件の終了の連絡が来た。 この案件の間だけ家のマシンをIPリーチャブルにしてたからなんだけど、最近はあんま更新してないので、逆に常時環境が無くなってもb-mobile等でどうにか運用出来るレベルなので、このまままったり続けようかなぁ、とか思っている。

ついでに0.2.3.12リリースした。あとでアナウンスしなきゃなぁ。

2012/09/06

18:33

マージ作業終了。少しつついて平気そうならアナウンス。 今回は変更少ないんで楽っすな。

2012/08/16

22:09

多少つついたが問題無いのでこのままで行く事に。

最近は0.2.2系列についていく以外の作業をしていないので、Wikiやリリースの運用もそのレベルに合うように簡素化。 手抜きでついていく作業だけを当面は続けていきます。

2012/08/12

23:55

現状だとdev channelとか分けるのはオーバーエンジニアリングと思い、直接リリースチャンネルに投げる。 ただアナウンスする前に少しつついてみるかなぁ。

2012/08/04

20:12

ちょっとした事情で別マシンにマージ環境を作る事になったので手順をメモしておく。

  1. git remote add xyzzy-022 https://github.com/xyzzy-022/xyzzy.git
  2. git pull xyzzy-022
  3. git checkout xyzzy-022/master
  4. git checkout -b xyzzy-022-mirror (たぶん上とくっつけるべき)

で、github for windowsから続きは出来そう。 コンフリクトは

 git status

でチェックしつつエディタで直したりgit rmしたり

git checkout --ours src/version.h

とか

git checkout --theirs etc/Makefile

したりしてconflictを直してgit addしてcommit。

そしてVS 2010 Expressが入ってないので続きはまた今度。

2012/07/28

18:24

あまり更新するネタも無くなったのと、xyzzy使う事も減ったので以後は0.2.2系列についていくだけにしようかな、と思います。 そのうちまた何か入れるかもしれないし何かPRがくれば取り込みますが。 という訳で保守フェーズに移行。Wikiも直すか。

2012/07/09

21:20

一か月ぶりくらいにマージするか、と思ったら手順忘れてる。 とりあえずxyzzy-022をpullして、ローカルとマージでマージして、 コンフリクトはコマンドラインからgit mergetool、でいいんだっけか。

そしてVSからビルドしてbytecompile.bat実行してrun_test.bat実行していろいろ直した後にバージョン番号上げてまたリビルドしてcreate_package.batしてアップロードしてlatest-xyzzy-dev-info.lにlocal-data-fileを設定

(require "ni/setup")
(setq ni::*local-data-file* (merge-pathnames "..\\..\\GitHub\\xyzzy\\latest-xyzzy-dev-info.l" (si:system-root)))

してni::local-app-add

2012/06/09

11:58

ようするにIFileDialogCustomizeをQIすれば良さそう。 問題はこのレベルのCOMなコードをどう書くか、って所か。WTLがありゃ書けるが… 手でQueryInterfaceしたりするのは泣きそうだなぁ。

dual interfaceがあったらlispレイヤーでやってしまいたい気もするが…とみていくとIModalWindowがIUnknownの下らしい。 しょぼーん。

この位は素のC++で書くかなぁ。

11:32

ファイルダイアログ直そうぜ、という話があるので、直すかなぁ。

https://github.com/xyzzy-022/xyzzy/issues/308

multiframe特有な部分は無いので0.2.2に入れてpullする事に。こっちの方が一回conflictのresolveが少なくて済むので。

まずは前提知識。

http://www.codeproject.com/Articles/16678/Vista-Goodies-in-C-Using-the-New-Vista-File-Dialog

で、xyzzy的にはdialogs.ccのFfile_name_dialogを見ておけば良い。 上記ページを参考にすると、lpfnHookとTemplateNameが問題。

lpfnHookはfile_name_dialog_hookでOFN構造体をユーザーデータに突っ込みwndprocを委譲してる。 wndprocはinit, WM_SIZEで何か、DESTROYでget_result()、あとWM_PRIVATE_SIZEとかいうのをハンドルしてる。

lpTemplateNameは複数選択かどうかで何かリソースを変更してる。

さて、どうしたもんかね。 見た所拡張性は大して無さそうなのでここを差し替えても後方互換に問題は無かろう。

フラグを見てる分にはencodingとeol回りのドロップダウン以外はどうって事無さそうだが。 explorerってのは良く分からんモードなので以前のコードがそのまま走るようにしておくのが良かろう。

encodingとeolを足せたら9割終わりだな。まずはテンプレートの差し替え方法を見てみるか。 まずは小さく始められるように、メニューからのオープンのケースだけ対応してみよう。

2012/05/25

19:08

最近はひたすらNAXELにパッケージ追加するだけなのでここに書く事もほとんどない日々です。

今日はGitHub for Windowsを使ってみてはまった事とか。

既存のローカルレポジトリはsshのkeyがどうとかいってpushもsyncも出来ないので取得しなおし。 ここでbatファイルが全てlfで落ちてくる、という罠にはまってる。詳細はおいとくがこれは我々のプロジェクト側の事情。

で、pushしたらうまくいかないからcommand lineで直してくれよ!とかいう感じのメッセージが出てコマンドラインが立ち上がる。 そこからpushするとこんな感じ。

$ git push origin master
error: unpack failed: index-pack abnormal exit
To https://github.com/mumurik/xyzzy.git
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to 'https://github.com/mumurik/xyzzy.git'

良く分からないのでぐぐって

$ git repack remote/origin/master

としろ、というページを見つけたのでやってみるも変わらない。

うーむ、とりあえずgithub for windowsの使用は諦めるかなぁ。

2012/05/16

0:29

ちょいとした空き時間があったのでちまちまNAXELにパッケージ追加。 動かないlispパッケージ一覧に報告のあったreference.chmはどれの事かさっぱり分からんなぁ。

カスタム版はそろそろ終わりやね。

普段はこの手のかったるい作業とかはやんないんだけど、今回はこういう所での頑張りがテーマなので力の限り頑張る事にする。 もう全部揃えるぜ!くらいの勢いで。

2012/05/14

21:54

今日はちまちまとNAXELへの追加作業。簡単に作れるカスタム版で現在分かってるのは残り6個。 NAXELに追加されているライブラリ数は現在64個。大分形にはなってきたかな。 ぼちぼちこうやって時間を見つけて足していくつもり。

とりあえずカスタム版が揃ったら次はniじゃなかったのをniにしていく、というのをやっていこうかなぁ、と思ってる。 lzhやtgzの物は自分で統合アーカイバからdll入れれば今のままでも他所から入れる事は出来るので後回しでいいか、と。 むしろこれまでniじゃなかった奴をniにしていってしまう方が作業のdupも無いし、価値も多い気がするので。

404な奴でライセンスクリアな奴からやってくとかの方がいいんだけど、そんなリストなんて誰も持ってないだろうしなぁ。 持ってたら下さい。

こんなペースでやっていけば、全部一人で揃えられちゃいそうだなぁ、という気がしている。 元のniはdepend先が別siteな場合が多かったので勝手に解決はしなかったんだろうけれど、 全てNAXELに入れば勝手に解決してしまって良い気もする。 その辺はすぐ書けるし、私じゃない人が書いてPRくれてもいい気がするのでしばらくほっとくつもり。

updaterNAXELで、仕組みとして最低限必要なのは揃ったと思っているし、 使っててもこんな感じかなぁ、という仕上がりになりつつある。 後は目標とするexperienceまでちまちま作業したら、もちっと宣伝するかなぁ。

2012/05/08

22:17

問題無さそうなのでRC1をリリース、といっても中ほとんど変わらんけど。これで0.2.3.8は正式リリースだろうね。

リリースノートは今回はどうしたもんかね~。 マージの過程でいろいろ想定外な事があって、結局develop側ブランチのその時のlatestをマージしてしまったので、 何もキリが良くないんだよなぁ。

次回以降はmasterのみをマージするので次回からは向こうのりリースノートコピペでいいんだが。

しかもetc以下の扱いが悩ましい。updaterで更新されない分はやっぱり更新されてない、というのが正しいと思うのだが。 もう少し落ち着くのを待ってNAXELに登録、が基本方針なので、そこまではリリースノートには入れないんかなぁ。

2012/05/06

1:08

ようやくαリリースだぁ。今回は難産だったなぁ。 これでようやく0.2.2系列の状況は理解出来たし、今後揃えていくのに必要な事も理解出来た。

0.2.2系列がガンガンいじってる間は追っかけ重視でいいかもなぁ。 ちょうどこっちも別件で忙しいし。 という割にはxyzzy関連作業は結構やってるが。

機能的な変更とかfixはほとんど638氏がやってて自分はなんもやってないっす。 サンクス。

こっちはひたすら泥臭い作業をいろいろやっておりました。 結果的にはrebaseせずに素直にpullした後revert commitしていけばよかったなぁ、という結論だけれども、 最初にそれを理解する方法が無かったんで仕方ない。

次回以降はマージして一部revert、というフローで回せるとおもいます。 現状はdevelopブランチをマージしちゃってる気もするので、次回以降はmasterのみを追っかけます。 今回はいろいろ錯綜しててビルド通すので精一杯だった。

とりあえず次回のリリースは今回のマージ分の整備とNAXEL拡充かなぁ。 仕組み的なのはだいたい片付いて来た感じだ。

2012/04/30

16:41

update_version_describe.batでgitがパスに無い、と怒られる。まぁないんだけど。 PROGRAM_VERSION_DESCRIBE_STRINGが定義されるっぽい。 たぶんdev branch側でのバージョン識別子って所だろうなぁ。

この辺のビルドの運用固有の仕組みとどう共存していくかは悩ましいね。 もちろんこっちはこっちでbuild event修正してcommitしてしまえばいいんだけど、 それだとvcxprojのフォルダ移動した時とか不要な手作業が増えてしまう。

update_version_describe.batを差し替えかなぁ。これならvcxprojの移動には対応出来る。

16:31

なんかここのwikiの日付が変に認識されるようになったなぁ。このページの日付が変なhtmlになってる気がする。まぁいいや。所詮雑記だし。

ようやく時間取れたので作業再開。ビルドは無事通して、少し触った感じ良さそうな所まで来た。

次に来てるPRを一通り調べて取り込んでいる最中。とりあえず今週前半にアルファ出して叩いてRC出してリリース、という感じで週末には出せそうだなぁ。 直す気だったDEPもPR来てて内容も良さ気だし、よしよし、という感じ。

とりあえず0.2.2系の取り込みをちゃんと出来る体制を整えて一回リリース出してみたい。 向こうの変更も当初思ってたよりアクティブなので、しばらくはついていく事に集中して、他の変更はせんでもいいかもしれない。

それにしても638氏は結構大変そうなのもバンバン直してくるなぁ。

2012/04/23

0:29

先週は全然作業出来んかったです。私用で別件が二つ重なったんで、こういう時は仕方ないかなぁ。 ローカルでビルドが出来ないとPRを確認出来ないので、取り込みもちょっとたまってます。すんません>638氏

一応、プライペートな用事はこのペースだと今週で片付くので、来週は作業に戻れるかな。

それだと来週末にリリースかなぁ、と思っとります。 来週末だと0.2.2系列の新しいのがmasterに入りますが、そいつのpullはやらないでおこう(たぶん永遠に出せなくなるので)

本当は時間ベースのりリースって事でいまのPRだけ取り込んで出しておく方がいいんだろうけれど、 そういうスタイルにはしてなかったのでこれは仕方ない結果ですな。 この辺は立ち上げ当時の状況からすると悪くない選択だったと思ってる(ここでスリップしてもあんまし影響無いし)

updater回りの整備が終わっててとりあえず使うのに問題ある問題も大分片付いているので、 更新自体はそんなに急ぐ理由は無いとは思ってます。 でも時間空けるとやる気無くすんで、一通りやる予定の事が終わるまでは気合入れて一気にやってしまいたい。

2012/04/21

19:46

ちと今週は時間取れないんでリリースは遅れそうっす。分からんけど。

memo

後でチェック
xyzzy.src : modify make-tags-file-dialog. #125

2012/04/14

21:03

022rebaseのおっかけがようやく終わり。0.2.2.237までは追いついた。 非常に不毛な作業だったが、これ以降はそんな事は無いと思う、たぶん。

さて、ただこれをmasterにしてしまっても良いのだけれども、 一部いらんがなぁ、と思うlispパッケージが入っているのでどうしたもんかなぁ。

追っかける利便性という事を考えると全部取り込む方がいいし、 これは一つの結論なんだが。

でもやっぱreferenceの類やCL関連はniでインストールすりゃいいんじゃね?という気はどうしてもする。 こっちはNAXELでおっかける方が簡単そうなのでそれいいかな~という気もしないでも無し。

チェリーピックする場合はこういうケースの定石を知りたいので作業は一旦中断して本屋でも行ってこの手の本でも調べるかなぁ、と思ってる。 意外と無いんだけどねぇ、そういうの。

2012/04/11

22:10

ちょいとNAXELは飽きたので気分転換に0.2.2系列へのおっかけを着手してみる。

まず、022masterというブランチで0.2.2系列のmasterをミラーする。 そして022rebaseというブランチはこの022masterを0.2.3系列のHEADにrebaseした物とする。

取り込みたくないのはどう管理していくのがいいのかなぁ?

2012/04/09

1:28

この雑記はあまり更新してなかったけれど、作業してなかった訳では無く、NAXELの作業を結構やりました。 既存のniでzipで公開してくれているのは全て追加完了。 それなりに形にはなったと思う。

基本的に動作が確認出来ている物だけを足している都合でいろいろ面倒。 0.2.2系列とかならスクリプトでpackages.lを全部足しちゃう、 で一気に揃うので、そっちの方がNAXEL向きだよなぁ、とは思う。

今週もNAXELのうち、簡単に修正すれば動く物を揃える予定。 ここまで終わったら一旦NAXEL回りの作業は中断して、他の作業に戻るかな。 再パックとかはそれ以降に暇を見てぼちぼちやっていく感じで。

次のリリースの前に、0.2.2系列についていく体制作りと、DEP問題を解決する予定。 この二つとNAXELの拡充で次のバージョンは終わりかなぁ。

最近は地味な雑用的なのが続くけれど、次のリリースまで行けば結構いい感じの状態になるんじゃないかな?

2012/04/03

22:43

はるるんの誕生日という事で765の名を冠する私としてはいろいろ忙しいのだった。主にニコ動見るのに。

そういう訳だが結構いろいろ作業は進み、手持ちのカスタム版は全部NAXELに入った。 しかもDeaR氏に一つPR出してもらったが一通り問題無くマージ出来た。 手伝ってもらう枠組みも完成。

xyzzy側もデフォルトの状態でM-x netinstallerとするとNAXELのパッケージ一覧を見る状態には出来た。

後はpackages.lがマージにやさしくないのでppをどうにかしたら、とりあえず使い始めるのに必要な道具は揃った事になる。

あとはひたすらNAXELのパッケージ集めで週の残りを使うかな。 一応今週中にはそれなりに私が何をしているのかが一般ユーザーに理解出来る所までは行くと思う。 来週くらいまでパッケージ集めを続けてそれなりの数まで行ったら次の作業に移るかなぁ。

次はDEP対応かな。そして0.2.2系列の取り込み体制の整備で次の次のリリースになるかね。

その後はniのクライアントを作ろうと思ってた。キーバインド覚えなくていいの。 ついでにライセンスのconfirmやらdependな物取ってきてくれるとかそういう事を片すつもりだった。 packages.lにライセンスの項目を足すなりして。

でも、最初は0.2.2系列が無かったんでユーザー増やす為にこの辺本気でやるか、と思ってたが、現状はちょっと状況が変わった。 もしこのまま0.2.2系列がいい感じに本流になるなら、方針を考えなおしてもいいかもしれない。 この辺は見てみないと分からんので、あんまりそれを前提に考えずに、 目の前にあるタスクが終わってから状況を見て考えてみましょう。

とりあえず状況が分かるまでにどうせ必要になる事、という事でNAXELを続ける自体は別に構わんのだが、 UIの作り直しはオーバースペックかもなぁ。 パッケージを集めてみて世の反応を見てから方針を考える方がいいかもしれない。

2012/04/02

22:33

ライセンスがいまいち分からなかったKaTeXだが、DeaR氏がGPL v2である事を発見してくれる。 それなら少なくともKaTeXの中のemacs.lとelisp.lは当然GPL v2だろう、という事でこの二つをNAXELに登録。 よしよし。 ちょうどWebArchiveからしか取得出来なかったKaTeXをちゃんとホスト出来たしライセンス回りもクリアに出来たし、 なかなか満足。

ライセンス回りもコンベンションが決まってしまえば割とすぐだし、使った印象もまぁまぁだしなかなか満足。

とりあえず今週の残りはiconのバグを直したら後はひたすらパッケージを追加していきたい。 手伝ってくれる下地もだいたい出来たけど、一人でも結構集められるんじゃないかな?これなら。

セットアップとかちゃんとNetInstallerに対応したり、とかは当面はしません。 まずは既存のを頑張って揃える、という方向を重視し、セットアップ回りの対応は必要に応じてやっていこうかな、と。 なお、やってくれてPRくれれば嬉しいです。

6:24

せっかくなのでアイコン差し替えてhttpsのproxy対応もなんとなく入れてalphaリリース。 そしてDevChannel始動。リリース版とDevChannelは分けたいと思ってた。

5:02

変な時間に目がさめてしまったのでNAXELにemacs lisp移植パッケージを追加して、手元のxyzzyでは一通り動く事を確認。 niのhttps対応が必要なのでこいつのα版を出さないと試せないですな。出します。

一応形は整ったという事で、NAXELの解説をちゃんと書き始める。分からん所とかあったら教えて下さい。

2012/04/01

22:16

0.2.2系列は立ち上がりは非常にうまくいったようで。ちょっとこちらの戦略も楽な道に変更出来るかもね、こりゃ。 なんとかマルチフレームが入ってくれれば自分はもうツリーメンテしなくていい水準だと思うが、 どうなるかはもう少し様子を見ましょう。その間にどうせ必要になる部分を固めておく。

とりあえずライセンスが不明なBrowser.dllをスクラッチから書き直し。せっかっくなのでATLで。 一通り動いたと思う。まだバイナリパッケージは作ってない。

また、ライセンスが「フリーウェア」という良く分からないemacs.lも、iswitchb.lを動かす程度まではスクラッチから書いてみた。 emacs.lに関しては複数人間の書いた物の寄せ集めなので、厳密にはそれぞれの人が著作権を有する類の物だと思うし、 この手のは申告罪なんだから限りなく白に近いんだが....

普通に考えたら元のemacs.lを使っても問題無いと思うが、まずははっきり分かってる物を揃えるという路線なので、 分からない物は作りなおす。emacs.lとBrowser.dllは他からも良く使われているので、ここは頑張るしか無かろう。

明日からとりあえずいまdownloadsに置いてあるのを一通りNAXELに移していく。 まだpackages.l書いてないが、それも明日やろう。

そろそろproxy対応もなおさんとなぁ。

来週中にサーバー側の形は示せると思うが、クライアントはその次に持ち越しだな~。予想より時間かかったが仕方ない。

ちなみに私が書いてる部分は全部MITライセンスです。

2012/03/28

6:36

ちょっとプライベートの方が忙しいので作業はせず。ま、明日は肉の日なんで、あんまり邪魔しないように。

睡眠時間調整でもう少し頑張って起きていたいが、やる事が無いので少し我慢してここに何か書く。 そうだ、とりあえずNAXELの話でも書くか。

2012/03/26

0.2.2系列見てたらA successful Git branching modelなんてドキュメントの存在を知る。 こういうの見たかったんだよなぁ。

現状はgithubのプレゼンと自分の常識と世の中のgithubなプロジェクトを見た感じでなんとなくやったら似た作りにはなったが。 でもdevelopが無いね。

これは最終的にはこのドキュメントのようにやるのが良さそうだ。 もともとリリース担当は分けられる体制にしておこう、という狙いがあり、その為にいろいろやってきた訳だが、developとmaster分けるのはそれを促進する気がする。

でも現状はこのままでいいかな。 もう少しチームが大きくなるまではブランチの数が一個少ない分楽だし。

バージョン番号を上げるタイミングもちょうど同じだね。RC用にブランチを切る時に上げるので。 ただαという概念が無いみたいだ。 これはなくす方がいいのかもしれんが。

現状はReleaseの意図は無いがいろいろ踏んで欲しい、という時に出している。 でも例えば0.2.3.6 alpha3とかが実は0.2.3.5.3とか0.2.3.5のパッチとして扱われているのはちょっとおかしい気もする。 でも最終リリース時にパッチレベルが必ずつく、って風にもしたくないんだよね。

そう考えると本当はαの時点でリリースブランチを切って、0.2.3.6を名乗るべき、という話はある。 実際0.2.3.5にhot fixを当てたらバージョン番号がかぶっちゃうんだし、現状のやり方はまずいわな。

正式リリースじゃないのとの区別ってのはそんなに頑張りたくないので、 RCやαには番号振りたくないんだよなぁ。そういう点では全部0.2.3.6名乗っとけばいいって話はある。 本当はビルド番号を識別出来た方がいいとは思うが。

2012/03/23

21:26

アップデータだとDEPが切れてないので結局後処理が要るやん、という話を聞く。 ほぅ、DEP切るんか。

と xyzzy DEPでぐぐると結構みんな切ってる。

でも_CRT_SECURE_NO_DEPRECATEとかdefineされてるのはまずいとずっと思ってる自分としては、 そんなexeのDEPを外すのはさすがにまずいんじゃないか?という気がする。 これについてちゃんと説明してる人も一人もいないし、いかにも何をやってるか理解してなさそうな感じで切ってる人がちらほら。 ちょっとこれはまずいなぁ。

で、説明するか?というと説明してもいいが、、、 ようするにheapにマシン語置いてそこにジャンプしたら例外とする、って機能だ。 バッファオーバーランがセキュリティ破りの定石な事を考えると、その難易度が劇的に上がるDEPはかなり素晴らしい。

でもこんな説明じゃしてないのも一緒で、やっぱり初心者にこいつをちゃんと説明するのはちょっと難しい。 そういう物を自己責任でフラグを外してね(はぁと)、ってのはまずかろう。 いろいろ細かい事言い出すと怪しい所たくさんあるんでいちいち言う気は無いんだが、 さすがにアプリ全体のDEPを切っちゃうのを常識にしちゃう訳にはいかん。

で、なんでそんなの切るのかな? というと普通はdll.ccのFsi_make_c_callable絡みでallocした所にマシン語つめてトランポリン作ってるあたりが動かなくなるからだろう。 結局このトランポリンだけ実行属性与えてやればいいんで、そこのallocationを見ると、、、 これが多くの所で使われているのと同じallocatorなのでFsi_make_c_callableの時だけ実行属性与えるのは出来ない。

lispのheapには全て実行属性与える、はアプリ全体でDEP切るよりは遥かに安全だが、 それでもいろいろと危険な要素はある。 例えば不思議な文字コードのファイルでちょうどx86のマシン語になるような物を用意し、何かのモードのバグをついてスタックのオブジェクトをオーバーフローさせてretアドレス書き換えてそこに飛ばせば実行させられてしまう。 これは結構実現するのが大変だが、うまいのを見つければ最悪「このファイル見て下さい!」ってどこかにテキストファイルを置いて、そいつを開かせる事に成功すれば好きな事が実行出来る、というのも理論上は可能だ(し、たぶん本気の人がやれば出来る)。

そういう訳でやはりFsi_make_c_callableでinsn吐いてる所だけ実行属性与える、が正しかろう。 そこは一応オーバーランと組み合わせて何か上書きされちゃう可能性も無くは無いが、 この機能実現の為の最小のリスクであるし、 そこまで書き換えられちゃうならx86命令実行させる意外にもxyzzyはいろいろ出来ちゃうので、 妥当な取引と言える(私の感覚では)。

そういう訳でmake_c_callableのトランポリンだけ別のheapアロケータを作って、lisp objectに持たせる感じにすれば、 markだけ書いてやればGCにはほとんど手を入れずに共存は出来そう。 でもアロケータ作るのはかったるいなぁ、という事で世の中のallocatorを見ると、tcmallocかjemallocが良く使われているっぽい。

tcmallocはtreeをweb越しに見てる感じだとmmapがVirtualAlloc直呼びで差し替えが出来ない。 いじってリンクしなおせば出来るんだが、、、

jemallocは本流はWindowsに対応してない。Mozillaは対応してるらしいので持ってくればどうにか出来そうだが、 やっぱりちとかったるい。

allocatorはいつか書きなおす日は来るとは思うのだが、まだそこに踏み込む準備は出来てないので後回しにしたい。 うーむ、困ったなぁ、というあたりでとりあえずここまでの内容をここに記しておく。

そのうち機会があったらDEP問題は片そう。

2012/03/22

17:14

だいたい他のユーザーの環境でも動かす目処が立ったので、解説を書きはじめる事に。 もうちょっとはまるかと思って早めにリリースしたんだが、意外といけそうな手応え。

変な環境ではしばらくトラブルが出ると思うので、中を分かる人がある程度自前でトラブルシュートしてくれる事を期待して。

2012/03/21

2:56

だいたい方針決定してガリガリ書いていると、httpsが取れねー! そりゃ無いよ、という事でいろいろhttp回りのライブラリ物色するも、どうも大きなのが多い。 一ファイルでちょろっと使える感じのがあったら取り込むつもりだったが…

仕方ないのでXMLDOM2でも使うか、とへろへろいじっていたら、これにはまる。

http://d.hatena.ne.jp/miyamuko/20060619/p1

何これ?という事で調べるとsafearrayの扱いにバグがあって、即値の配列はうまく扱えない模様。 へろへろ直す。

ついでにobjectからVARIANTに変換する時に配列は全てVARIANTの配列にするとうい実装になっててADODB.Streamとかに渡せないので、 byte程度の大きさのvectorの時だけVT_UI1の配列にするというやる気無い実装で目的を果たす。 これでresponseBodyをStreamにWrite出来ます。

でもwhileでsleep-forでreadyState変わるの待っても全然変わらん。sleep-forじゃダメなんだろうね。 調べる気も起こらんので今はblockingで乗り切る。後でちゃんと調べよう。

そういう訳で今日中に終わると思ってたのに終わらんかった。

でも残りはつなげるだけなのでエンディングは見えたかな。

そういえばset_undumped()はたぶん要らないので後で確認して削除せんとなぁ。超忘れそうだが。

2012/03/20

19:23

今日はxyzzy+のリリースという事で2chへの書き込みは控えておく。

NetInstallerでxyzzy自身のupdateをする、というのを、ついにlisp側実装中。 当初はnet installerの一アプリ、という顔をする気だったのだけれども、 いろいろリッチ過ぎて対応が面倒なので、net installerの低レベルAPI的なのを使ってxyzzy自身のupdateは別に実装する事にする。

現状だとzipファイルはそのまま残しておくのがniの標準的な動作だけれども、xyzzy本体に関しては使い道が無い割に無駄なので、その辺は大きく変えてしまう事に。展開後はzipは削除。

packages.lはpackagesと複数書ける理由は全く無いが、その辺作りなおすのは面倒なのでこのまま行こうと思う。 ただ、名前は変えてlatest-xyzzy-info.lとinstalled-xyzzy-info.lにインストール済みと最新のpackages.l相当の名前を入れてしまおうと思う。

urlもpackages.lでは無くlatest-xyzzy-info.lにしてしまおう。

2012/03/17

2:39

xyzzy.exeのアップデータが正常系では動いた。 まだ取ってくる側が出来てないが、これはniとくっつければだいたいOK(だいたいというのはインストール先が違うのでちょっと特殊処理は要る)

起動時にxyzzy.exeからキックするコードはまだ動作を確認してないが、どうって事無い処理なのでたぶん平気でしょう。

次はni側をいじってxyzzyのフォルダ持ってきて展開してxyzzy_newって名前にrenameする、ってあたりを書かなくちゃいけない。 ここは大部分lispで書けるので、C++ほどかったるくもあるまい。

こういう処理、これまでもたくさん書いてきたが、大抵お仕事だったので、持ってこれるコードが手持ちに無かった。 一度オープンソースな場で書いておくのはアリだな。 趣味で使いまわせるので。

来週後半のRCはこの不具合対応に追われる事になりそうだが、今後も続けていくつもりなら元が取れるでしょう。 もちろん元が取れると思ってる位には続けるつもりだ。

どうでもいいけどCXANの名前誰も書いてくれないなぁ。 こんな読めない名前嫌だよ。ZeniGameとかにして任天堂に訴えられちゃうぞ!(<やめなさい)

MidoriKameとかかなぁ。誰か俺の代わりに考えてくれよ。

今後しばらくは、こういう感じのペースで開発していこうと思っています。 巡航速度という感じ。 初心者向け整備が終わってある程度下地が出来たら次の目玉にとりかかるけど、それはだいぶ先の話だなぁ。 そこまではこんなマターリペースで。

アップデータが出来たら次は第二の山、CPANもどき作成に挑みます。 これは、システム自体は全て有り物流用でどうにか出来そうなので、コードはちょっとしか書かなくて良さそうな気がする。 packages.lのS式がでかすぎて使い物にならん!って所まで行ったらちょっと考えなきゃいけないけど、 xyzzyに存在するパッケージの数くらいならひょっとしたら最後までイケちゃうかもしれん。

この辺は形を示せばそれなりに皆協力してくれるんじゃないか、と甘く見てるがどうかね?

ある程度手応えを感じたら、システム側では無くてクライアント側をやろうかなぁ、と思っている。

ま、来週はxyzzy+が出るらしいので、向こうの感じを見てから路線を決めても良かろう。 どんな感じで出してくるのか、どんな感じで続けていくつもりなのか、なかなか楽しみだ。

2012/03/15

1:54

zipはCodeProjectのを使う事にした。ただしunzip32.dllがある場合はそちらを優先。 niはlisp下にそのまま突っ込む。とりあえず何もいじらなくてもzipの物はインストール出来るのを確認。

次に本体のインストーラにかかる。誰か協力してくれる人募る方がいいかな? 一人でも二週間あれば出来るとは思うが。

まず、xyzzy.exeがあるフォルダと同じフォルダにxyzzy_newみたいなフォルダを作る。 で、前回のリリース時より新しいファイルを上書き…かな?全部上書でもいいが。 ここは少し悩むな。まずは一番簡単な方法で実装して、あとから直していきたい。 よし、全コピーだな。

xyzzy.exeの起動時にxyzzy_newがあるかチェックして、あったら外部のアップデートプログラムをキックして自身は終了。 アップデートプログラムは全部コピーしてダンプイメージ削除してxyzzy_new削除してxyzzy.exeを再キック。 引数は失われる、でいいかな。というのは大半は次に述べる再起動で起動する事になるので。

updateは最終的にはメニューから実行する感じを想定だが、当面はM-xで実行。 新バージョンをチェックして、あったらダウンロードして展開。 そして「再起動しますか? yes no」のダイアログを出す。 普通は再起動を押して、上記アップデートのフローが走って*scratch*のみのxyzzyが立ち上がる。

という訳でやる事はこの三つか。

  1. ダウンロードしてxyzzy_newフォルダに展開するコマンドを作る
  2. 起動時にxyzzy_newフォルダをチェックし、あったらアップデートするコードを書く
  3. 再起動の実装

やっぱり他人と協力した方がいいかもね。

2012/03/13

1:36

NetInstallerは機能的には必要なのが全て入っているので、とりあえずこいつをベースで考えていきたい。 ただ、UIは初心者用がいるかもしらん。これは0.2.3.6より後に考えていこうと思う。 ライセンスは修正BSD。どう含めたもんか?各ファイルの先頭にコピペで埋めるかな。大して長く無いし。

別フォルダに出来るパッケージならLICENSE.txt置いておしまいでいいんだが、 lispフォルダに直接置くのを目指す場合、さすがに何か外から持ってくる都度ライセンスファイルが増えていくのはきつい。MITならコピーライトだけ残して終わりでいいんだが(本体がMITなので)。

まず最初から設定無しでこいつが使えて、しかもxyzzy自体のupdateが出来る、というのを目指す。 xyzzy本体はxyzzy.exeの書き換えの為に一旦外部プロセスキックして書き換えて再起動、 とかやらなくちゃいけないので、インテグレートを現状よりももっとタイトにやる必要がある。

現状だとアーカイバは自由に選べてしまうが、同梱するのはzipのみかな。 unzip32.dllはライセンス的に互換じゃないのでzlibにしようと思う。 この辺は調査してみた印象としては楽では無いがどうにかなりそう。

目標としてはカスタム版のパッケージをどうにかする、という物だが、 まずは答えが明白でそれなりにゴツい、本体のupdateから手をつけて、感触を試してみる。

かなりこれまでのxyzzyの哲学と違う物も混ぜる事になるが、 開発スタイルを変えるというのはそういうのを含むのでこれは仕方なかろう。 これまでのやり方はもう維持出来なかった訳だし。 変わらないのが良い人は0.2.2.235を使えばいいだけの話なので、 この辺はドラスティックにやっていきたい。

ただオートアップデートまで含める覚悟は出来ず。そこまで急進派にはなれんかった。 ここは次世代の若者がやればいいさ。

packages.lのメンテはとりあえず誰かに頼みたいが、この位なら手伝ってくれる人はいそう。 将来的には属人化しないように何とかしたいが、 最悪リリース側さえ分散出来れば初期設定URLを差し替えてリリースしなおせばいいだけなので、 誰かに任せてしまっても被害は少なかろう。

NetInstallerが思ってたより高機能だったので、カスタム版の問題はどうにかなりそうな気がしはじめている。

2012/03/12

2:21

RC2は問題無さそうなのでこれで正式リリース。 以後は二週間に一回のリリースの予定。もっと伸ばすかは次のリリースを見てからのつもり。
この辺までで立ち上げのフェーズは終わりかな。

ここまででとりあえず自分がどういう感じでやっていくのか、 ってのはそれなりに見せられたし、どれ位手伝ってくれる人が居るか、とか、どの位反応あるか、 とかも分かってきたので、今後はそれらを踏まえてもう少し長いスパンの作業をやっていくつもり。

とりあえず世の中のlispパッケージをどうにかする、というあたりをやっていく。 NetInstallerを使っていくのが良さそうなので、 まずはNetInstallerをセットアップして使ってみる所からだなぁ。

2012/03/09

23:31

週末は用事がいろいろあるので少し早めにRCリリース。 今回はまぁ大丈夫でしょう…と思ったらさっそく-no-init-fileがうごかねー。 この位はご愛嬌。

来週からはもうちょっと長期の作業に移っていきます。 当面考えてるのは既存パッケージのサポートと初心者が乗り換えやすくする為の作業。

はじめは自分はそういう事はやらずに次の目玉として劇的なパフォーマンス改善に乗り出してしまおう、 その間にこの辺誰かやってくれるといいなぁ、 と思ってたんですが、さすがにそれは無いか、という事で。

6話の雪歩ももっと大変そうなのに頑張ってたので、俺ももうちょっと苦手な事頑張ってみる事にします。

2012/03/08

2:32

動画見てみた。熱いなぁ。いいね!github!

現状だと皆がdeployableという感じにはなってないなぁ。 いや、システム的にはもちろんpullしてマージすればdeployableなんだが。体制として。

このマスターがいつでもリリース可能な物、ってのは理解していなかったな。 トピックブランチは俺も切れ、って事だね。そうかもしらん。 でも現状のような小さな事しかやってないフェーズだとそこまで固い事言わんでも、という気はする。

1:38

github的なプロジェクトの進め方をお勉強すべく、 http://zachholman.com/talk/how-github-uses-github-to-build-github を見てみる。まずはスライドだけ。

欲しい物とは違うけれどなかなか興味深かった。PRで話をするってのが特に。そういう所あるよね、github。
しかもこういうのはおかしいんじゃないか?ってのは禿同、って感じだ。 勉強になる、というよりは「そうそう、俺も前からそう思ってたんだよ!」って言いたくなる感じ。 そういう点で勉強にはならないが面白いし、参照したくなる事もありそう。

なかなか面白かったので動画も見てみるかな。

2012/03/07

21:27

キャレット消える問題を追ってる。 ようするにevalから出るまでactiveの切り替えはdeferしてる訳だが、 mini bufferは中でmain_loop回すからdeferのままですよ、って事だ。

なるほどねぇ、こんなケースもあるのか。 本来はreactivateとそれ以外を区別すべきなんだろうけれど、ちょっと煩雑だなぁ。 とりあえず同じframeへのactivate要請が来たら害の無さそうなのは実行してしまって様子を見るか。

昼頃

xyzzyのダウンロード数を見てると、公開した数日以降も割とコンスタントに伸びてるっぽいなぁ。 一部の人がひたすらついてきてくれてるのかと思ったが、これ、結構別々の人かもわからんね。 いつも19人くらいがすぐに反応してきて、その後は一定のペースで伸び続ける。 これ、意外と合計がユニークユーザーなのかもしらん。

もしそうだとすると、ユーザーは70人くらい、って見積は大きく間違ってて、 4*70=300人くらいかもしれない。しかもまだ伸び続けてるって事だ。 もしそうならもうちょっと続けて広まるのを待ってからの方がいろいろやるのはいいのかもしらん。

2012/03/06

4:18

638氏はやけにいろいろやってくれるなぁ。 結構いいコード書くし、ぶっちゃけツリーの権限あげてもいい気もするんで、欲しければジジにあげる。

つーかツリーの権限欲しいって人は言ってくれれば、今PRよこして来ている人ならたぶん全員上げますよ。 といってもPR送るのと直接push出来るのの差は大して無いから、 別にどっちでもいいだろうけれど。

今の内に何人かに上げておいた方が、不慮の事態に備えるって面はあるかもしれない。 まぁ今不慮の事態が起きたらまだ空中分解だろうから急ぐ必要も無い気はするけど。

最初のコードはなんか変更量が多い上に核心をあんまし理解してなさそうなfixでちょっとなぁ、 と思っていたが、腕が無いというよりは手抜きしてただけっぽいなぁ。 その後のコードでも単純に手抜きっぽいのは指摘するだけでちゃんと直してくるし。 もちっと仕様とか自分の意見押し通しちゃっていい気もするが、コード自体は結構まともな気がする。 得意なフィールドが遠い人なのかもね。ま、名無しの詮索はやぼってもんなのでこの辺で。(私の詮索もほどほどにね!)

xyzzyはダウンロード数はそんなに多くないがアクティブに活躍してる人が異様に多い気がする。 なんなんだ、この変な比率。いや、いいんだけど。 なんか10%くらいの人はかなりアクティブに活動してるんじゃないか。 もっと普通のユーザーが居てもいいと思うんだが。たぶん認知されてないんだろうな。

表でblogとか書いてくれる人がもう少し増えないかなぁ。DeaR氏は非常にありがたい。 ただ、あれはちと普通の人にはレベル高すぎなので、もっと普通に使った使用感とか完成度割と高いぜ的なのとか、 そういうのスクリーンショットとかいっぱい貼って紹介してくれるようなブログがあるといいと思う。 全然ぐぐってもひっかからないからなぁ、現状は。

っつーかなんで私のgithubとbitbucketはこんなに検索順位が低いのか!?一応中心人物じゃないの!?俺。 ぐーぐる先生は認めてくれないらしい。結構頑張ってるんだがなぁ。

1:12

今どきっぽいプロジェクト運営という事でfacebookのムービーを見る。

http://www.facebook.com/video/video.php?v=10100259101684977&oid=9445547199

面白いし勉強にもなるが、xyzzyには役に立たない感じ。 ただ現状と似てるね。一週間単位で、2日くらいかけて安定させる、という運用が。

ただxyzzyがそうなってるのは私がまぁこんなもんだろ、と思って決めただけだが、 facebookでこれを運用するのは凄いなぁ。相当の強者がいるんだろうなぁ。

逆にfacebook並の運用ってのは現状のxyzzyからすると保守的過ぎるかもしれない、とは思った。 やっぱりRC出してバグとってリリース、ってのはちょっと古いのかもしれん。

2012/03/05

15:29

政治体制とのメタファで考える。

  1. 絶対王政
  2. 寡頭制(一部の人達による議会)
  3. 民主制

とざっくり分ける。1は一人がとりまとめ、一人が最終的な判断をまとめる、というスタイル。 2は何人かのレビューボードみたいなのがいて、機能の取捨選択や方針を決めたりする。 3は良くわからない所。

2は割と簡単にイメージ出来るし、条件が揃えば移行出来ると思う。 3はなんなんだろうね。

例えば選挙的な物を考えると、PRが一番集まった人が首相になる、とか? それ以外の候補者はマージした後にこの最後に決まった人にPRを出す。 なんかこれはいい気がする。

PRの数で決めるってのは良さそうだな。 その時関連する変更を一番している人がタグ打ちをやる、って事か。

RCとかはやはりやり方としては古いと思う。 nightlyビルドとか出して、いっつも最新版でバグをガツガツ直して、安定した版を振り返って後からリリースするのがいいんじゃないか。 何らかの目安はある方が良くて、第二、第四金曜日のビルドをRCとして、これの見つかったバグはすぐ直す。 逆に中途半端なcommitはこの日の周辺にはしない、みたいな。

品質は低下するが、リリースコストを下げて分散化していくのは最終的には開発が進むので、 より面白いソフトウェアに育つってのがFacebookやChromeの教訓と理解している。

そういう体制が確立されればリリース作業はほぼ完全自動化され得る。 そうなればリリース当番というのは必要無くなる。 PR選挙とそのマージが全てとなる訳だ。 毎週第二、第四月曜はPR選挙の日、とかしておけばいいのかもしれない。

ふむ、理想形はわかってきた気がする。 xyzzyではそもそもビルドボットすら無いのでそうはいかんが。

15:09

ちょいと息抜きにgithubでのプロジェクト運営について考える。ぐぐってみると、意外とそういう話は無い。

まずデベロッパにとって何が新しかったのか。 forkして自分の修正を入れる。そしてPRを送る。 本家に修正が取り込まれれば最新版についていくのが楽になるし、 本家に修正がとりこまれなくても自分のツリーは変更が入っているので最低限は困らない。

これまでのパッチを送るのに比べると、どうせそれ以前もソース管理は行なっていたのだから、パッチを作るという作業が一つ少ない事になる。また、送られる側もpatchをあててcommitが単なるcherry pickになるので楽になる。 送られるのも単なるnotificationなので、MLにパッチ送るよりもずっと気軽に出来る。 嫌ならCloseするだけでいいんだから。

とり込む判断が誤りと思えば、他のツリーからforkする人が増えて、 それがメインのツリーとなる、、、のかな? その辺のベストプラクティスは良く分からない。

一方で、エンドユーザーから見た時の正式版、というのはあった方がいい。 これは特定のgithubレポジトリである必要は無いが、配布場所は特定の場所の方がいいだろう。 また、issue trackerもエンドユーザーが迷わずにここ、と思える場所がある方がいい。

xyzzyの現状はおいといて、とりあえず理想的な状態を考える。

ツリーは普段ばらばらで開発しておいて、2chの次スレ立てる感じで条件を満たした誰かがブランチを切ってPRを集める。 そしてその誰かがスクリプトかなんかを走らせるとタグが打たれてリリースされる、という感じかしら。

特定の共有ツリーがあれば、そこへのpushにトリガーしてボットが自動化出来るかもしれない。 でもどちらがいいのか?分散されてる方がいいんじゃないか?

リリース場所は固定されてる方が良かろう。最後にリリースする元となったソースの場所もわかった方が良かろう。 issue-trackerも固定されてる方が良いと思う。

逆にエンドユーザーに向けた物以外は全て固定されている必要は無い。なるべく分散している方が都合が良い気もする。 関連する場所をいじっている人同士がPRを送り合って、定期的に全てがマージされる。

マージにおける取捨選択は個人が行うんじゃなくて、PR出す側に任せてしまっていいんじゃないか。 一般的な大規模オープンソースプロジェクトではコミッタとかレビューワーとか権限持った人が何人かいて、 コミッタがコミットする訳だが。これはちとgithub wayじゃない気がする。

PRの品質が酷い場合は何らかの方法でそいつは排除する仕組みはたぶんいるんだが、 そういうのから考えるのは官僚的だと思うのだよな。 まずは皆がちゃんとやると想定し、まずい事態が起きた時に対策してく方が官僚化は抑えやすい気がする。

開発側ってのはかなりgithubベースは分かりやすいんだが、エンドユーザー向けにまとめる必要があるあたりとのギャップの埋め方がいまいち分からない。 結局誰かがやる必要があるんだが、その認識は間違ってるのかな? その誰かは交代制に出来そうだが。

2:01

特に問題無さそうなのでリリース。だいぶ片付いてきたかなぁ。 残りのissuesを見てもWoW64の32bitな話以外はどうって事無いのばかりだし。

来週末の時点で様子を見てだが、リリース感覚をもう少し長く出来る時期は近いかもね。

プロジェクトの最初としてはこんなもんかな、という程度の出来だと思う。 思ったよりは協力者は得られたし、ユーザー数もそれなりには増えた。 webベースでの開発のスタイルは確立出来たし、基本的な運用は固まりつつある。

次のフェーズはユーザーにもっと広めるって話になるんだろうけれど、 そこはもっと大変な所だやね。このままうまくは行くまい。 それは最初から折込済みで、それでも現状よりはもう少し先までは持っていけると踏んでる。

でもその前に、もう少し開発が続いていくソフトウェアってのがこれまでとどう違うか、 ってのを現在のコミュニティが体験する必要があるかもしれんね。 お仕事じゃないんだから楽しくやっていかんと。

ここまでの自分の印象としては、皆意外とC++書けるなぁ、という事。 VS入れてビルドなんて相当面倒だと思うんだが、 それにさらにgitでPR寄越せや(゚Д゚)ゴルァ!!とか言ったら意外と送って来れてびっくり。 lispレイヤは送ってくれる人も居るとは踏んでたが。たいしたもんだ。

一方でlispレイヤは思ったよりも層が薄い。 なんとなく自分の持ってた先入観では、現在残ってるxyzzy使いはC++分からんがlispはバリバリ、なのかと思ったが、 比率的にはC++分かる人の方が多い?似たりよったり? 何にせよ想像とはだいぶ分布が違った。

開発に協力してくれる人が何人か居るのは嬉しい誤算だ。 これなら当初思ってたよりは長く続けられそう。その幸運はうまく使いたい。

2012/03/04

14:54

さっぱり反応は無いが、RC2は何も問題無いって事かしらね? 今日の終わりくらいまで待ってリリースかな。この位落ち着いた期間が挟めると安心出来る。 こういう安心はアジリティー落とすからよくないんだろうが。

4:51

深夜はろくでも無い事を書きたくなる。

私はxyzzyの開発を引き継ぐ気は無い、って話は、覚えている人もいると思う。 引き継ぐってのがどういう事かをわかってない人にはきっと良く分からないと思うのだけれども、 ソフトウェアを開発するってのはもっと必要な事が多いのよ。そして私には致命的な欠点がある。

で、その話はいいとして、では私は何をやってるか、という話。

現状は私のやる気に依存して、かなりムリした状態で開発が続いている。 これは続かない。それは最初からわかってる。
これはこのまま行くぜ!という話ではなく、私のやる気が尽きるのが先か、私が居なくてもどうにかなる所まで辿りつくのが先か、そのレースなのだ。

現時点ではまずコミュニティが発生し、大きくなる事が重要なので開発継続と勘違いされる方が都合がいい訳で、 もっと言えば現実的にしばらく開発を引き継ぐ気があるので、ことさらこれを強調する気は無い。 そしてこの「しばらく」は、普通に想像するよりも遥かに長い期間を考えている。
先の事は分からない以上、これをもって引き継いでいると言ってしまっても嘘は無い。

でも皆が「やったね!あとを継いでくれる人が現れた!よかったよかった」とされてしまうと、 上記のレースでの、私の負けが決定する。
もともと敗北覚悟でやってるんで負けてもいいんだが、 出来たらそうはなって欲しくないなぁ、と思ってる。 だから開発を私が継続してくれた、とコミュニティの中に居る人が思ってしまうと、困ったなぁ、と思う訳だ。

たぶんもう一人誰かが必要なんだよな。 誰かは分からんが、私くらいの、でもタイプが違うのがもう一人。

一応最終的には私もその一人も分散して複数人で代用出来るような形になるってのが今の漠然として持ってるイメージなのだが。 ここまででだいぶ形というか想像のようなのはおぼろげながら出来るようになってきたが、 そこまでいけるかは現時点では1割以下って所だねぇ。 この辺が私の限界だろうな。ベストを尽くした上で1割に入るのを祈るとしましょう。

今回は久しぶりに率の悪い賭けをやりたい気分だったので、満足はしている。

2:25

変な時間に起きちまった。

cppモードの修正はブランチ切って入れてみた。やってみたら意外と少ない変更だったので、masterに入れちゃってもいい気がする。 何にせよ0.2.3.4には入れないけど。

RC2は良さそうですな。とりあえずもうしばらく様子を見て、問題無さそうなら今日の終わり(24時間後くらい、という意味で)くらいにリリースかしらね。 RC以降は待つのが仕事、って古い考え方なんだろうけれど。 そういう訳でバグが出なければ他の事やっときます。

最近はパッケージで挫折という話が増えてきたなぁ。XyzzyWikiみたいな感じで誰でも書き込める所に蓄積していくのがいいと思うんだが、 そういう場所無いかしら?誰かアイデアある人いるかい? アップ出来る場所さえあれば皆そこに置いてくれるとは思うんだが。

2012/03/03

15:01

RC2は今の所良さそうですな。明日も様子見て良さ気ならそのままリリースしちゃおう。

いまどき中央集権とか老害しねよってのは全くもってその通りだと思うし自分もそっち側の人間でありたいと思うんだが、 いきなりは難しいと思うんだよね。

まずいろいろな人(含む私)が実際にgithubやgitをベースとしたスタイルとはどういうモノか、 どこがどれだけ便利になったのか、ってのを試して理解していくフェーズが必要だと思うのだった。 そういうワケで現状のfixをとり込むのは、なるべく多くの人にそういうフローを体験してもらう、って意味もある。 小さくてトリビアルなfixでもPR出してみる、という事自体にそれなりに意味があると思ってるワケだ。 いや、fix自体もありがたいけどね。

そういう中でmasterがアップデートされてしまったりして、マージが必要になった時にマージというのが何なのかを理解出来たりもする。コンフリクトがある時と無い時の違いを学んで、 コンフリクトを避けるってのがどれだけ重要か、逆にどれだけ重要じゃないかを理解出来たりもする。 そういう作業を各自がやってみれば、実際にプロジェクトを運営していく上で問題になるのはどこか、 どこはもう問題とならないのか、という事を理解出来ると思うんだよね。

これは以前は中央のメンテナとかしか知る事が出来なかった問題なんだが、 今は皆がこのコストを体験出来て、分担出来る。 これを体験しておくってのは結構重要だと思うんだ。

それらを理解した上で、じゃあどうしましょ?という話に進めば良い。 特に後者の「もう問題とならない」事ってのは、昨今随分と増えたと思うんだが、 あんましこのコミュニティ全体の合意では無いと思うんだよね。

今回MLでは無くwebベースな事にこだわって、パブリックな所だけでやってきたのにはそれなりに理由もあって(理由が無い部分もあるが)、 issue trackerやgitがちゃんと運用されて、第三者がどう協力するのか、って形を明確にしていくのは、 答えを知ってるイマドキな人が思う以上に価値はあると思うんだ。

だからまぁそりゃ今時ねーよ、って思うのはもっともだし俺も結構そう思ってるんだが、 まずは多くの人がそういう認識を持つ所まで行くのが先だと思うんだ。

2:51

RC1はいろいろ怪しいのでRC2を出す事にする。 やっぱりselected-frameの変更を遅らすのは被害が大きい。

これは正しいので基本的にはおかしくなった所の方が悪いんだけれども、 lispレイヤーにかんしては全部直すのはちときついので妥協して、前と同じっぽく見えるようにする。

xyzzy.exeの方は全部気合で対応していく。 この手のモノを潰していく過程でいろいろおかしいコードは治っていくので、 xyzzy.exeの中に関しては妥協しない方向で。

2012/03/01

25:20

なんか今週はいろんな人が手伝ってくれたなぁ。 プロジェクトの運営的なのを考えなきゃいけないやね。 いろいろと流動的な状態で、やってきた人にいろいろ実験的なお願いをしたので、 結構いろいろ頼んで来やがって大変だなぁ、と思った人もいると思いますが、まぁすんません。最初はこんなもんっす。

走りながらなのでまだまだ整備は出来てませんが、一応受け入れるひな形みたいなのはできつつあると思う。 issue trackerの運用でバグの受け入れは一応出来ているし、 PRの受け入れに関してもUnitTestがなんとか入ったので、UnitTestの運用みたいな形も一応出来てきた。

自分的にはこういう幸運がいつまでも続くとは思っていないので、 受け入れの準備に時間をかけるよりは、 なるべく来た段階で混沌としていても即座に受け入れていく感じを基本としたい。 きっちり固まってから混ぜるんじゃなくて、受け入れた後腕力でねじふせる感じで。 まぁまぁそういう腕力は自信あるし。
UnitTestとかもっといろいろ時間かけて形を整えたかったという思いもあるかもしれんけど、まぁそういう感じなので不完全でも早く運用に入るのを重視しとります。

ただしエンドユーザーに出すのはそれなりの安定性を確保したい。 何も知らない人がzipを持って行ったら酷い奴で

「あー、そのバージョンはハズレだから一つ前の使って下さい」

みたいなのはなるべく無いようにしたい。 自分がそういうの大嫌いだから。

結果としてRCとかの重要度は高まる訳ですが、その辺は割とみなさま協力してくれてるのでどうにかなってると思ってる。

15:17

お手伝い募集とか書いてみる。アナウンスはもちっとタイミングを見て。

12:44

emacsの挙動を調べる。

(make-frame)

新しいフレームがアクティブに。

(setq frame (make-frame))
(switch-to-buffer "memo.txt")

親のフレームがswitch-to-bufferされて新しいフレームがアクティブに。 ほぉ。

(setq frame (make-frame))
(select-frame frame)
(switch-to-buffer "memo.txt")

新しいフレームでswitch-to-bufferされる。

感じとしては通常と同じにactivateをdelayすれば良さそうだね。

(save-window-excursion
  (setq frame (make-frame))
  (select-frame frame)
  (split-window))

新しいwindowはsplitされる(!!)

save-window-excursionはevalを実行した最中のフレームでだけ処理すれば良いのか。 chainに存在するかどうかは一応チェックかしらね。

(setq frame (make-frame))
(delete-frame (selected-frame))
(split-window)

split-windowがどっかいっちゃう時と新しいフレームでsplit-windowされる時があるっぽい? 良く挙動が分からない。

2012/02/29

24:00

今日はPRが幾つか来た一日だったなぁ。こんな事は普通は無いと思うんだが、雪だったので会社休んだ腕っこきが多かったのかしらね?

PRの運用とかUnitTestの運用とか、どうにか形は整えられそうな気はする。 結構カオスだが。
PR出してもらって取り込んで、という形は一応達成出来ているし、 参加者が徐々にgitに慣れていく事も出来ていそう(含む自分)。
この手のは後になったらみんな誰もやってくれない、って所があるんで、 人が来てくれた時に頑張るのは重要と思う。 現時点ではまぁまぁいいフィードバックを返せたんじゃないか、と自分では思ってる。 bowbow氏とかプレッシャーに思ってたら失礼。別に急かす気は無いですよ。
この立ち上げがこんなにうまく行くとは正直思ってなかったので面食らってるけど、 ラッキーって事で素直に皆に感謝して進んでいこうかと思ってはいます。 ビルドのインストラクションとか一切無いのにみんな良く頑張るなぁ。 ちなみに今は一回makeした後は以後VSでF5実行で開発出来るんだぜい?知らん人も多いだろうけれど。
結局GCのチェックがデバッガつけてると遅くなりすぎるので途中からアタッチするのがメインですがね。

自分の予定していた作業としては、把握しているバグは終わってしまった。 その他の作業をやってみてもいいんだが、最近xyzzyに時間使いすぎていたので、プライベートな作業を進める。 バグ報告が無ければ現時点のでRC出しちゃってもいいんだが、まだ何か来るかもしれないので後回しに。

ちなみに略語が意外と通じない事もあるので解説しておくとRCはRelease Candidateね。 特に問題が無ければこれをそのままリリースしたいと思ってます!ってバージョン。 大抵出した後にバグが見つかるのでそれがリリースされる事は無いけど。

>別ページに移す。RC

15:15

UnitTestの運用について、ちょっと書くか。 まだ流動的な上に最終的には私よりは担当者にお任せしたい所だけれども、 実際のユースケースが分かる方が考えやすいだろうし。

12:46

テストは無事通った。バンザイ。ついでにSystem32のリダイレクト対応PRが来た。 やったね!という事でとりこんで試すとこれまたちゃんと動いていい感じ。 64bitの時しか動かないのでunittestはちと書きにくいのでサボり(ぉ

make-frameのhookがおかしいよ、という話なので修正。 この辺は使わんと分からんので、使ってくれるのはありがたい事です。

さて、次は以前挫折したC-x 5 oに再挑戦かなぁ。

テストのログ。

fix-format-R...OK.
fix-format-F-00...OK.
fix-format-E-01...OK.
fix-format-E-00...OK.
fix-format-G...OK.
fix-for-FFI-c-function-return-doubl/float-00...OK.
fix-ole-method...OK.
fix-typo-in-lisp/css-mode.l...Failed
  Return values (non-nil-p):
    Expected:
    => :non-nil
    Actually:
    => nil
fix-typo-in-lisp/encoding.l...Failed
  Return values (non-nil-p):
    Expected:
    => :non-nil
    Actually:
    => nil
add-*brackets-is-wildcard-character*-to-history-variable...Failed
  Return values (non-nil-p):
    Expected:
    => :non-nil
    Actually:
    => nil
fix-format-n@A...OK.
fix-long-operation...Failed
  Return values (equal):
    Expected:
    => 2
    Actually:
    => 1
fix-save-window-excursion...OK.
fix-listen-for-file-stream...OK.
fix-listen-for-string-stream...OK.
add-get-buffer-colors...OK.
add-*read-eval*-01...OK.
add-*read-eval*-00...OK.
fix-applyhook-00...OK.
fix-format-F-02...OK.
fix-format-F-01...OK.
fix-format-VT...OK.
fix-format-T...OK.
add-putenv-04...OK.
add-putenv-03...OK.
add-putenv-02...OK.
add-putend-01...OK.
add-putenv-00...OK.
add-deleted-window-p-02...OK.
add-deleted-window-p-01...Failed
  Return values (non-nil-p):
    Expected:
    => :non-nil
    Actually:
    !! simple-error: 分割できません
add-deleted-window-p-00...OK.
fix-single-float-eplilon...OK.
fix-nthcdr-given-dotted-list-05...OK.
fix-type-check-in-list-length-01...OK.
fix-type-check-in-list-length-00...OK.
fix-flet/labels/macrolet-02...OK.
fix-flet/labels/macrolet-01...OK.
fix-flet/labels/macrolet-00...OK.
fix-macroexpand-01...OK.
fix-macroexpand-00...OK.
fix-eol-code-of-zero-size-file...OK.
fix-special-variables-restore-at-the-end-of-let/let*-01...OK.
fix-special-variables-restore-at-the-end-of-let/let*-00...OK.
fix-multiple-binding-of-special-variable-in-let/let*-01...OK.
fix-multiple-binding-of-special-variable-in-let/let*-00...OK.
fix-abbreviate-display-string...OK.
fix-typo-in-lisp/compile.l...Failed
  Return values (non-nil-p):
    Expected:
    => :non-nil
    Actually:
    => nil
fix-compiling-lambda-form...Failed
  Return values (equal):
    Expected:
    => 1
    Actually:
    !! unbound-variable: 変数が定義されていません: a
sxhash-fix-01...OK.
equalp-for-hash-table...OK.
----------------------------------------------------------------------
total 50 tests, 43 passed, 7 failed, 0 Errors

2012/02/28

いろいろあって開発PCが半日くらい使えなかった。今日は作業は無理かなぁ。 反応する為にpublicなtwitterアカウントを作ってみた。

http://twitter.com/mumurik465

で。 mumurik765とどちらにするか悩んだが、465にしておく。

2012/02/27

14:03

issue trackerの運用を書く。

13:43

なんかたまにC-gが食われるなぁ。たぶんよそのアプリから戻ってくる時に、前activeじゃなかったフレーム触ると…かな?良く分からんが。 誰か再現方法調べてよ!

12:33

今後は上に新しいエントリを書こう。

でisearchを調査開始。まずisearch中に他のフレームが使えなくなるのはloop内で処理してるから仕方ないな。 ハノイ問題の時にたどり着いた結論なのでまぁいいか、という気はする。 これ、書き方変えてマルチフレームでも動くように、コールバックスタイルみたいなのを提供したい気もする。

ちなみにemacsで試すとC-gされたかのように振る舞う。こっちの方がいいような気もするが、もうちょっとこった事しないと困ったケースもあるかもしれないので、まずはださくても安全な挙動で満足。

動かないのはおいといてミニバッファが変だよ、ってのは、Vminibuffer_messageとVminibuffer_promptがグローバル変数なせいだね。 ハッシュにしてもいいしframeに持たせても良いが…frameに持たせる方が筋はいいかなぁ。lispからは触ってなさそうだし。

メモ。そのうちちゃんと解説を書く。 xyzzyの継続的な開発に必要な事

2012/02/26

とりあえず反応無いし、自分がつついた感じでも特に問題無いし、リリースしちゃっていいかなぁ。

すぐに新しいバージョンが出すぎて試す気が起こらない、という要素と、 なかなか変更を反映した版が出ない、の間のバランスとしては、 自分はやっぱりすぐに変更したバージョンが出る方に倒す派。

そういう訳でリリースしておいて、修正を素早く、という方向で行きます。 オートアップデートが無いから最新版ついていくのかったるい訳だが、この問題はそのうちなんとかせんとなぁ。

開発を本気で長期間続けるならオートアップデート入れちゃってもいいが、 現時点ではそこまでやる気は無いんで入れません。

ついでにapp-menu.lの話でも書いておくか。

待ってたらこの辺片付く、と期待している人が多そうなんですが、私にはちょっと無理っす。 初期の頃ならここまでやってたと思うけど、さすがに力尽きた。

13:35

もうちょっとリリース計画とかオープンにしたいなぁ。うまい手は無いものか。

  • 0.2.3.2 現状。マルチフレームのちゃんと動く版
  • 0.2.3.3(現在準備中) 世の中にあるパッチを取り込んだ物
  • 0.2.3.4 C-x 5 oとかselect-frameとかC-x 5 2した時にselected-buffer持っていくとかそういうmultiframe回りを直した物

という風に考えている。 0.2.3.5以降はノープランで、何も無ければこのままバグfixを続けて行ってフェードアウトになる訳なので、 理想的には0.2.3.5まで行ったあたりで誰かがforkして他のネタを入れてくれるのを期待している。
ただ、0.2.3.4を出す頃には何かまた変更ネタがあって0.2.3.4みたいなのがしばらく続く可能性もある。 この辺は0.2.3.4が出る頃になってみないと分からんかなぁ、と思ってる。

0.2.3.4まではweekly releaseくらいを思ってます。

リリースプランに移す。

13:44

issue trackerでのissueの登録があったので、自分もissue trackerを使い始める。 今後はこいつで集約管理の予定(分からんけど)。

そういう訳でバグ報告はgithubではなくbitbucketsにお願いしたいと思ってます。 (将来移行するかもしれませんが)

21:19

Load of the Filesはいい話なので翻訳無いかなぁ、と思っていたら、やってくれた人がいた。

githubの思想は凄い正しいと思うんだけど、自分はgithub使いという訳じゃないので、いまいちgithub wayにプロジェクトを運営する方法は分かっていない。 だからmultiframe版はgithub wayには進められない。

ただ、わかっている人がやってきて正しく進めてくれる時の為に、例えばchangeのhash値変えないようにとかそういう所にはそれなりに気をつけている。 最終的にはgithub wayしか無いと思っていて、でもそれは自分では出来ない。

自分は皆に受けがいいタイプのキャラじゃないし、面倒な事嫌いだし、twitterのアカウントも電話代わりに身内との連絡に使ってるので個人情報だだもれでpublicに出来なかったり、いろいろプロジェクト運営していくのには向いていないという自覚はある。 もうドキュメント書いたりとかパッケージ入れたりとかMLに登録したりとか凄い苦手なのよ、本当。

twitterは返事したいんだがなぁ。

22:40

正式に0.2.3.3をリリース。ただしRC1と全く同じフォルダをrenameしただけなのでRC1を試している人はそのままでおk。
Wikiの関連するページも一通り更新。

2chは今64bitで盛り上がってるのでちょっと様子見。後でアナウンスします。

2012/02/25

一応USB対応終わり。これで少しつついてOKならRCを出すかな。ベータが無いのがマルチフレームクオリティ(ぉ

既存の挙動が既になかなか一貫性が無い(環境変数、コマンドライン引数等の優先具合とかが変数によって違うとか)ので、 変更した挙動を説明するのもなかなか難しい。
細かい部分はコード読んでもらうとして、基本的なユースケースだけ抑える、という感じにするかな。

11:55

こんなに月も紅いのに-マルチフレームの感想を読んでて、そういえばmake-frameした時のサイズは何も指定してないままなのを思い出す。 作った当初になるべく何もしないstartup-frame作ったまま、ツールバーとメニュー以外何も見直していないからなぁ。

そういえば変なscratchバッファ持ったままだったりするよね。なんだろ?あれ。 次のリリースはその辺直すか。

自分としてのToDoの消化はだいたい終わったんだけど、今後はどうしたもんかねぇ。 メニュー対応は本当はやった方がいいんだが、ちと燃え尽きた。

もうちょっと続けて今後の中心になれるツリーの元になる感じにしたいんだが、そろそろやる気がある事が無くなってきたなぁ。

16:28

リリース用のスクリプトを走らせたら、byte-compileがデバッグ用のxyzzyが使われてしまって大変遅い。 これはestartup.lcがコンパイルされるまでxyzzy.exeが起動しないので、どこか動いているxyzzyを使う必要がある為普段使ってるxyzzy.exeの場所のでビルドしている訳だが、これがrelease版だったりdebug版だったりはその時つつきたいのに依存してるからだなぁ。

バイトコンパイル用にどこかにとっといたバージョンを使ってもいいんだが…

18:00

更新履歴を更新。ここはreadme_multiframe.txtとかぶってるので同じ内容にしてみる。 結果としてreadme_multiframe.txtがよみにくくなってしまった…

Wiki記法と可読性は微妙に一致してないけれど、二つ管理は嫌なので仕方ないな。

正確な履歴自体はgitの履歴を読む方が正確だし読みやすいので、ここにはエンドユーザー視点で知りたいと思う内容をまとめたいと思う。 一応オリジナルの変更履歴の魂を継いで、頑張りすぎないようにはしたい。

今回のfixは結構いろいろな所に散らばっていて、関係各者に連絡するのは絶望的な感じだ。 その為のgithubだとは思うが、やっぱりオリジナルを作った人には感謝の気持ちを示したいなぁ。

なんかいい手は無い物か。

19:16

githubを使うようになったのでgithubの哲学も、という事でhttp://www.wired.com/wiredenterprise/2012/02/github/all/ などを読んでみる。 許可をとったりなんてせずにガンガン行け!ってのがgithubスタイルという事なんだろうなぁ。

最近のようにたくさんのパッチ取り込んだりしてると、こういう哲学の正しさを痛感する。

システム的にはbitbucketも大して変わらんし、hgはむしろ優れていると私は思うが、 githubの方がこういう哲学的な部分が前面に出てるよなぁ。

xyzzyのように継続的にやる人はいないが何かやりたいと思っている人が多いコミュニティではこういうやり方が非常に適しているとは思うが、 皆がgithub wayに馴染んでいる訳では無い、というかxyzzy界隈は逆に誰も馴染んでいないので、 そういう方向に進めるのは一気には出来なかろう。

自分としてはそういう方向に進める人が現れた時に踏み台として使える物を残しておく、 というのが影の目標の一つだったり。

2012/02/24

マージした結果byte-compileしなきゃいけないファイルが増えたので、コマンドラインから一発で全部バイトコンパイルする、 とか書いてたら、思ったより時間がかかったりする。 glob-execは毎回はまるなぁ。

その成果としてunittestを作ってくれる人向けにアルファリリースをしてみる。意外と試す人が多くて驚くが、 落ちバグ報告等はwelcomeだぜ。

USB起動のパッチはちょっと強引なので今のツリーにこのままは取り込めない。 archiverは割と素直なんでこのままでもいいか、と思って多少コードを堅く直したくらいだが、homeディレクトリは基本はユーザーのhomeになるべきだろう。
環境変数はいやん、ってのは皆の意見なんだろうから、それ無しで済むけど既存の挙動への変更が少なく、 ついでにアタックサーフェスを広げないようなのがいいとは思ってる。 今更C++でセキュアもくそもねー、って意見もあるだろうが、そこは育ちの良さがにじみ出る所という事で。

だいたいxyzzy.exeのあるフォルダのusr以下に出来る訳だが、持ち運びを考える上で問題になるのはhomeディレクトリだろうなぁ。 つまり.xyzzyとか。
で、それを指定するのはiniファイルとかで良い気がするんだが、 iniファイルは現状だとusr下のちょっとわかりにくい所にこっそり出来るので、 ここにhomedirのエントリを書いてよ、ってのはちょっと説明がかったるい。

そういう訳でxyzzy.exeと同じフォルダにiniファイルがあったらそいつを使う、で、 そこでhomedirのエントリがあったらそれ使う、って感じでどうかしら?

オリジナルのパッチはもう少しいろいろ汎用性があるけど、とりあえず上記で最低限はこなせるんじゃないか。 ただ、USBのドライブは毎回違いうる上に、homeのフォルダは違うドライブだろうから、これまでと同じ挙動を明示的に出来るようにするにはもうひと頑張りいるか。

emptyならこれまでと同じ挙動、エントリがあったら相対パスと解釈、で実情は困らん気がするがどうかな? とりあえずこれで出してみてフィードバックを待とう。

現状の案。xyzzy.exeと同じフォルダにxyzzy.iniというファイルを作り、

[Setup]
xyzzyHome=.\home
xyzzyUserConfig=.\config

と書いておく、という物。
これだとxyzzy.exeと同じフォルダに書き込み権限が無い状況でこの挙動をさせる手段は無くなるが、USBで持ち運ぶ、 というならとりあえず十分だろう。

configとhomeを別に指定するのはかったるいが、とりあえず今の仕様から自然な延長になる範囲で我慢。

ダンプファイルをどうこうする変更は必要なのかな?どうせいまどきはxyzzy.wxpしかないだろうし、USBに書いちゃっても問題無かろう。
書き込みおせーよ、ってのがあるからこのパッチはtempに書いているんだろうが、 こちらは保守的にやってみて、ユーザーの意見を聞いてから考えよう。

23:53

今日中に終わらせる気だったが、仕様を考えたりいろいろ微妙なケースをケアしていたら、半分くらい残ってしまった。
iniファイル回りは終わったので残りはconfigとhomeやって終わりの予定。 残りは明日かなぁ。

26:51

なんかinitというセクションがあり、ここにhomeDirとかいう値がある。

これはフルパスになってしまうので、usb物は優先されなくちゃダメだよなぁ。 同じようなエントリが二つになってしまうが、USBってのを分かりやすくするか。

[USBInit]
usbHomeDir=home
usbConfigDir=config

こんな感じで、USBのセクションはinitのセクションに優先される。どちらも相対パスなので、data
homeなどと一段掘ってもいい。 ただし.とか..とかはハンドルしてない。

2012/02/23

結局レポジトリの中をlfに変える、ってのが一番と判断し、PowerShellで変換。 こういう作業ばかりに時間を食うとせっかく関心を持ってもらえてるこのタイミングを逃すのでちょいと急いで作業。

説教くさいことばっかいって手を動かさない老害もかっこ悪いので、実作業もガリガリ進めるです。

現状はhashのrehash回りの変更と*brackets-is-wildcard-character*をhistory variableに移す、という変更を見て考え中。まぁ害は無さそうなので取り込んでしまうか。

ちなみにChangeLog.txtはcherry-pickでコンフリクトが非常に多い。
だがログには日本語使えないから解説が過少になるんだよ!って事だと思うんで、こればっかは仕方ないなぁ。

結局我々のような人種はログは英語で!で終わらせてしまう訳だが、そっちの方がひどい話だよな、本当は。

12:26

ChangeLog.txtの管理はやっぱ無理だなぁ。私のツリーに入っているChangeLog.txtはあまり信頼がおけない感じになるのは諦めるしか無さそう。 混乱を呼ぶけれど、このファイルが無いとマージが面倒だし。

listenのEOF判定はなんかちょっと書き方がロバストじゃない気がして悩むが、とりあえず取り込む事に。 バグが出たら書き直せば良かろう。

get-buffer-colorsは小さいし害はないので、推奨に反しpickする事に。

minimize時のtrimの無効化はなんで入れたんだろう?trimしてくれる方がいい気がするが。ちょっとピックは後回しにするか。 と思ったら次でrevertされてた。

12:53

nthcdrとか細かい挙動の変更はどうも必要性が分からんなぁ。別にANSI CommonLisp準拠って訳じゃないんだし、これまでの挙動でもいいんちゃう?という気がする。
この手の物は実際にlispのパッケージ作る時こう困った!というのが無いと、価値が分からん。

しかもだいたいオリジナルのコードの方が短くて挙動が(C++のコードを)見た瞬間すぐわかる。 これはこういうポリシーだと思うんだが。

ただ、変更した挙動が何かまずいかっていうと別にまずくも無さそうなんで、気にする人がいるなら取り込むかなぁ。

こういうのを細かく入れてく位ならちゃんとANSI CommonLispとかに準拠させてしまう方がいいと思うんだよなぁ。 まぁ俺はCommon LispよかC#派なのであんまり関わる気は無い。

この手の取り込むポリシーは悩ましいね。まったくなんでも無節操に取り込むと、アプリとしての完成度が落ちる。 でも基本自分一人の趣味に従ってそれ以外は全部reject、では誰もこれに関わる気が起こらない。
自分的なバランスとして、このくらいは趣味じゃないけど取り込む、ってのが私の答え。

14:12

unicodeが中途半端に入った結果ビルドできなくなった。どうせなら全部入れるか。 確かMITでOKだったはずなので、配布に入れない理由は無いんだよね。

16:03

マージしゅーりょー。頑張った、俺。えらい。USB回りは明日かな?

あんまプロジェクト的な話語って手を動かさない奴は嫌いなんで、そうならんようにそういう事はあまり口出さないようにしてるが、 ちょこっと基本となる方針的なのは2chに書き込んでみる。

そういえばgithubの場所を言ってなかったかも。まぁこんな所見てる人間なら勝手に調べられると思うが。

https://github.com/mumurik/xyzzy

です。

2012/02/22

丘ぎったーが、masterにRIなんてしてなくても必要な物だけ含むようにrebaseしまくってから持ってくるのがgit流なんだぜ?(たぶん)
とか言ってたので、ツリーとしてのマージが必要な時はその方針でやってみようと思ってる。 確かにこちら側で好きにやるのがgitスタイルだよな。

xyzzyのgitモードとか無いのかね?たまにgit+xyzzyというtweetをしてる人を見るんだが、どう関係しているのか良く分からない…

git guiは差分表示の時にChangeLog.txtの文字が化けて読めなくて困ってます。

追伸:

git config --global gui.encoding utf-8

で化けなくなった。

19:21

試しにいつかマージしようと思っていたMakefile回りをマージしてみる。 unsafe系をsuppressしてしまうのかぁ。 ちょっと趣味が合わんがここらへんはぐっと飲み込むか。
ネットワーク物を開発していくならやっぱり長さ指定無いのは全部見直すべきだと思うが、 今それをやっちゃうといろいろ面倒だからなぁ。 さしあたりサーバーソケットを開く人はいないと思うのでよしとするか。

改行コードがなんか合わない。nanri-masterから持ってくるとlfで自分のレポジトリのはcrlf。 autoCRLF=trueです。

良く分からんが、diffmergeはよきにはからうので多少面倒だけどどうにかはなるので気にしない。

マージしてみると変なフラグが残ってるので、いい機会なので古いフラグは新しいのに変更しておく。

2012/02/21

落ちバグの報告があり確かに再現する。だが最新版だとしない。そして幾つか思い当たる変更がある。 本来は前の版でちゃんと再現させて原因見て納得すべきだが、今回はちょっと手抜きさせてもらって直した、という事にさせてもらおうかな。

そして昨日の今日だが落ちバグは直した物をリリースする、というのを基本ポリシーとしたいので、0.2.3.2をリリースするか。

10:55

ツールバーを選択した結果が保存されてないぞ!という指摘を受ける。 history variableがnilな人だけ起こる(つまり新規インストールなら確実に起こる)ので、私の環境だと再現しなかった。

.xyzzyを無視して起動するとツールバーがそもそも死んじゃうんだよね。だからこの辺のテストをするいい手が無くて困ってる。 がんばって.xyzzy直せばいいんだけど。起動時の指定で、無視じゃなければhistory variableのloadはされるのかしら? (このload hookが呼ばれないとツールバーが出来ないという作り。これはもともとそうなんだけどバグじゃね?という気もする)

16:28

今日はリリースした結果の広まり具合とかをちょこちょこ見ている。ダウンロード数やtwitterの検索とか。 一応2chで進行していた秘密プロジェクト、という状態からは脱したのかなぁ。

今回正式リリースという事で考えていたのは、良く分からない人でもちゃんと使える物を目指す、というのがある。

目標としては、一部の人たちだけが試す実験版では無く、「xyzzyの最新版を入れようと思うんだけどどれ?」と言われた時に皆がこれをさしてくれる、という状態。これが目標です。
そこに至る為の第一歩として、ちゃんとバージョンを決めてリリースをしていき、リリースされている版は初心者でも使える版である、という形式を固めたかった。

ただパッケージの対応がある分、現状はまだ0.2.2.235を使う方が無難だというのは認めざるを得ない。

ここは開発側の問題というのもあるが、どっちかといえば広まっていけば解決するという要素の方が大きいので、 にわとりが先か卵が先か的な問題と思ってます。 皆が使えば皆が使うべきバージョンになる、という。

最終的には0.2.2.235はobsoleteで0.2.3系列が最新版、新しくlispパッケージを作る人はこの最新版向けに作る、という状態を目指しています。 それにはほとんどのユーザーが移らなくてはいけない訳で、先は長いし、そこまで行くのは現実的にはかなり難しいですけどね。

結局、今後は自分が全部やるぜ!新バージョンをこの後もずーっと作り続けていくぜ!と覚悟を持ってやればこういう話はどうでも良くなるのですが、やっぱり現状そこまで全てを背負うのは難しい。
だからとりあえず自分はどこまでやる気があるのか、というのを示すのは意味があると思っています。
マルチフレームの入ったバージョンが最新版になる、というのを目指すくらいまではちゃんとやる意志がある。 そこから先、継続的にやっていくよ!というのは難しいと思っているけれど、 この上に何かを作っていってもらってOK、という状態までは持っていくつもり。 やはりそういう意図が良く分からない他人のツリーにはcommitできんと思うんですよね。

もちろん本当にそこまでいけるかはまた別の話。

補足: ちなみに全部一人でやっていくつもりの奴は、もう現れないのかもな、と思っています。 でもこれまでのxyzzy界隈はそうだったし、現状ではそれ以外はどうしようも無い。
そういう訳で現状のそういう要素こそが変わって欲しいなぁ、と思ってます。 どういう形かは分からんけど、どこかに最新版のツリーがあって、forkして適当にいじっってPR出せばpullしてくれて、 という形で開発が進んでいくような。
やっぱ一人じゃもうダメだと思うんだよね。 で、誰かが頑張るんじゃなくて皆の頑張りをうまく集められるように、これまでのxyzzyの常識的なのを変えいかんと、そうはならんと思ってます。

でも誰かがツリーの中心を管理すればいい、って程簡単な話でも無いんだよね。 実際私と同じ人間が三人いて、一人が中央のツリーを管理、残り二人が開発、という感じならどうにかなると思うけど、 逆に言うとその位はリソースがいる。 今回の変更くらい大きくいじる人があと二人、居ると思う?居るといいな。本当にそう思う。

ツリーの中心を管理するのがただ一人いてもどうしようも無い。 しかもその管理に求められるエンジニアとしての力も、相当な物になると思う。
ただgitにツリー作ればいいってんじゃない。 ただ中が分からないけどマージはします、じゃ意味は無い。
どういう変更は入れるか、どういう変更は入れないか、こういう機能は本来はどうあるべきか、そういった判断をいろいろとこなしつつ、 リリースエンジニアリングに関してもいろいろな事が求められる。
だから私がgithubに移れば全て解決、って話では全然無い。

そういう訳で、たぶん私一人では目標としてる所までは行かないし、その先が続いていく事も無いけれど、 もう幾つか思いがけない何かが重なればうまく行く、と思ってるし、その何かがあるといなぁ、と思ってます。

まぁ私一人がやる事なんてこの程度がせいぜいよ。趣味だしねぇ。
そういう訳であんまし私一人には期待せずに、なんとかなる方法を模索しようぜ。 私が考えている事の幾つかは今回のリリースやらこのwikiやらに込めているつもりです。

23:46

githubにうつしてくれた人が居たのでそちらに移行。 https://github.com/mumurik/xyzzy

とりあえずはgitの使い方復習しつつ今後の方針を考える。

ツリー的には関係が無いが、かたっぱしからぶつかりそうなのをcherry pickしていって、最後に自分の後ろにがんとリベースかなぁ。
git触るのはmonaいじってた時以来なので2年くらい前だからなぁ。もう忘れた。

あんまし取り込まん方がいいのもあるらしいってのが事態を面倒にしてる。 本当は取り込まない方がいいのは残してmasterにRIしててくれればmasterに対して上の方針でOKだろうが、 さすがに相手の手を煩わす訳にもいかんので、こっちでどうにかする方向で考えよう。

ざっと見た所ぶつかる所は限られてるので持ってくるのは(短調作業はかったるいが)難しい事は無さそう。

そしてgit guiだとChangeLog.txtが化けるんだが、どのクライアント使ってるかしら?TortoiseGit?

2012/02/20

あれ?昨日の日付が一日ずれてるな。まぁいいや。

sessionを直したつもりだったが直ってなかったので直してmultiframe_full_20120220.zipを作る。 これがさすがに最後だと思うが…

と思ったらhookの名前変え忘れに気づく。まぁこんなもんだ。直さなくてもよかったが、まだ前のがダウンロード0だったので、multiframe_full_20120220_2.zipに差し替え。

sessionのread時にmenuがねーとか言われるのを見つける。multiframe_full_20120220_3.zipに差し替え。 なかなか細かいの出てくるね。

20:00

よし、正式リリース!タグも打って、multiframe_0_2_3_1_20120220.zipというのを作った! 以後は0.2.3.1と言ったらこのzipをさします。これを作った元のタグも打っときました。
中身はmultiframe_full_20120220_3.zipと同じだと思います(一応作り直した)。

皆様 https://bitbucket.org/mumurik/xyzzy/wiki/Home の宣伝よろしく!

22:13

バージョン番号の話とか書いてみるか。

23:48

共通設定の指定幅で折り返し、が保存されない、というバグ報告を受ける。こんなのあったんか。
中を見ると指定幅での折り返しの扱いの考慮が足りてないなぁ、という事で抜本的に直す方向で。

ただ、結局報告のあったケース以外では被害が無いので、次回のリリースに含めれば良さそう。 そういう訳でcommitだけしとくがリリースは後回し。

24:00

folding回り直したらmini bufferもfoldingされるようになってしまった。修正は明日だな。 そしていろいろframe分を忘れてるfor文をチェックしてだいたい直す。その結果バッファのモードラインが別フレームのは反映されないって言ってたのが直った。

2012/02/18

mode-line-formatの%/動いた。だいぶコードも良くなったのでこの手の追加するのも簡単になった。 急いでリリースする必要は無さそうなので、今日これからの作業の分も含めて今晩リリースで良かろう。

今日はコマンドバーを直すつもり。たぶんメニューまでは届かないかなぁ。メニューが終われば完成なんだが、メニューは今回はやらないかも。 ちょっと変更量のでかさにモチベーションが足りてない感じ。

そういう訳でコマンドバーを直したら最初の正式リリースに近い感じかなぁ、と思ってる。 少し叩いて平気そうならバージョン番号上げようと思う。0.2.3.1かしらね?

12:46

とりあえずRCをリリース。これまでさぼってたbyte-compileとかもちゃんとやるんで、上書きインストールの時も再ダンプすればOKになったぜ。といってもカスタムのlispは動かんけどね。

バージョン番号も0.2.3.1にしてみた。一応これで少し様子見て、問題無さそうなら正式リリースかな。

17:28

リリースに向けてページを整備したり。 皆にはここのトップページを紹介してもらいたい、と思っているので、初心者にも読めるような物を目指している。 達成出来ているかはフィードバック待ちだが、まぁフィードバックしてくれる人はいなかろう。

今の所2chのスレ見てる人くらいしか存在を知らないんだよなぁ。 リリースはmixiのxyzzyコミュにも書くつもりだが、別のトピを立てる程頑張ってはやらんつもり。

いまいち宣伝する場所が無いんだよなぁ。 publicなtwitterアカウントとか持ってないし。 正式リリースした暁には、皆様ここのWikiのHomeにRTしたりはてブしたりして下さい。

22:31

C-x 5 1, C-x 5 0を使うんだが…と友人に言われたので実装。 ユーザー数少ないのでユーザーの声はやけに簡単に取り入れられます(w
この辺でリリースかなぁ。

ちなみに私に本家の開発引き継いで欲しいなぁ、と思ってる奴は多そうだが、俺も誰か開発続けてくんねーかなぁ~、と思ってるよ。
つまりそう思うのは分かるが自分の印象としては「そういうおまいが続けろお!」という感じ。

ただダウンロードして叩いてくれてる人には感謝してます。 あんたらのおかげでここまでこれました。ありがとう。 ってここで書いても仕方ないね。リリースして一段落ついたらスレにも書くよ。

ただもうちょっと宣伝してくれるとなお嬉しいね。 なんか2ちゃんねらーしか知らない秘密プロジェクト状態なので(全然秘密じゃないんだが…)

23:16

そろそろ寝るのでzipを作り直す。これがrc3になります。そろそろリリースかな、と思ってる。 RC2との違いはC-x 5 1, C-x 5 0が入ったのと*features*が入っただけなので、無理してアップデートはしなくてもいいです。これから落とす人は新しい方落としてね(はぁと)

2012/02/17

セッションが開けねーぞ!という事で調べてみるとbuiltin.lのかっこの閉じ忘れ発見…

この為だけにリリースするのもなぁ、という事でついでに%/を実装してみようのコーナーを発足させるも割とかったるい。
基本となるbuffer_infoのformatを実装するのは一瞬なんだが、これではキーが入力されるつど反映はされない。
どうするかというとおおざっぱには

  1. paint_mode_line_point相当の物のパーセント版を作る
  2. paint_mode_line内で一か所だけ飛ばすのを、こういうのが複数ありうる、という感じのfor文に変更
  3. 適切な場所でw_point_pixel的な物などを更新してやる

という感じでいいんだが、実際にやるとそれぞれちょっとかったるい。 かったるいっていうか、ほとんど%Pと同じ処理なのでいい感じに関数化したいのだが、こいつがやる気ない実装なのでいい感じに関数化するのがちょっと頭使う。

実際毎回redrawしてもいまどきなら平気だと思うんだが、こういうのの積み重ねがきびきびした動きにつながるという部分もあるので、あんまりいまどきっぽく直したくは無いんだよなぁ(やるなら本気の計測環境とかからやるべきという気がする)

22:24

最初はどう手をつけたらいいか途方に暮れる感じだったが、%P絡みだけを別クラスに分割してみたら結構行けそうな感じに仕上がった。 ちょっと完全に分離はしてないが、目処はついたので良しとしよう。

24:00

%/のコードは書いたがもう眠いので実際に動かすのは明日。
もう少しいじればlispレイヤーでも定義出来るように出来るが、まぁまだいいか。将来やる日が来る時の為の準備って事で。
ちなみにパフォーマンスにはかなりうるさい作りになってるのでformat一個定義するだけじゃダメで、桁数が変わるかとかアップデートいるかとかいろいろ定義してやらないと使えないのでlispで書けてもまぁまぁ面倒。

2012/02/17

anything.lを少し見たけどまだ治せず。延々二分探査すればいいんだが、かったるいなぁ。 debug-on-errorを実装したくなる。

10:02

一時間ほど追って、sources.lのbyte-comnpileし忘れだったorz
まぁanything.lというのがどういうコードかはだいぶ理解したのでいいか。

2012/02/16

セ◯社員がC-x 5 oが無いとめんどくさくて死んじゃう!というので仕方なくother-frameを実装しようと思い立つが…
引数とかはまぁ無視でいいだろう。前にしかいかねーっしょ?とただSetFocusするだけのコード書いたらキャレットが変な場所で表示されてる。 フォーカス回りはリモートデバッグ環境にしないとVSにフォーカス取られて開発が面倒なんだが、そこまで必須って機能でも無いしなぁ。
仕事柄リモートデバッグは得意ではあるんだが。

昨日はいろいろxyzzy以外の作業がはまってて全然進んでないが、情報が集まってからの方がいいという部分もあるのでこれはこれで良かろう。diff.lが動いていないとか予想外の物も発覚したし。

KaTeX追い
動かないよ!という事で報告があったKaTeX。論文書きとかだと地味に重要だからな、texは。
そういう訳で追ってみるとこいつが難易度高かった。なんかスタックオーバーフローになちゃって開発機自体の動きがとろくなるのでやる気がなくなる。
結果としてはtool-bar関連のほかは

(fset 'select-frame #'select-pseudo-frame)
(fset 'selected-frame #'selected-pseudo-frame)

こいつがいろいろ無限ループを生んでいたようだ。selected-frameはちゃんとしたのを実装した訳だが、select-frameは実装してないよ。 ダミーにしておこう。

;(fset 'select-frame #'select-pseudo-frame)
;(fset 'selected-frame #'selected-pseudo-frame)
(fset 'select-frame #'(lambda(frame) ()))

これで動く。 command-bar関連はコメントアウトしておき、app-menuはちゃんとマルチフレーム対応しておく。

あとでcommand-barを見る時にもうちょっと真面目に見よう。ここまでの版を上げておくのでつついてもらえたらつついてもらうかな。 でかすぎてちょっと追い切れない。

次はdiffかしら。

diffわかんねー

どうもexecute-shell-commandの結果が出力されないっぽい。call-processが違うようだ。 でもこんな所いじってないし、見た感じただしそうに見える。なんでCreateProcessした結果がoutputに吐かれないのかな?

18:51

class dyn_handle
{
  dyn_handle (const dyn_handle &, int = 0);
  operator HANDLE () const;
...
};

こんなクラスがあって、

  dyn_handle hout;
  si.hStdOutput = hout.valid () ? hout :  GetStdHandle (STD_OUTPUT_HANDLE);

このコードの時、valid()はtrueなんだけど、houtのHANDLE()が呼ばれる前にコピーコンストラクタが呼ばれるんだよね。 これがdiffが動かなくなった原因なんだけど、なんで呼ばれるの?

メニューは後回しにしようかなぁ

メニューは結局モデルとビューを分離する、というか、モデルをGUIとは別に持つように変更して表示の時に動的に生成、って感じにするのが王道だと思う。あえてそうじゃないのがxyzzyの良さだと思うんだが、こういう事態になった以上書きなおすのが正しい姿だろう。

これは実際そんなに難しい作業じゃない事はわかってる。というのはtoolbarはそういう実装になってるから。 だから実験的な部分はあまりなくて、たぶんやれば出来る。

出来るんだが、結構大きな変更なのでやる気が出ない。マルチフレーム関係無いし。
ほとんど全パッケージが変更無しで動くようになるので、たぶんやった方がいいんだろうが、かったるい。
そういう訳で当面はmultiframe用に良く使うパッケージを修正して凌ぐかなぁ、という気がしている。 簡単だしね、修正。

週末コード書き大会とかあったらそこで一気に直しちゃうかもしれないけど。

browserexカスタム版
とりあえず*app-menu*を(get-app-menu (selected-frame))に置換して、*app-menu-popup*と(get-app-menu-popup (selected-frame))に置換して、と三つくらい置換したらあっさり動く。donwloadsに置いときます。

やっぱ大変更よりも前にこれで少し凌いで叩いてもらう方がいいよなぁ。

既存のパッケージをmultiframe用に変更する
なんてページを作ってみた。 皆がやってくれる、というのを期待してる訳じゃないが、どの位簡単なのかは示しておいて良かろう。

22:10 multiframe_full_20120216.zip リリース

diffを直したのとC-x 5 2を追加したのが主な変更。C-x 5 2が無いと死んじゃう!って人以外は前のバージョンでも問題無いと思う。
diff.lのfixはどの位同じ類のバグがあるのか分からないのでリリースしておいた。電八もこれで治る?(分からん)

2012/02/15

世の中のlispパッケージをどうするか、という問題に軸足を移す時が来た!…かな?
2chでbuf2html.lとbrowserex.lが動かない、とあったがbuf2htmlは普通に動くなぁ。 それっぽいコードは幾つかあるので設定次第で動かない、って感じか。
buf2html-set-app-popup-menuとかを.xyzzyで呼んでるのかしらね。 menu使うのか、とちょっと意外な驚き。俺全然使わん人なので。
multiframeもいまだにメニューに追加されてないしね。

ちらっと検索した所*app-menu*と*app-popup-menu*か。今はhashになっちゃったのでどうしたもんか。 最初に起動したフレームはこの変数を使うようにし、hash側には参照を突っ込んどく、 hashの変数名は変えて、*-mapとか後ろにつけるか。

最初からそうしとけ、って話はあるんだが、うっかり変に動いちゃう状態で開発は厳しいので、一旦あえて動かなくさせてもらったのですよ。 これを直しちゃうとうっかり変に動くようになってしまう物もあるので、他が安定するまではやりたく無かったんだが。
もう割と他は安定してきたかにゃ~?

11:00
C-x 5 2が無いとだるくて死んじゃう!という意見をもらったのでアサインする事に。
ってあれ?split-window-verticallyがC-x 5にアサインされてるぞ?なにこれ?
良く分からんがC-x 3にしておく。なんで5なんだ…

C-x 5 oは実装してません(キリッ!
いや、簡単なんで要望ありゃやるです。

一応ここに*scratch*バッファeval用のコードを置いておこう。

(defvar ctl-x-5-map (make-sparse-keymap))
(setf (symbol-function 'ctl-x-5-prefix) ctl-x-5-map)
(define-key ctl-x-map #\5 'ctl-x-5-prefix)
(define-key ctl-x-5-map #\2 'make-frame)

12:00
メニューは見直してみるとWindowsのハンドルを直接触る感じになってるんだよね、そういえば。
こいつをモデルとビューで分離する、ってのはやれば出来るんだが、、、面倒くさい。
以前ブラウザ屋に聞いたら分離するにきまってるだろ!的な対応をされたのを思い出す。でもやっぱかったるいよ。

cmdbarの方はモデルは単なるlistになってるので簡単なんだよね。なんでmenuはこうしなかったのか。

とりあえず既存のAPIを使ってる分には最初に作ったフレームだけに更新されて、それ以外を望む人は新規API使ってね、という感じにするか。

でも新規APIを呼ぶ手頃なhookがあるか?frameのloadでいいんだが、menuのinitとかが呼ばれるべきな気がする。
既に*init-app-menus-hook*ってのはあるんだが、こいつは一回しか呼ばれないべきか、frameが作られるごとに呼ばれるべきか。
今コード見直したらフレーム作る都度呼ばれるな。まぁいいや、ここでやれば。

既存のコードは一回を想定している場合もある気がするので、こいつを初回のメニューの時だけ呼んで以後は*init-app-frame-menus-hook*とか呼ぶ方が被害は少ないんだろうが、名前的にやっぱオリジナルの名前はフレーム毎だし、名前と実態をずれさせるのは禍根を残すからやめとこう。

2012/02/14

hanoi問題解決。ただしバイナリリリースはまだ。何故ならM-x hanoi中にC-gが効かない事に気づいたから。 オリジナル版は効く。なんでだ?

> GetCurrentThreadId()とすべき所をGetCurrentThreadIdを渡してた…

これで一通り終了かしら?

define-command-barがサードパーティーに優しくないのでこの辺は直すか。 lispレイヤーのみの話だけど。

2012/02/13

Wikiを頑張って更新中。Homeマルチフレームとは

hanoi問題、emacsで調べてもらった所だとただブロックするだけっぽい。これに習っておくかなぁ。

現状だとフォーカス変えるとC-gが効かなくなるんだが、これ、オリジナル版でもそうだなぁ。なんでだ?バグっぽい。 ついでに直しておくか。

実験用コード

(setq a 1)
(while (< a 10000)
  (setq a (+ 1 a)))

数字は用途によって大きくしたり。

9:46

そういえばWikiへのスクリーンショットはhg pushする、と書いてあったのでTortoiseHGでWikiをcloneしたら日本語のWikiNameが文字化けしてpush出来ない…

こんな初歩的な部分で問題があるとは思いにくいしぐぐっても誰も同じ事言ってないんだが、どうなってるの?これ。 downloadsに置いてお茶を濁す。一番上に来るのは邪魔だからzでファイル名をはじめるべきか?

21:39

C-gは裏でスレッドを動かして、ForegroundWindowがxyzzyのウィンドウならHOT_KEYをレジスターしてる。

でも、しばらく裏で無限ループ回すとghost windowになっちゃうので、ForegroundWindowがxyzzyとは別のハンドルを返しちゃうんだな。 だからオリジナルのxyzzyでも再現するね。

理屈は分かったがどうしたもんか。ghostから元のハンドルが取れるか、ループの中でメッセージポンプ回すか。 ghostをdisableにしてもこの場合は問題無いんだが、問題ある場合のexperienceが最低だからなぁ。

if(!msg.wParam)
{
	// may be ghost window. 
	if(IsHungAppWindow(hwnd_fg))
	{
		if(IsHungAppWindow(active_app_frame().toplev))
		{
			msg.wParam = 1;
		}
	}
}

こんなコードを足してみた。 これはforgroundのウィンドウがハングしてて、xyzzyのウィンドウがハングしてたらforgroundとちがくてもxyzzyのホットキーを足す、という物。

偶然xyzzy以外もハングしててそのウィンドウを表に持ってきた時に間違って足しちゃうんだが、そんな事めったに無いし、どうせそんな事態ならxyzzyをタスクマネージャーからkillする感じになるから変なホットキーがregisterされるかどうかなんて小さな問題だろう。

ついでにframeでもC-g用のスレッドを立ち上げてしまっていたが、一個ありゃ十分じゃね?と思い直し、quit_thread_entry回りをいろいろ書き換え。 なるほど、これがC-gがたまに食われた理由か。

2012/02/12

今日C-gしたら突然画面が灰色になって何も表示されなくなった。なんだこれ?あまり再現しないが。 C-g回りはなんか変だなぁ。落ちた時もC-gした時だったし。 >frame対応が終わってなかったせいっぽい?set-window-configurationに変なの渡したらなった。

pseudo-frameの期待動作を考えよう。 まず、pseudo-frame自体はツールバー無しでも存在する概念だ。 普通に考えればフレーム同士で共有すべきか。

ただ、実行時にdelete-other-windowして現在のpseudo-frameになる、というのはカレントのframe(pseudoじゃない方の)のみの挙動であるべきだろう。 それ以外のframeはただpseudo-frameのtool-barに新しいframeを追加するだけで良かろう。

なんか変な機能だよな、pframe。

frameはオプショナルか必須か
最初は基本的にはframeは必須で作業してた。型チェック的な意味で、なんとなく動くよりもちゃんと動かない方が良かろう、と。
ただ、やってみると結構多くの場合、というかほとんどのケースで(selected-frame)渡しておけばいいんだよなぁ。 emacsでもminibuffer-windowなどがframeを必須としないし、split-windowなどに至ってはframe引数無し。 emacsとの互換性は出来るだけ重視したい。

そう考えるとframeはオプショナルにすべきだな。途中で変えると訳わからなくなるからpframeの作業が終わってからになるが、 オプショナルにしようと思う。menu-barのような物のemacsの扱いを見ると本当何も出来ないんだよなぁ。 この辺のwindowハンドルが触れるのがxyzzyらしさな気もするんだが。

どうもpseudo-frameの期待動作が分からない 実装を進めていってふと気づいた事だが、これ、multi frameと組み合わせたらどう動くべきなんだろうか?

最初はpseudo-frameという概念はframeローカルじゃないと思ってた。 pframeのリストは二つのフレームで同じのが表示されてれば良かろう、と。

でもset-window-configurationする段になって、それじゃあおかしい気がしてきた。 もともと二つのフレームはsplitしたりは自由に出来ていた。 という事は概念的にpframeをグローバルにするなら、この二つは別のpframeであるべきでだ。

でもこの実装はlispレイヤーで誤魔化しとして実装されている。だからそんなコアな部分に導入は出来ない。

とここまで書いてフレームごとにpframeのリストを持つしか無い事に気づく。 互換性は無くなるが仕方ない。ローカルじゃないんだから。 外の口はなるべく揃えるが、*pseudo-frame-list*を直接触る人は動かなくなるのは仕方あるまい。

一通り動く所まで 動くようにはなったが、define-history-variable回りの挙動が直観的じゃないなぁ。
たとえばbuffer-barをonにしたフレームとoffのままのフレームがあって、終了した時にどちらの値が残るでしょう?みたいな。
そしてbuffer-barをonにしても新しくframeを作るとbuffer-barがonじゃない。
でもbuffer-barをonにして「終了して」また起動してmake-frameするとbuffer-barがon。 この辺は分かりにくいが、いろいろ試した所これが一番正しい振る舞いっぽいので諦めるかなぁ、と思ってる。

ルーラーは追ってないけどなんかrepaintが呼ばれてないだけっぽい気がするので後回しでいいか。
次はactiveかなぁ。

active回りあれこれ
まずフォーカス、SetFocusをコメントアウトした所ふつうに動くんだが…なんでこれじゃダメだったんだっけ?全然分からん。 なんかすごい落ちやすくなった記憶があって、原因も理解したはずなんだが…全然落ちないがな。
もうすべてを忘れた。しばらく使ってみよう。

そしてmake-frameした時にマウスの入力を受け付けなくなるのはtoplevel_is_activeが0だからだな。 これ1にしてしまえばいいんだが、そもそもにこれ、frameローカルじゃなくてxyzzyグローバルな物のような気もする。 ログを見直すとこれはApplicationFrameに間違って移動してしまった物のようだな。Applicationに戻しておこう。

2chモードも動いてしまった…
これの対応作業でxyzzyをつつくか、と思ってたが、一発で動く。どうしたもんかなぁ。 SetFocusがどうなのかもうしばらく触ってからリリースしたいんだが、触るネタが無い。

と思ったがタブがまずそうなエラーメッセージ出す事がある。これをちょっと追ってみるか。

2ch-mode、修正は二か所

main.lとthread.lで

(ed::pseudo-frame-name ed::*current-pseudo-frame*)

としている所を

(ed::selected-pseudo-frame-name)

に変更。そしてこの二つのファイルをbyte-compile-fileしたら今の所問題無い。

  • current-pseudo-frame*はなぁ。一応最新版らしき物を入れておくって対処も出来なくは無いが、今はハッシュになってるんだよね。
    この変数だけなら違う変数を普段は使って外向きにはこの変数を最新の値にして出すってのは出来なくは無いが、 どの変数が触られるか分からないからなぁ。

とりあえず直した版をdownloadsにでも置いておくか。

リリース
ちょっとつついてもさっぱり落ちなくて面倒になってきたのでリリースしてしまう事に。 たぶんまだ落ちる部分はあると思うのだが、エディタでやる事が今手元に無いのですよ。

現状は開発のターンアラウンド重視で幾つかの.lcが無い。 だから上書きインストールは出来ない(というか一部バイトコンパイルがいる)のですが、ある程度安定してきたらちゃんと.lcも含まれたバージョンをリリースして、既存のに上書きして.wxp消せば使えるようにするつもりです。

とりあえず本格的な紹介ページを書きますかね。

2012/02/11

グローバルだった*app-menu*をframeごとに持つようにする結果、niftylog.lとsession.lを書き直す事に。 うんざりだが仕方がない。
結局既存の物に影響を与えない範囲で出来る事なんて限られているのだ。

9:16
とりあえずメニュー対応が終わった物をリリースする。以後はlispをいじる、という基準となるバージョンのつもり。
メニューの中身は動かないのもあります(フレーム絡みとか)。

一度他のウィンドウを選択しないとマウスが効かないのはなんなんだろうか。 activate絡みと一緒に真面目に見る日までほっとくか。 たまにC-gがどっかに食われてる気もするんだよな。

で、コマンドバー対応。どうしたらいいのかね?
例えばcmdbar.lのロード時に

(define-command-bar 'std-tool-bar "標準(&S)")
(define-command-bar 'buffer-bar "バッファ(&B)")

とか呼んじゃうんだよね。これがWindowsのハンドルを作っちゃうのでdupは面倒。 init的な物に分離されてればそれを呼ぶ、でいいんだが。 ロードだともう一回ロードするとかは嫌だし。

しかもhistoryのload hookでなんかやってるんだよなぁ。 これはhistoryのloadと関係なくhookもう一回呼ぶ、でもいいのかもしれんが…
少し気持ち悪いよなぁ。やっぱりexportして呼ぶべきか。historyがロードされてないと呼べない関数ってのもそれはそれで気持ち悪いが。

historyは一旦忘れれば、一応cmdbar.lとpframe.lの二人しかdefine-command-barはやってないから、init的な物を呼ぶように直しちゃってもいいかもしれない。 とりあえずbeffer-barの方が実装が簡単だからそっちから直すかなぁ。

pframeは自分は結構使ってたんだが、実装面倒だしframeとそもそも機能かぶってるから後回しでいいか? なんにせよtoolbar回りはバグバグなのでちょっと真面目に実装追う必要はありそうだ。

21:38
全然楽じゃなかった>buffer-bar
一日作業になってしまった。一応動いている。ルーラーが変だけど。

一日作業してたら一回落ちた。少し調べたけど原因が分からないなぁ。 ルーラーがおかしいのと場所的には似てそうなので、ルーラーのバグは優先度あげるか。

buffer-barはだいたい満足な動きをするようになった。次はpseudoフレームだなぁ。これも一日作業になるのかしら?

ちなみに2chで2ch-modeが動かないという話が。いかにも動かなさそうだなぁ。 pseudoフレーム対応も終われば落ちなくなってロードに失敗するようになると思うが。

既存のパッケージはなるべく変更無しで動くように、というのは一つの常識的な発想ではあるが、一方でオリジナルのバージョンに過度に合わせて無理が出て不安定になってもなぁ。
結局あるべき姿にしておく方がさらに次に進む時の為にも良い気もする。 オリジナルのバージョンから変更をする以上、オリジナル向けのコードでは動かない部分が出てくるのは当然な気もする。
とりあえず2ch-modeを見て、するべき変更と回避出来る変更の比率を見てみるか。

2012/02/10

set-menuの引数をset-menu(menu)からset-menu(menu, frame)に変える訳だが、frameはオプショナルか必須か。
既存の物が動くという点ではオプショナルにしておく方がいいんだろうが、直し忘れが見つかりにくくもなるんだよなぁ。
もともとset-menuの引数はWindowsのハンドルなので、全員にセットしてやる、とかできないんだよね。 使う側がその辺は気を付けてやらなきゃいけない作りになってるのだ。
するとrequiredにする方が筋な気はする。それでちゃんと動かなくなる方が良かろう。
でも既存のlispがなんとなくactiveなframeに追加する、という形で動く方が自分でいじる気の無いユーザーは嬉しいだろうなぁ。

どうしよっかなぁ。とりあえずrequiredにしといてあとで考えるか。

app-menu.lの変更はwxp削除しないといけないのか。面倒だなぁ。

Vdefault_menuを直したがVlast_active_menuとVtracking_menuも直さないとダメっぽいなぁ。 まったく同じ変更で単純作業なんだが、まったく同じ変更でいいのでやる気が出ない。 なんにせよmenuは終わりが見えたかな。

21:04
メニュー対応が終わったんだが…なんかたまにメニューがグレーになっちゃうなぁ。 再現条件が良くわからん。以前2chで指摘があった時はC-gで止めると、とかあった気がするが、とりあえずfind-fileをC-gしただけだと再現しない。

うーん、どうしようかなぁ?一旦リリースか? そろそろlispいじるから全部入りリリースしか無い感じなんだよなぁ。
まぁいいや、とりあえずリリースして再現方法を見つける神が現れるのを待ちつつpseudoフレームの対応でも進めるか(ぉ

そういえばどうせ全部入り出すならdocstringもつけちゃいたい、と思ったのだが、ref2doc.lってもう無いのかしら? ある場所知ってたら教えてください(どうやって?)

21:56
lispをいじり始めたので以後は全部入りをリリースする事に。 一部.lcは削除していたりします。
既存の環境に入れてる人は、.l、.lcの更新忘れやxyzzy.wxpの削除し忘れに注意(readme_multiframe.txt参照)。

まだバッファーbarとかpseudoフレームとか対応終わってません。

22:26
うが、フレーム閉じたら「メニュー ハンドルが無効です」とか出る。なんじゃこりゃ。 という訳でリリースはとりやめ。

そうか。recent historyに追加しようとしちゃうのか。lisp側でもハッシュ触れないとダメって事だね。 うーん、C++側と二重持ちか。まぁいいか。明日やろう。

2012/02/09

lispの更新開始。そしてその過程で裏でファイルが更新されてる時の落ちバグを見つける。 直したけどバイナリリリースは次のlispと同じタイミングでご勘弁。 たぶん今日中には何かリリースするんで。 やっぱ実際に使ってないとバグは見つからんやね。

12:00現在は

  1. frameのhookの名前をemacsに合わせる
  2. next-frame, selected-frameを実装

まで終わった。 次は初期化周りでframeオブジェクトを渡すように変更。こいつが終わればC++側は一揃いするので残りはlisp側の作業となる。

20:46
無事frameオブジェクトをstartupに渡す所まで来た。 次はmenuだね。とりあえずapp-menu.lを直すのはいいとしてexportしてる*app-menu*とかはどうしたらいいんかなぁ? これにあとから追加する奴とかいるよね。
当面は最後のframeの値をexportしとくとして、本来の期待動作はなんなんだろうね? 追加とかの関数を定義して、中身でforeachで回してすべてのframeに追加、とかかなぁ。 そして新しくframeを作る時には今のmenuを引き回す。たぶんこれが正解なんだろうが、既存の流儀を変えるのは説明がかったるいなぁ。

なんにせよまずは動く事だ。追加する時の挙動はあとで2chででも話せば良かろう。

それなりに使って動いているのでバイナリリリース。前の版は裏でファイル更新されると落ちる事があります。
すみませんがアップデートお願いします。

21:52
menuはVdefault_menuをrefreshの時に表示するって作りか。大胆だな。
set-menuでframeのリファレンスを渡すようには簡単に変更出来そうだが、そのあとどうするか。 簡単に考えるならApplicationFrameにメンバ増やしてlispオブジェクトを持たせちまう、って感じだが。 今後こういう事はたくさん起こると思うんだよなぁ。
ApplicationFrameにハッシュを持たせるか?make_hash_tableをC++側で使ってる例がないなぁ。 なんでだろう?なんかまずい理由があるのかしら?面倒くさいのかな?funcall_1とfuncall_2で良さそうな気もするが。

ここは一つ分岐点だな。hashをlispレイヤーで管理させるか、C++レイヤーに一つフレーム用のハッシュを持たせるか…
ってここまで書いててlispレイヤーが筋な気がしてきた。 同じハッシュじゃ名前のバッティングとかあるし、こういうのはlispの側で頑張りすぎるのがemacsからの伝統だからな。 frameリファレンスをキーにしたハッシュに突っ込むように実装を変更し、refresh側ではhashをlookupしよう。

2012/02/08

2chに自分の日記書くのもどうかと思ったが、記録をオープンな場所に残しておく価値がありそうな話もあるしなぁ、と考えた結果、ここに書く。

まずはxyzzyスレ part 17での472のバグの話。
http://toro.2ch.net/test/read.cgi/win/1303662374/472

  1. DONE 同じバッファを複数ウィンドウで表示しているときに一方で編集しても他方に反映されない
  2. DONE F2でも叩いてダイアログ出して、一旦別フレームにフォーカス移してダイアログ閉じるとまた開く
  3. M-x hanoi で動いてる途中にほかのフレームにフォーカスもってくと長時間応答なしになるとか(一応C-gでとまったきがする)。

以下はlisp

  1. バッファバー (表示→ツールバー→バッファ) がそれぞれのフレームに付かない
  2. 別フレームでC-gで止めるとメニューが無効になったまま
  3. フレーム増やすと最初のフレームのメニューアイテムが機能しない

ここでhanoiの話。
これはようするにlisp実行中にselected-bufferが変わっちまうのはまずいんじゃないか?という事。
じゃあWindowの切り替えはどうなってるんだろう?とWindowのwndprocを見てみると、WM_SETFOCUSやWM_MOUSEACTIVATEはtoplevelにfocusを当てるだけ。
じゃあ自身にあてるのは誰か?というとmouse.lのmouse-left-press。

ようするにすべてのイベントを一番上のframeが受け取ってるんですな。
で、それを処理するのはlispの中なので処理中にfocusがうつっちゃう、って事は無い。
それはまぁいいんだけど、frameのように親子関係が無い物はどうしたらいいのかしら?
lispのエンジンは見えないHWNDを持って、すべてのactivateは一旦こいつに投げる、というのがありか?いや、無しだな。
Windowsのフォーカスやキーボードは本質的にframe単位なのにframeをまたいで管理するのはなんかまずい予感がする。

lispの処理中は単純にactivateを無視する、でとりあえず動かないでも無い。
ただやっぱりwindowのフォーカスに比べると堅さがいまいち。
ここは良く考えた方が良さそうなので、一旦このまま放置で違う作業進めつつ考える事にする。

現状とか今後の方針に対する考え

ここまでの方針として、まずC++のレイヤーを固める、と考えていた。
一度に両方変更していくと原因の切り分けが大変になって収拾がつかなくなる、と思ったから。
だからlisp側ですぐ直り、かつ被害が大きいメニュー周りとかをあえて直さないでここまで来た。

でも、そろそろC++レイヤーの大きな部分は治ったかなぁ、と思っている。
細かいのは今後も出続けるとは思うが、なんというか、アイデア的にオリジナルのxyzzyの実装と不整合、というのはだいぶ潰せたという認識。 たぶんまだ残ってる大きいのは上記のhanoiだけなんじゃないか。
だから次はlispレイヤーを直そう、と思い始めている。

このバージョンはもともとエイプリルフールのネタから始まってて、意外とちゃんと動きそうだったのと自分の友人もmultiframe使いたい、と言ってたので、自分ひとり+友人一人が使えればいいか、という考えで作り始めた。
試してみるのが無駄に面倒なのもいわゆる普通のユーザが誤って使ってしまうのを防ぐという部分がある(リリースさぼってるから、ってのが一番だけど)
ちなみにその友人は今は使ってない。裏切りもの~(T_T)

で、自分一人で使う場合の最優先は落ちない事。
xyzzyでの作業は一旦落ちるとなに開いてたのかとか忘れて大変面倒なので、 どのようなレアケースにせよ自分がやる作業なら完全に落ちなくする気でいた。
逆に使ってて変とか使いにくいとかそういうのは気にしないでいた。
メニュー変でも俺メニュー使わんし、片方の変更がもう片方に反映されないんだけど、みたいなのも別に表示が変なだけだし、という事で最初は直さなかった。

なのだけど、当初いい加減にごまかしていた部分が実は落ちバグにつながってたりで、なんだかんだでちゃんと実装しなおさざるを得ない事情がちょこちょこ出てきて、結構まともな実装になってきた。
だから、lispレイヤーも直して、一般向けにリリースしてもいいかも、と心変わりしつつある。
たぶん上記hanoiのバグが治ったら一般向けリリースする事になるかな。

そこまで本当にやるかはまだグレーだが、もしそこまで行ったらmultiframeとは何か、どう嬉しいのか、という解説を書いたり、ダウンロードしただけですぐ使えるzipを用意したりするつもり。
現状だとemacsのmultiframe知っててあれが欲しい!って思ってるユーザー以外は完全無視状態なので。

ちなみにこのバージョンの方針としては、multiframeに必要な変更は、どんなに大きくても入れる、という物です。
オリジナルのxyzzyをなるべく保とうとは、あんまりしません。
結果としてオリジナルが枯れてた部分がまた不安定になります。
ただ、結構本気で直していくつもりの副作用として、オリジナルの現在の実装では直せないようなバグも直す気でいます。

落ちバグ報告は大歓迎です。再現方法わからなくてもどの位使ったら落ちた、って話だけでも結構欲しい。
lisp書き換え手伝ってやるよ~、って人も大歓迎ですが、こちらはちょっと敷居も高いと思うのであまり期待はしてない。 一人で泣きながらやるつもり。

Updated