週刊mosh - CMakeビルド不発/Moshを選択する理由

イベントが取れるように(callback)。開発はXCodeとVisualStudioの両方でやってます。
0.2.6のリリースから1週間ほど経って、mosh 0.2.6のダウンロード数は16と個人的にDLした数の半分以下の低調な滑り出し。
...Google codeのダウンロードカウントは直接DLをカウントしない..?

CMake不発

今回の0.2.6はCMakeをサポートした最初のリリースですが、スムースにビルドできない事故が多発。。
LinuxとMacOS X上でのCMakeビルドは次のリリースで直します。
ビルドが難しいWindows版に関しては両方について一応記事を書きました。

バイナリリリースについて

実は今回はWindows版のバイナリをまだ出していなかったりします。単純に動作検証の時間が取れていない*1のも原因ですが、

psyntax-moshはキャッシュのバージョニングが無いので、他所で起きた問題の切り分けが困難
埋め込みライブラリパスが固定
mpirをバイナリ配布することになるので、ライセンス文言等の準備が必要
検証環境の準備が大変

といったあたりで停滞しています。CMakeビルドの場合はPrefixを設定できるので、今のところはCMakeを使ってビルド/インストールするのが一番確実です。

GUIサポートに向けて

0.2.7では、

Windows/MacOS Xサポート
REPLコンソールを複数開ける
コモンダイアログサポート: ファイル、フォント
描画専用のWindowを開いて、単純な描画とマウス/キーイベントへの反応ができる

あたりを目標に。
ネイティブWidgetへの対応は後回しにします。今必要としているのがREPLコンソールであることと、種類を絞り込まないと対応が現実的で無いため。
基本的には、可能な限り多くの要素をScheme上で実装するようにしたいので、0.2.7では単にビットマップ表示器としてwxWidgetsを使うことになります。。

Moshを選択する理由

(後で独立した項目にするかも)
他にSchemeはいくらでも有るのに何故Moshなのかというのが地味にFAQなので、個人的な回答 :

移植性: VisualStudioでビルドできる

ActiveStateがActiveMoshを出すまでもなく、(n)moshはWindows上でちゃんと動く。Gaucheのように人気のある処理系でも、この特徴はなかなか備えていない。
VisualStudioでビルドできることの重要性は、1) Windows上のconfigure/makeは耐えられないほど遅い 2) OpenCVやLLVMのような他のVisualStudioプロジェクトと混ぜて使うことができる(gccとVCのデバッグ情報には互換性が無いため、ツールチェーンを統一する必要がある) 3) VisualStudio自体がコンパイラとして地味に優秀。
要するに、Windows社会への適応能力が高く、かつ、LinuxやMacでも開発できる言語としてMoshはそれなりに高いポテンシャルが有る。
PythonやRubyのような他の言語では、言語コアだけを自分のアプリケーションに流用するような使い方はあまり簡単ではないし、Windows環境で言語コアに手を入れるのもそれなりに面倒な仕事になる。

Unicode対応

moshは(R6RSが要求しているので)Unicodeに対応している。

依存関係が少い

moshをビルドするために必要なライブラリはonigurumaとGMP(またはMPIR)だけで、他のライブラリを揃えたりインストールしたりする必要は無い。
...将来的にはonigurumaやGMP自体もオプショナルにしたい。onigurumaは殆ど使われない(と、思う)し、GMPはLGPLなのでアプリケーション組込みの障害になる。

スクリプトをプリコンパイルして内蔵できる

nmoshはスクリプトをプリコンパイルしてREPLの代わりに内蔵することができる*2。ただ、これはmoshに限らずChez Schemeのような処理系でも普通に実装されているし、Gambitのようなコンパイラ型の実装ならもっと直接的に実装できる。
スクリプトをコンパイルして実行環境と一緒に配布したいというのは地味に根強い需要が有る。