Mosh学習日記5

　今日は久しぶりに朝Moshをしてみました。余りにも久しぶりだったので、次にどこを読もうか迷ってしまいました。本日は、眠気眼をこすりながら迷っている間に、数十分が経って殆ど収穫がありませんでした。
　それでも楽しく読みました。前にも読んだところですが、Moshはポートを重要視していて、テキストポートの初期化時にスキャナを初期化しています。そして、MoshはBisonで構文解析を行っています。やはり本格的なコンパイラを作ろうと思ったら、Bisonが要るようですね。そういえば、昔yacc/lexを触った事があるけど、随分長い間パーサジェネレーターを触っていないな・・・
　おっと、いかんいかん。睡魔に襲われてしまった。他は今まで読んだところの再確認になってしまいました。う～ん、頭が働かない。朝Moshをする日は、もっと早く起きて目を覚ましてからしなくてはならないですね・・・
　

Mosh学習日記4

　今日は久しぶりに朝Moshをしたので、その感想を書きます。
　今回気になったのはテストのやり方です。ソフトウェアはテストが大事です。積極的にリファクタリングが行われているプロジェクトでは、なくてはならない存在です。テストの構成を調べてみると、仮想マシンは単体テストに相当するもの。仮想マシン上で実現されている機能については、結合テストに相当するものでした。
　仮想マシンはC++でプログラミングされているので、当然テストコードはC++です。一方、ソケットなどの仮想マシン上で実現する機能については、Schemeでプログラミングされていました。その事から私は、単体テストと結合テストが上手く実施されていると感じました。テストの量は、チーム開発としては少ないものの、ハッカーの個人的プロジェクトではありです。どれだけの精度でテストを行うのかは、プロジェクトの性質と開発人数により異なります。
　次に私が興味を持ったのはポートです。Moshにおいて、ポートはかなり重要なオブジェクトです。ポートは複数の階層になっており、最終的にはヒープから取り出されています。ポートオブジェクトのインスタンスの生成方法に特徴があります。ポートのインスタンスは、Unicodeに対応する為に、直接オブジェクトを生成するのではなく、Objectのメソッドにより間接的に生成されています。Moshはデータと文字コードを分離しています。
　ヒープから取り出されるのは、ポートだけではないと思われます。ポートの他に、シンボル・各種データ・クロージャ・Callable（恐らく関数呼び出しに関する情報）のタイプが定義されています。ヒープの使い方が非常に興味深いので今後調べます。
　

Mosh学習日記3

　今日も2・3時間、夕Moshしました♪私が昨日気になったのは、match_imageです。matchというぐらいだから、関数型言語が得意とするマッチング処理で、FaslReaderが読みとっている事からSRFI が関係していると推測していました。しかし、match_imageがUTF-8のバイナリだったので、確証が持てませんでした。
　そこで、過去のMoshのソースコードを探って、match_imageについて調べてみました。その結果、やはりマッチ処理に関する事だという確証を得ました。どうやら、match_imageはマッチマクロの様です。これが正解か分かりませんが、大きくは外れていないでしょう。
　ついでに、Moshの過去のヴァージョンのソースコードをちょっと覗いてみました。すると、リファクタリングされている様子が伺えました。例えば、ヴァーチャルマシンに関する事は、当初VMだけでした。ヴァージョンが上がるごとに、ヘッダーファイルとソースコードが増えています。その分け方が綺麗で、リファクタリングをしっかりしている事が感じ取れます。
　ソースコードを読み始めて、改めて感じたのですが、ひげぽんさんは凄いです。R6RS準拠だし、SRFIにも対応しているご様子です。恥ずかしい事に、私なんかR5RSしか知りませんでした。ひげぽんさんは常に最先端を行っています。
　それからもうひとつ、関心した事があります。それは、親クラスでマクロを使って、Boehm GCの使用有無を抽象化している部分です。これは実にいいアイデアだと思います。マクロを使ったメタプログラミングは奥が深いです。
　これは、ソースコードとは違う話題ですが、SRFIから言語設計について考えさせられました。Schemeはコンパクトな言語設計を目指しています。それは、正しい事だと思います。しかしそれが原因で、SRFIが生まれてしまうとは皮肉です。とはいえ、C++もBoostがあるし、技術者の創造力はとどまる事を知らないという事かな？
　話しは飛びますが、MoshのVMがポートでやり取りをしているのを見て、Erlangを連想しました。ポートとストリームを使ったやり方は宣言的並列性の手法であり、分散処理と並列処理に向いています。もしかすると、MoshはErlangの要素を取り入れて、分散処理と並列処理に強くなるのかもしれない。ひげぽんさんは、こうした方面にも強いからその可能性は十分にあると思います。
　それにしても、Moshのソースコードは面白いです。また明日も朝Moshします。

Mosh学習日記2

