Commits

camlspotter committed 163b723

update

Comments (0)

Files changed (1)

 もし知らないツール名があったらちょっと読んでみて欲しい。
 もしかしたらあなたの問題を解決するツールがあるかもしれないから。
 ライブラリとツールの中間のようなコード生成系も取り上げた。
-基本的に触ったことのある物しか紹介しない。
+あくまでも基本的に私が触ったことのある物しか紹介しないから、
+そっけなかったりするのはあまり触ってないということです。
 なんでこれはなんで取り上げてないの?と思ったら、それは使ったことないからです。ごめんね。
+不満があったら自分で紹介記事書いてください夜露死苦!
 
 ★は重要度。五点満点。
 
 * ちゃんとスケールする (Jane Street の 100万行程度の多岐のディレクトリにわたる OCaml プロジェクトでも動く)
 * マニュアルに日本語の訳がある (英語: http://omake.metaprl.org/manual/omake.html 日本語: http://omake-japanese.sourceforge.jp/ )
 
-私は OCaml のプログラムは今のところ OMake を使っている。問題がないわけではない:
+私は OCaml のプログラムは今のところ OMake を使っている。スケール感半端無いので。問題がないわけではない:
 
 * スコープルールが特殊。ビルドのために便利なようになっているらしいが、わかったようなわからないような、である
 * 依存関係を完全に抑える努力をしないと無駄なリビルドが発生する
 * お仕着せの OCaml ビルドルールで満足できなくなると関数を沢山書き始めて辛い
 * ld as needed と相性が悪く ``-P`` のビルドが上手くいかない人が ( http://d.hatena.ne.jp/camlspotter/20121002/1349162772 )
 
-とはいえ小さい OCaml プロジェクトの OMakefile はあっけないほど簡単に書けるので使ってみると良い。(まあこれは OCamlBuild にも言えることだが)
+とはいえ小さい OCaml プロジェクトの OMakefile はあっけないほど簡単に書けるので使ってみると良い。(まあこれは OCamlBuild にも言えることなんだけどね)
 
 OCamlMakefile ★★
 ------------------------------
 ライブラリパッケージマネージャおよびビルド補助ツール
 
 非常に重要なツール。
+OCamlFind はある種のパッケージシステムでもあるわけだけど
+パッケージ配布には焦点を置いていないのでビルドシステムに分類した。
 
 OCaml コンパイラはモジュールをまとめてライブラリにするリンカ機能は当然あるが、
 その出来たライブラリをどのように管理すべきか、統一的な方法はコンパイラ開発チームは
 sexplib と tiny_json_conv がこれらを必要としていることがそれぞれの META ファイルに
 書かれているので、 type_conv と meta_conv のフラッグが自動的に加わっている。
 
-そんなわけで OCamlFind は OCaml のライブラリを駆使するものはまず使う必須ツール。
+OCamlFind は OCaml のライブラリを駆使するものはまず使う必須ツールなので、
+ちょっとややこしいことをする場合は使ったほうがいい。
+ちなみに OCamlFind は Findlib というライブラリの上に作られたツールなので自分自身の OCamlFind パッケージ名は findlib。なのに OPAM パッケージ名は ocamlfind というちょっと変な名付けになってる。
 
 OCamlFind, 便利なんだけど、さらに camlp4 のラッピングをしてコード展開を楽にしてくれるととても嬉しいのだが、そんな機能はないのだなあ。
 
-ちなみに OCamlFind は Findlib というライブラリの上に作られたツールなので自分自身の OCamlFind パッケージ名は findlib。なのに OPAM パッケージ名は ocamlfind というちょっと変な名付けになってる。
-
-OCamlFind はある種のパッケージシステムでもあるわけだけど
-パッケージ配布には焦点を置いていないのでビルドシステムに分類した。
-
 パッケージシステム
 ========================
 
 
 Oasis では ``_oasis`` という設定ファイルに色々書くと自動的に ``oasis setup`` で setup.ml を
 作成してくれるのだが、その際、``_oasis`` から OCamlBuild のビルドファイルを自動的に作ってくれたり
-OCamlFind の META フィアルを作ってくれたりするようだ、が、よくわからない
+OCamlFind の META フィアルを作ってくれたりするようだ。
 Readme や INSTALL.txt を勝手に作ってくれたり、
 ソフトウェアライセンスとかも記述でき、コピーライトファイルを自動的に取ってきたり、
 いろいろ機能はあるみたいなんだけど…私には、ちょっとやりたいことが多すぎて手が回ってない感じのツールだな。
 
-私は OMake ユーザーであり、 OMake は Oasis で全くサポートされていないので恩恵は殆ど無い。
+私は OMake ユーザーであり、 OMake は Oasis で全くサポートされていないのでビルドファイル生成とかの
+恩恵は全く無い。
 まあ _oasis ファイルを書いて oasis setup すると OMake を呼んでくれる setup.ml を
-作成することはできる…でもそれだけであまり嬉しくはない。参考までに OMake で使うばあいの ``_oasis``:: 
+作成することはできる…でもそれだけ。参考までに OMake で使うばあいの ``_oasis``:: 
 
     OASISFormat: 0.2
     Name:        spotlib
 OMake はサポートされていないので ``XCustomなんちゃら`` を使う。まあこれで setup.ml から omake が呼べるようになる。
 ( http://d.hatena.ne.jp/camlspotter/20110603/1307080062 )
 Custom なのでビルドの自動設定はできないが… ``_oasis`` の Library エントリとか妙によくわからないので
-書けないなら書けないで…
+書けないなら書けないで…まあ構わないのだ。
 
 Oasis パッケージを管理する Oasis DB というモノも作られかけていたが…コケた。
 アップロードがあまりに不親切かつ面倒だったからだ。今はもう OPAM repo だね。
 この際のアルゴリズムとして Debian のパッケージと同じアルゴリズムが使われている、まあ枯れていて強力
 ということなのだろう。
 
+例として私が書いている opam ファイルはいつもこんな感じ::
+
+    opam-version: "1"
+    maintainer: "hoge.hoge@gmail.com"
+    build: [
+      ["ocaml" "setup.ml" "-configure" "--prefix" "%{prefix}%"]
+      ["ocaml" "setup.ml" "-build"]
+      ["ocaml" "setup.ml" "-install"]
+    ]
+    remove: [
+      ["ocaml" "setup.ml" "-uninstall"]
+    ]
+    depends: [ "ocamlfind" "spotlib" {>="2.1.0"} "omake" "orakuda"]
+    ocaml-version: [>= "4.00.0"]
+
+Oasis でビルド方法を統一してあるので、 ``build`` と ``remove`` ルールはいつも同じ。
+依存情報である ``depends`` と ``ocaml-version`` を書き換えるくらいしかしない。
+
 この ``opam`` ファイルに加え、ソフトウェアの説明を記述した ``descr``、ソフトウェアの tarball
 をどこに置いたか、そしてそのチェックサムを記録した ``url`` この三点セットのファイルで一つのパッケージ
 情報になる。これを opam-repository のレポに置けば誰もがそこから三点セットをダウンロードして
 (もちろん OPAM もソースを使ったソフトの配布システムなので環境が違うとインストールできないという事は
 普通にある…万能なソースベースのパッケージシステムなんかないのだ)
 
+そんなこんなで OCamlFind, Oasis, OPAM の住み分けは(少なくとも私には)こんな感じになってる::
+
+* OCamlFind を OMake で使う。最後は ocamlfind install で META ファイル含めてインストール
+* Oasis で OMakefile を呼び出す setup.ml を作る
+* ソースと setup.ml をレポに上げてバージョンのブランチなりタグを作る
+* ブランチもしくはタグに対応する tarball を url に書いて opam, descr と一緒に OPAM レポに pull request
+ 
 GODI ★?
 --------------------
 
 
 OCaml は C や他言語との橋渡しに C を使う。C関数を OCaml の関数として使うことができるのだが、
 そのままでは普通は使用できない。C関数を OCamlの GC やメモリモデルに沿った形で呼び出す
-ラッパ関数から間接的に呼び出す必要がある。このラッパ関数はスタブとよく呼ばれる。
+ラッパ関数(スタブ)から間接的に呼び出す必要がある。
 そのスタブの型安全性は全く保証されていない。正しい記述方法は
 http://caml.inria.fr/pub/docs/manual-ocaml-4.00/manual033.html
 に記載されているとおりだが、ちょっと間違うとすぐにプログラムがクラッシュする。
 それも GC に関連する問題だと大変だ、間違った関数を呼んでもそこではクラッシュしない…
-しばらくたって GC が走るとクラッシュする。スタブのデバッグは大変だ。
+しばらくたって GC が走ると…ボン!だ。スタブのデバッグは大変だ。
 
 CamlIDL は MIDL という C のヘッダにアノテーションを記述することで
 C関数を OCaml から呼び出すためのスタブを自動生成するツール。
-一応 OCaml のモジュールを COM コンポネントにする機能も付いているが、まあこっちは知らない。
+一応 OCaml のモジュールを COM コンポネントにする機能も付いているが、こっちは知らない。
 
 アノテーションが正確である限り CamlIDL は正しいスタブを作ってくれる。
 むろん、アノテーションを間違うとどうしようもないが、それでも手でスタブを書くよりは
 上の例でもわかるようにコンストラクタ名や型引数の違いはあるが、``show_t`` も
 ``show_t'`` も基本的にやってることは同じ。完全にルーチンワークだ。
 こういったルーチンワーク(Boiler plate code)は書きたくない、できればコンパイラに
-自動生成させたいというのが人の常で、type_conv はこういった型定義からの自動コード生成
-を支援するための CamlP4 フレームワーク。type_conv では type 宣言が拡張されていて
+自動生成させたいというのが人の常で、type_conv はこういった型構造で自然と決まるコード
+の自動生成を支援するための CamlP4 フレームワーク。type_conv では type 宣言が拡張されていて
 ``with <名前>`` というのをくっつけることができる::
 
     type t = Foo | Bar of int with show
 こちらは ``with hoge`` の代わりに ``deriving hoge`` と書く。js_of_ocaml
 で使われている。 Type_conv と OCaml_deriving が共存できるかどうかは、知らない。
 
-OCaml-deriving は show があるのが嬉しいかな。まあ type_conv でも meta_conv
+OCaml-deriving は show がすでにあるのが嬉しいかな。まあ type_conv でも meta_conv
 使って ``with conv(ocaml)`` すれば同じ事出来ますけどね。
 
 Atdgen ★
 どちらがいいのかは、正直よくわからない。特に私は toplevel でコード片を eval したりしない人なので…
 Jane Street が Tuareg を使っていて、特に Monad の bind 関係でインデントを整備していたので
 そのあたり、もしかしたら Tuareg のほうが使い勝手が良いこともあるかもしれない。
-(OCaml-indent を作った私としては両方共まーなんかなーなんですけどね)
+OCaml-mode も Tuareg もインデントは完璧ではないので気に入らなければ、提案されるインデントは
+無視して手で調整する。 C とか Java みたいな硬いインデントポリシーはないのでそこら辺は臨機応変にしよう。
 
 繰り返しになるけれども、 Tuareg を使っていても caml-types.el や camldebug.el は普通に使えます。
 
 エディタ力を強化してやる必要がある。まあこれは Unix 的発想で良いと思うんだけど、
 この頃の若者はそういう寛容さがないから無理を強いられていると感じるのしら。
 
-utop は ocaml toplevel を強化したもの。補完とかカラーつけたりカッコ対応表示したり
-できるそうです…が…何気に必要ライブラリすごくないかい?
+utop は ocaml toplevel を強化したもの。ラインエディット、補完とかカラーつけたりカッコ対応表示したり
+できる…使ってみると実際カラフルで全然 Caml っぽくないw が…何気に必要ライブラリすごくないかい?
 
-私は REPL 使わない派なので使いません
+私は REPL 使わない派なので使ったことなかったんだけど、補完はなかなか良さそうだ
  
 コンパイラテクノロジ寄りの開発強化ツール
 ============================================
 実はリファクタリングは OCamlSpotter にもあるし、インデントは OCaml-indent のほうが先だし、
 ちょっとパクられてるなーという被害妄想が私にはある。こういう時 OCaml専業+フレンチコネクションは強い。
 
-問題はプロセスをガンガン作るので Cygwin と相性が悪いってことか。
-Mac OS X ともなにか問題があるようで、 TypeRex が動かなかったら OCamlSpotter も試してみてくれい。
+問題は設計がこりすぎていて、Mac OS X となにか問題があるようで、動かなかったりする。
+TypeRex が動かなかったら OCamlSpotter も試してみてくれい。
 
 Spotter も TypeRex も使ってない caml-types.el も使ってないとかいう人は
 演習が終わったら OCaml もう使わないほうがいいと思う。 F# とか IDE あるでしょ?
 ただし、 Stdlib と Extlib しか検索できない。
 
 今や OPAM があるので OPAM パッケージを全て対応とかしたら嬉しいんじゃないだろうか。
-そこまで OCamlBrowser/OCaml API Search の検索アルゴリズムがスケールするのか、どうか
-興味もある。
+そこまで OCamlBrowser/OCaml API Search の検索アルゴリズムがスケールするのか、どうか興味もある。
 
 cmigrep ★
 ---------------------
 ---------------------
 
 これはぜーーんぜん使ったこと無いのですが、 PIC で OCaml を動かすという
-アホな楽しい OCaPIC project の産物。Dead code elimination を行なって
+OCaPIC project の産物。Dead code elimination を行なって
 バイトコードプログラムの挙動は同じままにサイズを減らしてくれる。
 (OCaml バイトコードコンパイラは使ってないコードもそのままリンクする。
 バイトコードはバイトコードで最適化はほとんど行わないというポリシーなので。)
 強化ライブラリ
 ==============================
 
-この紹介は開発ツールということで、ライブラリの紹介はしないつもりなのだが、
-強化基本ライブラリに関しては例外として紹介する。
+この紹介は開発ツールということで、ライブラリは飛ばすつもりなのだが、
+強化基本ライブラリに関しては例外。
 
 OCaml の標準ライブラリはとても貧弱。
 長らく、各人がそれぞれ自分で育てた強化ライブラリを使って仕事をしてきたが、
 OCaml Batteries Included ★★★★
 -----------------------------------
 
-OCaml Batteries Included は Python の Batteries Included から名前をインスパイヤ
-した強化基本ライブラリ。
+OCaml Batteries Included は Python の Batteries Included から名前を
+インスパイヤされた強化基本ライブラリ。
 
 私は使ったことがない。理由は Jane Street Core に慣れているから。
 なので違いとかもよくわかりません。
 OUnit
 -------------
 
+ユニットテストライブラリ
+
+テストは簡単には assert でやるもんですが、それが沢山になってくると、どのテストが通ったかとかどれが通ってないとか
+調べたくなるものです。OUnit はベタな assert を organized な物にするためのライブラリ。
+
+テストの元になってる最小単位は ``test_fun``、要は ``unit -> unit`` でエラーの場合は ``Failure`` 例外を上げる
+関数。これを ``(>::)`` で名前をつけて ``test`` にしてやる。複数の ``test`` を ``(>:::)``
+でまとめて一つの大きな ``test`` にしたり、などなど、テストという概念の簡単なコンビネータがある。
+最終的に全てのテストを一つの ``test`` にまとめ上げたら ``perform_test`` 関数で走らせる。
+
+OUnit は単にテストをまとめ上げるためだけだから、 QuickCheck 的なランダムテスト自動生成とかは、ない。
+
+テストが大量にあってカバレージが気になる人は使うといい。テストが少量とか、100% 通らないと困る、
+という人はあえて使わなくてもいいんじゃないか。
+
 OCaml-QuickCheck ★?
 --------------------
 
 書いてみただけ。試したこと無い…
 
+基本的に Haskell の QuickCheck を持ってきただけなので type class の辞書飛ばしを
+マニュアルでやらないといけない。面倒そうだ。
 https://github.com/camlunity/ocaml-quickcheck
 このフォークが 3.12.x の first class module を使っていて
-少し使いやすいそうだが、自動値生成として type_conv なり deriving 使ってないと
+その辞書飛ばしの部分は少し使いやすいそうだ。
+しかし、自動値生成として type_conv なり deriving 使ってないと
 大変だと思いますが。多分そういうの無いよねこれは…
 
-OCamlViz
---------------
-
 ドキュメントw
 ======================
 
 -----------------------
 http://www.ocamlpro.com/blog/2011/06/03/cheatsheets.html
 
-OCaml 文法からコンパイラのスイッチ、 Tuareg まで、
+OCaml 関連のカンニングペーパー。文法からコンパイラのスイッチ、 Tuareg まで、
 まあ簡単にまとまっていること! 
 
 Tuareg ってこんなに機能あるんですかー、多分1/10も使ってないわ私…