F# ビルドの続きです。
■fsharp のビルドでこける
正確には F# proto(F# 3.1 をビルドするための F# 3.0)のテストでこけます。
ガベージコレクションのテスト(かな?)をしているところで、alloc 出来なくてこけているので おそらく RasPi のメモリ不足ですね。手元の Raspberry Pi って初期型なので、メモリが少なくって USB が 2 つついているけど 256MB しかないんですよね。
おそらく、ここの GC チェックを外してしまえばビルドできると思うのですが、どうも手軽ではない。そもそも Mono 3.2.7 のメモリでこける件もテスト自体でこけているので実害はないかもしれない。
■Debian でビルドした F# をインストールする
で、そもそもが「 FSharp.Core は環境依存していないだろう」という想定のもとに、別の Debian でビルドした FSharp.Core 等を Raspberry Pi のほうにインストールしてしまいます。これでいいのかっどうか不明なのですが(Debian 構築のほうは Hyper-V 上で x64)、同じ Linux 上だしなんとかなるかもしれません。
Debian でビルドした fsharp を tar で固めて、Raspberry Pi へコピー。その後、フォルダ名を合わせてから sudo make install します。ビルド環境のパスをあわせるのは、makefile 等にビルド環境が書き込まれているからです。
無事インストールして fsharpi します。
fsharpi を動かすと30秒ぐらい待たされますが、一応動きます。元ネタは 大事なことは全部MLが教えてくれた ~ Apple の Swift の mutability 周りの件を理解する – Oh, you `re no (fun _ → more) です。どうやら mono の読み込みの時にかなりパワーを使っているらしく、新しい文法を使うたびに動作が重いです。一度、読み込むと動きがスムースになるのでキャッシュあたりですかね。
という訳で例の FsRandom で陽性かくにん! も動かしてみましょう。Windows の NuGet で持ってきた FsRandom.dll を Raspberry Pi にコピーして
fsharpc -r:FsRandom.dll stap.fs
すると、無事 stap.exe が出来上がります。これを実行すると…無事 198599 番目に(でよかったのかな?)陽性かくにんできます。
このプログラム自体は結構なスピードで動くので、初回の mono のロードだけ重たいみたいです。
ピンバック: F# Weekly #24-#25, 2014 | Sergey Tihon's Blog