　午前中で疲れた体を休め、今日は午後からMoshのソースコードを読んでいます。その過程で色々面白い事が分かりました。先ず、Moshの仮想マシンについてですが、レジスタ付きのスタックベース仮想マシンでした。備えているレジスタは、計算・ディスプレイクロージャ・カレントクロージャ・フレームポインタ・スタックポインタ・プログラムカウンタです。
　初期化時は、スタックサイズおよび、3個のポートを指定しています。仮想マシンを初期化した後は、コンパイラをロードしており拡張性を感じます。現在はSchemeコンパイラをロードしていますが、他の言語をロードする事が可能になるかもしれない。
　コンパイラロード時には、標準ライブラリと拡張仕様SRFIに準拠したバイナリストリームを、評価器内で使用するためにレジスタにセットしているようです。この部分で興味を引いたのがgetDirectThreadedCodeメソッド。
　getDirectThreadedCodeメソッドをざっくり読んだところ、どうやらコンパイル済みコードもしくは、コンパイル前のコードを一気に読みこんでいるようです。名前からして、他のスレッドから読んでいるのかもしれませんが、今のところはそこはまだ調べていません。このメソッドの重要な処理はrunLoopメソッドが行っています。ダイレクトスレッドが定義されていない場合も、指定されたオブジェクトをそのまま返して、runLoopメソッドが実行されています。
　runLoopメソッドは見所です。Schemeの中心部と言えるかもしれません。皆が大好きな？carが実行されていたりします。エラーが出た時は、callAssertionViolationAfterメソッドが処理をしています。この部分から分かったのですが、内部処理は○○Proceduresで定義されているようです。分かりやすくていい。こういう細かい部分で、ひげぽんさんが丁寧にプログラミングをしている事が分かります。
　ただ、一つ気になった事があります。それは、コメントアウトされたコードがある事です。Moshのソースコードは、確かGITで管理している筈です。ですから、コメントアウトして置いておく必要はないと思います。でも、ひげぽんさんがしているのだから、何か深い事情があるのかもしれない。もしかしたら、ソースコードをコミットしてた後要らないコードを削除するとか？いや、もしかしたらデバッグ中のコードかもしれない・・・色々想像してしまいます。今度聞いてみよう。
　では、またソースコードの海へ帰ります♪

Mosh学習日記1

　今日は残念ながら、仕事が忙しくて殆どMoshに触れませんでした。CMakeが難しい・・・何故か上手くいかない。仕方がないので、Windows上のビルドをひとまず置いといて、Moshのソースコードを読みました。いざとなったらDebianでビルドすればいいや。それに、ソースコードが読めれば、問題ナッシング。
　Moshコンパイラ（正確に言うとインタプリタ）なので字句解析をする為に、どこでスキャナが動作している筈。そこで、本日はスキャナを探す事にしました。スキャナと言えばTextであり、Moshはポートでやり取りをしているので、スキャナが使われている場所が直ぐに検討が付きました。調べてみると、やはりTextualInputPortクラスのコンストラクタで初期化されていました。
　スキャナは、ストリームとして設計されており、fill・emptyBuffer・scan・currentTokenの計4つのメソッドが定義されていました。なるほど、ポートでやり取りをするのであれば、ストリームで扱うのが王道。美しい連携プレイです。
　ここで、時間切れになりました。朝Moshは時間が短い。かといって、最近仕事が忙しくて、夜はもうくたくたです。う～ん、悩ましい。もっとMoshをハックしたいな。

Mosh学習日記

　以前から興味があったので、今日からMoshのソースコードを読みます。コンパイラに興味がある人や、Moshに興味がある人の参考になれば幸いです。誤解がないように、初めに断っておきますが、この日記はあくまでも私の感想を書いたものなので、正確なものではありません。
　MoshとはScheme言語の処理系の一つで、作者はひげぽんさんです。R6RS準拠で、FFIやソケットなどを拡張しているのが特徴です。公式ホームページはhttp://code.google.com/p/mosh-scheme/です。興味がある人はチェックして下さい。前置きはこれぐらいにして、日記を始めます。
　本日は、朝マックならぬ朝Moshをしました。ダウンロードして直ぐに展開し、迷わずソースコードをチェックしました。普通はドキュメントを読むべきなのでしょうが、ときめきを抑えきれずソースへ直行です！
　色々読みたいところがあるのですが、初めてなのでヘッダファイルとmainを眺める事にしました。ヘッダファイルは、綺麗に整理されており、中々読みやすそうです。Arithmetic.hとArithmeticProcedures.hのように綺麗に分割されており、後で調べたい時に便利だと感じました。他にも、Unicodeのサポートの充実ぶりや、InputとOutput関係のヘッダが多い事などが目を引きました。後でじっくり調べよう。
　ヘッダファイルをざっと読んだ後は、お決まりコースのmainメソッドを読んでみました。コンパイラは複雑なので、正直言って「いきなり読んで大丈夫か？」と不安だったのですが、Moshは綺麗に整頓されていました。色々せずに、指定されたコンパイラオプションのチェックおよび、仮想マシンのセットアップ処理をしていました。
　main.cppをざっくり見て分かったのですが、どうやらMoshの仮想マシンはポートでやり取りをする様です。UNIX思想を感じます。この考えは、Moshを強力な梃子にするでしょう。ただし、標準ポートを共有するとバッファの問題が起きるので、標準ポートは共有していないそうです。
　mainメソッドをざっくりと読んだ後は、なんとなくWindows上でビルドをしてみる事にしました。MoshはCMakeでビルドをします。マルチプラットフォームは大変ですね。リリースマネージメントをしておられるmjtさんの大変さが伺えます。CMakeはまだ使った事がないので、色々なホームページを見ながらやってみました。えいや！うごけー！うぉぉ～・・・！？・・・おや？失敗したぞ。
　エラーメッセージを読んで分かったのですが、Moshは鬼車とGMPを使用しているようです。おお！想像通りMoshは本格的だ。やはり、初めからドキュメント読むべきでした。鬼車をコンパイルして、GMPを・・・う～ん、難しい。GMPをソースからコンパイルするのが難しいです。仕方がないので色々調べたところ、WindowsではMPIRがよいそうです。。。。あれ？MPIRもビルドするのが難しいぞ。どうなっているんだ？
　ここで、9時前になったので朝Mosh終了しました。MPIRをWindowsへインストールするいい方法はないものか。今夜調べよう。