週刊mosh - 0.2.7進捗 / デザインチョイス
こまかいfixが溜まってきたので、そろそろ0.2.7を出したいという雰囲気になりつつ。
リリースのタイミングというのは絶妙なもので、いっそのことスナップショットリリースだけにした方が良いかもしれない。。
0.2.7での変更点(予定)
かなりlikelyな変更点としては:
moshはOpenSSLを標準でサポートするようになるので、インタプリタをGPL互換にするためには明示的にオプションを指定してビルドする必要が有ります。
FreeBSDやMacOSではOpenSSLはシステムに統合されているのでGPLの問題は有りませんが、バイナリを再配布する際のOpenSSLライセンスは依然適用されるので注意する必要があります。
Win32ではOpenSSLをサポートしません。
SSLに関しては、industriaにpure SchemeなTLS実装(GPL)があるのと、Win32やMacOSのように標準のSSLサポートが存在する環境ではそれらを使うように検討しています。
- post install hookの廃止
従来、psyntax-moshのキャッシュをmake installフェーズで行っていましたが、これからFreeBSDのportsに入れたりしていくのにあたって殆んどのパッケージシステムではこの動作を禁止しているので廃止しました。
重要なのは、psyntax-moshのキャッシュをmake後消す必要があること。従来はpost install hookでやってましたが、今回から必須です。nmoshのキャッシュは自動でstale(無効化)するので特に作業は要りません。
多分mosh-configコマンドや他の手段で同様のことができるようになるはず。。
- oniguruma同梱の復活(MonaOS、CMakeのみ)
MonaOSとCMakeビルドで使用されるonigurumaは同梱されるようになります。0.2.6では(Homebrewのために)削除したんですが、CMakeビルドが地味に難しいらしいので同梱に戻します。
代替される可能性のあるライブラリはextlibs/以下にまとめることにしました。(google testは例外。これは実行バイナリに含まれないため。)
- Win32版psyntax-moshの廃止
psyntax-moshのWin32版は殆どテストされていないのと、Win32 process APIに必要な機能(primitiveの動的な追加)がpsyntaxに無いので。
今後psyntax-moshをWindows上で使う場合はCygwin上ということで。。
0.2.7に間に合せたい変更点
- バグ修正
今のところ、SRFI-19に最近のうるう秒が無い問題を修正予定。
- ライブラリpathの追加と組込みモード(nmoshのみ)
moshが組込みインタプリタとして使用されるケースが増えてきたので、それ用の変更を2点: 1) デフォルトのライブラリパスを実行ファイル相対にするオプションの追加 2) MacOSやWindowsのアプリケーション習慣に合わせて、.exeをbin/に配置しないモードの追加。
- 端末関連のプリミティブ(nmoshのみ?)
端末の制御を行うためのプリミティブを導入予定ですが、psyntax-moshでどう対応するかを検討中。。
nmoshの場合、
(library (nmosh private terminals) (export terminal-hoge) (import (primitives terminal-hoge)))
のようにprimitivesを使って内部のprimitiveにアクセスできるんですが、psyntax-moshだと、
(library (nmosh private terminals) (export terminal-hoge) (import (rnrs) (mosh)) (define terminal-hoge (symbol-value 'terminal-hoge)))
のようにする必要が。後者はnmoshだとデバッグが困難になる問題があるので、たぶんpsyntax側のstubライブラリを自動生成するようにするか、psyntax-moshは単に非対応にするかのどちらかにします。(端末制御をするのはnmoshのREPLとスタックトレースだけなので)
- nmoshのキャッシュにPIDを入れる(nmoshのみ)
nmoshのキャッシュは秒単位の粒度でしかUnique IDを持たないので、複数のnmoshが同時に起動すると無駄なキャッシュが生じるなどの問題が起こることがあった。というわけで、キャッシュのUIDにプロセスIDも含むようにする方向。
- 実行中スクリプトのパス取得プリミティブ
意外と必要なケースが有るので。。
募集中の案件(draft)
まだ公式には募集していませんが、必要なのは:
- パッケージのメンテナ or Debianのパッケージングに詳しい人
今のところmoshはMacOSのHomebrewにしか収録されていません。FreeBSDのportsは更新されていない状況です。
通常のパッケージシステムに統合できるように変更を詰めていて、FreeBSDのports、pkgsrcは対応する予定がありますがLinux側は空席です。。
(もっとも、これは直ぐに立候補いただいても、直ぐに作業できる状況では無いです。例えば、DebianはDebianのUnicodeやその他ライブラリに対応するといった作業をしないといけないので。。)
nmoshは既にいくつかの企業で利用されています。
僕自身は、Win32/Win64アプリケーションのプロトタイピングに(カスタマイズした)nmoshを使っています。ある企業はnmoshをUSB機器のテストのためにWin32とCentOS上で使用しています(単にFFIを使ってDLL/soを操作するためだけに)。
というわけで、psyntax-moshのユースケースを必要としています。psyntax-moshとnmoshはいくつかの点でデザインチョイスが対立していて、どちらかに一本化することができていない状況です。多分どこかで妥協点を捜す必要があって、そのためにはどのようにmoshが使われているのかという情報が必要なわけです。
psyntax-moshとnmoshで異なるデザインチョイスを行っている点
基本的にnmoshはpsyntax-moshのdrop in replacementになるように作ったつもりですが :
- expand/runの比率
R6RS Schemeの実行モデルは色々考えることができますが、psyntax-moshとnmoshの最大の違いはここで、psyntax-moshはオンデマンドでexpandを行うのに対し、nmoshは完全にexpandを完了してからrunします。
というわけで、nmoshはスクリプトの初回起動が遅いが、以降はキャッシュを使用するので高速。psyntax-moshは逆にスクリプトの初回起動は高速だが、複雑なマクロを使うとnmoshより遅くなるという傾向が有ります。
- キャッシュの取り扱い
nmoshは$HOME以外にキャッシュを作りません。psyntax-moshは/tmpにフォールバックします。nmoshは常にsecureな方に設計を倒していて、psyntax-moshはperformanceに設計を倒しています。
例外はWin32で、nmoshは.exeの有るディレクトリにキャッシュを作ります。これはWindowsの伝統的なアプリケーション慣習に合わせたもの。
これはnmoshで事実上CGIプログラムが書けないという問題を生んでいるのでどうにかしたい部分。。例えばpythonの.pyoのようなin-placeなキャッシュを考えています。
個人的には、キャッシュの安全性に関してはnmoshの方が信頼できると思います。psyntax-moshはキャッシュを相対パスで行ったり、mosh自体を更新したときに互換性が損われるといった問題が有りますが、nmoshにはそれらの問題はありません。
- Scheme/nativeの比率
nmoshはいくつかの重要な機能をScheme側に実装しています。よって、nmoshは単体の起動が遅い(Scheme側のオブジェクトを大量に生成するので、起動中に起こるGCの回数が多い)という問題を生んでいます。そのかわり、スタックトレースやREPLを純粋なR6RSライブラリとして実装しているので後からカスタマイズしたり、よりリッチな情報を出したりすることができます。
psyntax-moshはスタックトレースやungensymをC++で実装しているので、これらは高速に実行できます。
