週刊mosh: %getpid登場 / Schemeの優位性
あまり進捗せず。0.2.6がそれなりに安定しているのであまりニュースが無いというのも。
getpidとプリミティブのアップデート方法
プロセスIDを取るプリミティブであるところの%getpidを追加した。
nmoshには複数のnmoshを同時に起動するとgensymで使う(時刻ベースの)UIDが被ることが有るという重大な問題が有って、それを解消するために追加。基本的にプロセスIDは十分な時間をおかない限り再使用されることは無いと期待している。
このようにfree-vars.scmを追加するのがプリミティブの正当な追加方法だが、(簡単なのは以前紹介した : http://d.hatena.ne.jp/mjt/20101028/p1 )これをやるとpsyntax-moshが不整合を起こすのでmoshのランタイムを注意して再生成する必要が有る。
簡単には、
- free-vars.scmを更新する
- ./gen-git-build.sh (1度目)
- make && make install この段階ではtestに通らない。
- rm -rf ~/.mosh
- ./gen-git-build.sh (2度目)
- make && make install
のように、2回gen-git-buildする必要が有る。
0.2.7予報
プロセスAPI(nmosh process)は、Win32とPOSIXでちゃんと使えているので、0.2.7に入る予定。
もっとも、APIの決定プロセスがまだmoshの開発プロセス中に無いので、どういう形で出現するかは未定。(mosh process)に追加されるのか、(nmosh process)になるのか等。
wxWidgetsは特に進捗なし。0.2.7ではautotoolsビルドには取り込まない方向にしたので、Linux上でビルドする場合はwxWidgetsの2.9を手動でインストールして、かつ、CMakeでビルドする必要が有るというハードルの高い代物に。。
Cソースコードの生成は0.2.7に入る可能性アリ。過去に(fmt)ライブラリ( http://synthcode.com/scheme/fmt/ )の採用が却下されているので、それに依存しないずっと単純なライブラリを作っていて、OpenCL Kernelsを表現するのに必要な機能を足しているところ。機能性はfmtのCフォーマッタとほぼ同様(ただし出てくるソースの見た目はずっと悪い)。
Schemeの優位性
一番良くない(?)のは、Schemeを使える人は大体他の言語も使えるといった不可逆性な気がする。自分自身上からPerlで書けと言われたらPerlで書く、と、思うし。。逆に、RubyやPerlのユーザがSchemeを使えるかというと難しい問題。
個人的に仕事でSchemeを使うのは高速にプロトタイピングが必要な分野。
例えばPOSIXな環境だったらシェルスクリプトを使って一瞬で終わる仕事であっても、同じスクリプトをWin32環境で使うとなると難しい。*1
nmoshは単体の実行ファイルに内蔵されるライブラリをカスタマイズできるので、必要なライブラリを纏めてWin32を使う開発上流に"アプリケーションとして"スクリプトを使ってもらうことができる*2。
これは単にScheme処理系としてのmoshの優位性(以前書いた : http://d.hatena.ne.jp/mjt/20101114/p1 )だけど、ここからScheme自体の優位性が言える気がする。
つまり、Schemeが使えること自体に、その言語が様々なところで通用するというインセンティブが有る。
ただ、最近は"Linuxに非ずんばコンピュータにあらず"という状況なわけで、そういう状況ではSchemeを差別化するのは難しいという気もしている。
偶然、職場ではWin32を強要されているからScheme(とnmosh)は強力な武器になるけれど、Linuxしか無い世界だったら(上のような理由では)Schemeを選択する理由に乏しい。
もちろん、Schemeの言語自体にも魅力は有るのだけれど、それ以外に、小回りの良さをもっとアピールするマーケティングが必要に思える。
一応、nmoshはこの辺に対して戦略的にやっていて、Schemeに限らず、いわゆるLLとしてはそれなりに特殊な位置を占めている、と、思う(Win32上では)。。もちろん積極的に選択されるためにはドキュメントの整備とか脱onigurumaのような作業を進めないといけないわけだけれど。
