リメイク版ロボコップ。案外悪くないし、けっこう現代的な映画になっていると思う

見てきました。トレイラーを見て、映像がかっこよさげなので、仮に駄作でもまぁこの映像が見られればいっか、ぐらいの気分だったんですが、なかなか悪くない作品だと思いました。こちらでの評判はけっこう悪いみたいなんですが。

ただ、極めて現代的なSF映画としてすべてが再構築されているので、旧作ファンやバーホーベンファンが見ると、これは違うな、ということで残念な気分になる点はあるかなと思います。

端的に言うと、旧作の良かったところというのは何一つ継承しておりません。そうした美点を期待すると、裏切られた、という気分になるかもしれません。「殉職した警官の体を使ったロボット警官」というコンセプトをもとに、いちから作りなおした映画だと理解するとよいのではないかなと。

以下ネタバレを多少ふくみつつ感想を書いておきますが――

---

ロボコップをリメイクするにあたって、製作陣はすべての大前提を考えることにしたようです。というのは「なんでまたロボコップみたいな異様なモノを作らざるを得なかったのか？」という問題ですね。なんでまた、ギャングに殺された警官を改造してまでロボコップのようなグロテスクな存在を作ることになったのか？

これはバーホーベンの旧作では答えられていない疑問です。とくに説明がないということにこの設定のグロテスクさがあるとも言える。でも現代のSF映画としてリメイクするときに、それを語らないというのは映画としての強度を失ってしまう。少なくともリメイクの製作陣はそう考えたのではないか。

したがって本作のロボコップにはいろいろ重要な設定変更がなされています。ED209はすでに実用化され、米軍によって世界各地で運用されているわけです。ティンマンという人型のロボットも使われています。この技術を転用して、オムニ社は広大なマーケットでありながら進出できていない地域を目指したい。それは米国本土である、というのが本作の設定です。もちろん目的は軍ではなくて、警察の機械化を推進するということです。

ところが本作のアメリカは、海外の紛争地域ではロボットを運用しているものの、国内の警察力を機械化することについては強い感情的な反発があるとされています。反対論者のドレイファス上院議員によって警察の機械化を禁止する法案が提出されようとしていて、賛成派と反対派でやりあっているという設定です。機械はなにも感じることはない、被害者に共感することもない、それが問題だ、というのが反対派の論調です。

こうした状況を踏まえ、警察を機械化しつつ、人間らしさを残すという奇策というべきデモンストレーションプランが考案されます。それが、「重症を負った人間をサイボーグ化することで機械化警察の利点と人間らしさのハイブリッドを実現する」というプランであった……という設定です。

ですから、本作ではマーフィーは公式にも殉職していませんし、彼は機械によって強化されているけれども人間だということになっています。残された家族との関わりも大きな物語上のポイントとなります。オムニ社の人たちも、旧作みたいに権力争いに終始するろくでもない連中ばっかりというわけでもない。もちろんただの善人というわけではないけれども、自分たちの信じることのために最大限の努力をしている人たちだとは言えるかも。

その設定変更はどうなのか？　という向きもあるでしょう。旧作らしさもない。でも、この「殉職した警官の体を使ったサイボーグ警官」というコンセプトとイメージから、いまこの時代に全く新しく再構築した映画としては、悪くない着地点なんじゃないでしょうか。そしてこの基本コンセプトとなるアメリカの設定は、極めて現代的であるなあ、と感心します。「なるほど、そういう映画にしたのね」と思った次第。

ちなみに映像もきちんとカッコイイので、その点も安心できます。

シリコンバレー史跡めぐり

唐突に思い立って行ってみました。

1. ヒューレット・パッカード創業の地

ウィリアム・ヒューレットとデビッド・パッカードのふたりがヒューレット・パッカードを創業したのが1935年。パロアルトにあったパッカードの家のガレージでの創業でした。現在はnational register of historic placesとして登録されている史跡ということになるようです。

所在地はパロアルトのダウンタウンであるUniversity Avenueから数ブロック先。ダウンタウンらしさがなくなり、閑静な住宅街だなーと思って歩いていると見つかるといった具合です。

1枚目の写真の奥にある小屋が創業時のガレージなのだそうですが。

なお、1枚目の写真の茂みの奥に小さなプレートがあると思いますが、そこにも「私有地です」といった但し書きがあります。今なお、この家には誰かが住んでいるわけで、その前を勝手に史跡としてプレートが立っちゃってる状態なわけですね。いい迷惑かもしれない……。

さて、堂々と「シリコンバレー誕生の地」と書かれておりますし、確かにシリコンバレーの形成にHPが重要な役割を果たしたことは間違いではないでしょうが、この時点でのHPというのは計測器を作ってる会社だったわけですね。電気製品ではあるものの、シリコンや半導体とは無関係でした。

シリコンバレーという名称が出てくるまでには、ほかの2つの会社が大きく関わってきます。

2. ショックレー半導体研究所跡地

そもそもトランジスタの発明自体が1940年台のこと。ベル研究所で発明されたとのことでした。この発明に大きく関わったウィリアム・ショックレーは、1956年に世界で最初の半導体機器の会社であるショックレー半導体研究所を立ち上げ、所長となります。写真は、その跡地。研究所自体は現存しません。

場所はこの辺（注：ストリートビューへのリンク）。この辺に住んでいる人たち向けに書くと、マウンテンビューのサンアントニオショッピングセンターの北のはずれのほう。今となってはちょっとうらぶれたあたりですね……。奥の看板はハラールを売っているスーパー。ストビューだと営業中ですが、行ってみたらつぶれていました。

さて、ショックレーの研究所じたいは現存もしないし、今となっては「世界で初の半導体の会社」というぐらいでしかないかもしれません。せっかくの看板もなんかショボイし。でも、歴史的には大きな意味がありました。

ショックレーさんはノーベル物理学賞も受賞した偉大な研究者だったのですが、人間的にはいろいろめんどうくさい人だったようです。そういうこともあってか、8人の若手の研究員が裏切って相次いで辞めてしまうという事件を引き起こします。そして……。

3. フェアチャイルドセミコンダクター創業の地

辞めた8人の中には、ムーアの法則で知られるゴードン・ムーアなどもいました。彼ら8人はフェアチャイルド・カメラ・アンド・インストルメントという会社の出資を受け、フェアチャイルドセミコンダクターを創業します。

のちに親会社と折り合いが悪くなり、8人のうちゴードン・ムーアとロバート・ノイスはフェアチャイルドセミコンダクターを退職し、新しい会社を創業します。それがインテルです。こうした流れのなかに「シリコンバレー」という名前があるのでした。

フェアチャイルドセミコンダクターの創業の地は、ここ。ストリートビューでもプレートの存在は確認できますね。建物自体は今では別の会社のオフィスになっているようです。

なんとなくまとめ

この後、せっかくなのでアップル創業のガレージ（アシュトン・カッチャーの映画でも使われていたアレ）も見物に行ってみたんですが、あまりにも普通の住宅街だったので気が引けるなあと思っていたら「監視カメラ使ってるから変なことするな」みたいな看板まで立っていたので、通り過ぎるだけにしました。ストリートビューでは看板立ってないけど、やっぱり映画で話題になったし、ここを史跡にするという運動もあったりするので、いっぱい人が来たんでしょうね（人のことは言えないが）。住民にとってはいい迷惑なのかも。

それにしても、シリコンバレーなんて、たかが半世紀かそこらの歴史なんですよね。無理やり広く考えてHPの創業から考えても100年もない。それより前は、この辺りには農家しかいなくて、一面の農園とか果樹園であった（らしい）んですよね。さらに言えば、そもそも西洋人の入植じたい、この辺ではサンフランシスコがゴールドラッシュで盛り上がった1849年以前は相当細々としていたわけです。

なんとなく、そういう歴史に思いを馳せる週末でした。

『絶園のテンペスト』。世界の存亡をかけたフーダニット

絶園のテンペスト

唐突ながらふと『絶園のテンペスト』を全巻イッキよみしました。といっても10冊ですが。世事にすっかり疎くなってしまいましたがアニメ化もされてたのね。まーけっこう面白かった。

いわゆる「能力バトルもの」の一種で、登場人物たちの一部は「はじまりの樹」とよばれる超常パワーをもった世界樹のようなものから力を授かる魔法使いの一族。彼らは伝承に背き、ひとり反対する姫君を離島に封じ込め、かつて「はじまりの樹」によって封じられたという「絶園の樹」の復活を目論みます。普通の人間である少年ふたりがふとしたきっかけから、このお姫様とつながり、「はじまりの樹」と「絶園の樹」をめぐる戦いに巻き込まれる、といった筋立て。

こういう基本的な設定そのものは言ってしまえばありきたりですが（それでも能力バトルものとしては魔法使いの設定などはけっこうユニークではあります）、ぼく個人としては、ストーリーが不思議にロジカルな組み立てになっているところに面白さを感じました。登場人物たちは自らの行動原理や行動規範を明らかにしつつ行動しているのですが、それらがパズルのように組み合わさって物語が進んでいく面白さがあります（そういう意味ではきわめていびつな、というか、きわめて人造的な感覚の強い物語です。amazonのレビューでも不評がそれなりにあるのはこの辺が理由かなと）。

さらにこの「パズル」を成り立たせるキモとなるのが、この作品のキーでもある「はじまりの樹」の設定で、こいつは世界の成り立ちにかかわる世界樹のようなものであり、物事の因果すら操ることができることになっています。このため、とくに物語の後半においては、ごく普通の少年である主人公ふたりがこうした物語に関わり重要な役割を（結果的にだが）負うことになるからには、そうなるだけの理由があるはずだ（でなければそこには、「はじまりの樹」の力が及びづらい「絶園の樹」の力が関わっているはずだ）、という論理が成り立つことになります。

主人公ふたり滝川吉野とその友人の不破真広が物語にかかわる根本的な原因は、「真広の妹が何者かによって殺された」という理不尽でした。したがって、その死はただの強盗などではなく、何らかの理由があってもたらされたものでなければならない、ということになります。ではその死は誰によって、なぜもたらされたのか？　この謎が物語後半を駆動するエンジンとなっていきます。

まあとはいえミステリとしては弱くて、真相自体は読んでいればふつうは予想がつくんですが、世界の存亡をかけた戦いが、ひとりの少女の殺害の謎に収束していくあたりの展開はなかなか良い感じ。

物語自体は9巻で終わって、最終巻はいろんなキャラの外伝的なストーリーになっているので（それにしても最近こういうの多いですね）、一般的には能力バトル＋キャラクターの関係性を楽しむものとして読まれており、こういう読み方は邪道かもしれません、けどね。

Sherlockシーズン3

日本でもすでにシーズン1と2は放映されているので皆様ご存知だと思いますが、シャーロック・ホームズの物語を現代風にアレンジしたBBCの人気ドラマ Sherlock のシーズン3です。まず英国で放映されていたんですが、米国にもやってきたので見ました。Google Play MovieやAmazonで出てます。

いやぁ相変わらず素晴らしい。英語は相変わらず聞き取れないけど。

シーズン3は「空き家の冒険」をもじった第1話 "The Empty Hearse"、『4つの署名』からの第2話 "The sign of three"、タイトルは「最後の挨拶」で中身は「犯人は二人」の "His last vow" の3話構成。

あんまりネタバレせずに紹介するのは難しいけど、頑張ってみると……

第1話は、シーズン2の結末から2年が経過し、ついにシャーロックが帰ってきて再開するというストーリー。ちょっと残念なのは（ネタバレだけど）シーズン2の結末の「シャーロックの死」がどう演出されたのか、本当のところはわからずに秘密のままにしちゃったこと。そりゃーないよー。あのシーン、何度も見返してあれかこれかっていろいろ考えたのになー。

第2話は、ワトスンがついに結婚することになり、シャーロックはワトスンの best man （新郎介添人）として挨拶をする、というエピソード。その挨拶のなかで、シャーロック自身の直近の調査が語るが……というエピソード。ラストでわかるオチの意味がすばらしかった。

第3話は、チャールズ・オーガスタス・マグナスンなる怪人物とシャーロックが丁々発止の対決をすることになるというあらすじなんですが、うーん、これはなんというか、想像を超えた展開で驚きました。でもネタバレせずにあらすじを紹介するのは難しいなあ……。

今回の3話は、わりとひとつながりのストーリーになっていて、けっこう緊密に3話がつながっています。2話があってこその3話のこの展開になるし、もちろん1話を抜きにはできない。

それと少し雰囲気が変わったな、と思うところはあります。物語の主軸が、事件調査よりはシャーロックとワトスンやその周囲の人物の関係性を主に描くようになったかな、比重が変わったな、という気がします。

これ自体は悪い変化とも言えなくて、たとえば1話でシャーロックとワトスンが久々の再開をするシーンはどうしたって笑ってしまいますし、2話でワトスンがシャーロックに自分の結婚式の best man をやってくれるよう頼むシーンは、ちょっとぐっときます。ほんとうに良いシーンなんですよこれが。

もちろん、シャーロックの推理のシーンなど、微速度撮影やCGを駆使した無駄にカッコイイ映像表現は健在ですが。

今回だと個人的には第2話がお気に入りかなぁ。ワトスンの bachelor party で酒を飲みまくって泥酔したシャーロックが調査に乗り出すんだけれどもまったく役立たずになってるところはセルフパロディっぽくて笑いっぱなしでした。ほかにも、結婚式の式辞からカットバック的に事件の回想が入っていき、最後に物語の解決までいきつくという凝った構成も光るし、最後の最後にタイトルの意味がわかるところもいい。

日本はさっそく5月には放映されるようですね。お楽しみに。

---

ちなみに一言だけ言っておくと。

このオチはねえよ！　ぜんぜん終わってねえじゃん！

こちらからは以上です。

Chromecastでお手軽wifiスピーカー

Chromecastというデバイスがあります。今日はそれを使ってちょっと遊んでみた、というもの。

Chromecastとは何か……というのはご存知の皆さんが多いのでかなりはしょりますが、下の写真のようなガジェットです。テレビに直接挿して使い、コンピュータや携帯電話のアプリから動画や音楽を流して試聴できる。

chromecast

対応サービスやアプリがまだ米国主体というのもあり、日本では未発売ではありますが、$35という低価格もあってこちらではそれなりに受けの良いガジェットのようです。ただ、動画とかをテレビで観るのはそれはそれで良いのですが、音楽だけなら画面いらんよなーとは誰しも思うところです。

というわけで今回はこのChromecastと Panlong HDMI Audio Extractor Decoder/Converter というコンバータを組み合わせます。こちらは HDMI を入力とし、画面出力は無視してオーディオ出力だけを出す、という、まさに今回の目的にうってつけのものです。

オーディオコンバータ

Chromecastと合体させれば、これだけでもう任意のスピーカーをwifiスピーカーにしてしまうことができるわけです。もちろん画面は出せませんけど、YouTubeで音楽を聴いたりとか、あとまあ音楽をGoogle Musicに上げてさえおけば、ふつうに音楽を流すぐらいはまったく支障ありませんね。

合体！

と、いうわけで、これを電源につなぎ、オーディオ出力の先に適当なスピーカーをつなぐと、どんなスピーカーでもあっというまにワイヤレススピーカーに！というわけですね（結線後の写真は省略します。ケーブルがごちゃごちゃして汚いので（笑））。

まだセットアップしたばかりで、あまりにも普通に音楽が聴けてしまっている状況のため感想も特にないのですが、これはかなりお手軽感があります。コンバータも思ったより小ぶりだし、Chromecastも小さいし。

もちろん、ワイヤレススピーカーなんてありふれてるといえばそうなんですが、どんなスピーカーでもワイヤレススピーカーにできてしまうという面白さと、それからChromecastは複数台から同時接続するのが簡単なんですが、その簡単さなどは魅力かもしれません。これはちょっとなにかあるかもしれない。気のせいかもしれないけど。

なおこのテクニックは比較的有名なようで、↑のオーディオコンバータのレビューでも Chromecast で使うと便利というものがあるし、なにしろ Frequently Bought Together が Chromecast になっておりまして、かなりメジャーなテクニックなようです。

どうでもいいけどこの組み合わせでHDMIケーブルはいらないよなー

ちなみに、Chromecastのセットアップは、いちおう画面を見て操作することが前提になっています。一番はじめはChromecastが画面にセットアップガイドを出すし、最初にコンピュータと接続してセットアップするためには、画面に出てくるランダムな数文字を確認して、あっているかどうかを確かめる必要があります。ただまあ、たまたま近所で同時にセットアップしている人がいない限りは、みずてんでオーケーしてしまっても、まあたいていは大丈夫なんではないかなあと思うわけですがいかがでしょう。どうしても気になるなら、はじめのセットアップだけはテレビを使えば良いかなとも思いますが。

まだ日本に来てないChromecastの話なんでアレですが、これはちょっと面白いなと思った次第です。

天冥の標 7 新世界ハーブC

天冥の標7　新世界ハーブC

これは……「ギャルナフカの迷宮」？

前巻で「救世群」に追い立てられて主人公たちが逃げ込んだ先、その閉鎖世界のなかでどうにかあがいて生き延びていくという物語であり、ようやく1巻に続く設定が明かされることになるという7巻でした。閉鎖世界で生き延びるうちに国を作り上げていくというのは同作者の「ギャルナフカの迷宮」（『老ヴォールの惑星』所収）を思わせるところがあるなーとも思うんですが、いや、やっぱりそれなりに成熟した少数の大人で構成されていたギャルナフカとは違いますね。主に少年少女で構成される世界をスカウトたちがなんとか仕切ろうとして、けっきょくのところリソース不足からだんだんぐだぐだになっていくという流れは、なんというか、ため息しか出てこない。

それでいて物凄く嫌な話にはなっていないのがうまいところ。この手の話でわりと適当にごまかしがちな性愛の問題を、SF的な理屈をつけることでひとまず落ち着かせておいて物語を進めるところもうまいといえばうまい。

メニー・メニー・シープの正体については、それほど意外感はないというか、まあこんなところでしょうという印象が半分ぐらいなのだけれど、この巻で描かれる閉塞感と1巻の開放感のある感覚とはちょっとかけ離れすぎというか、やっぱりこう、ギャップが大きいようにも思える。小川一水本人自体の力量が7巻まで進むうちに上がってしまっているのも一因という気がするけれど。

しかしここから300年というのはちょっと盛りすぎたんじゃないですかね小川先生……。300年間も防衛できていたダダーがすごいよ。

設定的にも解決できない部分を残すことでヒキがあるのも気になる。次はようやく1巻以降の話ということになるんでしょうか。と思って1巻のラストを読み返したら、いやーこれは厳しいですねー……。この展開から続きってどうありうるんでしょうか。気になるところです。

冬休みなのでNaClで遊んでいた

せっかくの休みなので仕事と関係ないことでもすっか、と思い、NativeClientで遊んでいました（微妙に関係するのかなこれ）。Google+で #冬休みの自由研究 というハッシュタグを勝手に作って適当にあれこれ書いていたんだけど、そういえばなぜか限定公開にしてたので誰でも見える状態にはなってませんでしたね……。

なのでブログで簡単に記録を残しておきます。

やったこと：GaucheをNative Clientで動かそうと四苦八苦して挫折。その後 chibi-scheme を動かそうとしたらあっさり達成

いちおうはじめから書きましょう。

NativeClient（通称NaCl）とは何か？

NativeClientは、ブラウザ（Chrome）のなかでネイティブコードを動かすためのモノです。SDKはカスタムメイドなCコンパイラでして、少し特殊なかんじのバイナリを生成します（nexeという拡張子がついています）。Googleが作ってます。

作ったバイナリは、objectやembedなどの要素でページに埋め込み、別プロセスで実行されます（この時にバイナリを検証します。で、NaClのコンパイラで生成したバイナリにはちょっとした制約があるため、セキュリティ的に問題のあるようなコードが動かない、つまり、サンドボックスを突破して利用者側に不利益のかかるような悪意のあるプログラムを配布できないようになっています）。ページのJSからは postMessage / onMessage を使ってやりとりするというかたちになります。

よくasm.jsと比較されることがあるのですが、個人的には性格が異なるかなーと思ってます。NativeClientは（特殊な調整がされているとはいえ）普通のELFバイナリなので、けっこういろんなことができます。pthreadでスレッドもあれこれできたり、環境によるけどdlopenできたり。asm.jsは最終的にはJSの意味論に落ちるので、やるのが難しいことがあるんじゃないかなぁと思うんだけどどうなのかなあ。

GaucheをNaClで動かす

そういうわけでNativeClientではネイティブコードが動くわけですが、実際の用途として想定されているのは、パフォーマンスが大事なエリアだけCで書いて頑張る、といったことかなと思います（そういうサンプルがSDKに添付されてるので）。だけど、こう、折角だからスクリプト言語とか動かすと面白いよね、と思う人はいっぱいいるようで、Ruby、Python、LuaについてはnaclportsというNaCl用のパッケージ集みたいなところに入っています。

で、Lisp系の言語はなかったみたいだしGaucheどうかなと、思ったわけです。うっかり。

目算はありました。というのは、GaucheはガベージコレクションとしてBoehm-GCを使っているわけですが、Boehm-GCはnaclportsに入っているのですね。だからそれほど問題はないのかなと思ったわけですが……。

naclportsのBoehm-GCが全然動かねえ！

という次第でありました。NaClもいちおう普通のELFバイナリではあるとはいえ、それなりにおかしなところもあるので、そう簡単な話ではなかったというわけです。

NaClが動かない場合のデバッグは大変で、いちおうSDKにはgdbが付属しているんですが、年末帰省でChromebookしかない状況だったため、gdbつきでNaClバイナリを動かすことが出来ません。デベロッパーツールを見るとクラッシュしたことだけがわかる（スタックトレースも何もわからない）という状態。

ただ、後述する方法によってstderrに書きだしたものはIPCを経由してconsole.errorとして吐き出されるようにできるということはわかったのが救いで、これを使ってprintfデバッグという超原始的な手法に着手しました。とはいえfflushしてもフラッシュしてくれないので、クラッシュするタイミングとIPCの調子によっては実行してるのにログが吐かれないということもあったりするため、何度もクラッシュさせてみて「ここまで出ることはあるからここで落ちているんだろう」と推測して、とかしていました。

そういう謎の苦労のすえにわかったのは、GCの初期化時の問題だということでした。Boehm-GCはマーク＆スイープのルートオブジェクトの集合として、スタック上の変数とグローバル変数をとっているわけですが、どうやら Boehm-GC がグローバル変数の領域と思っているエリアがおかしい気がする。といったところに当たりをつけたぐらいで神のような方が教えを授けてくれたわけですが、まぁ要約するとこれは無理っぽいなと。

その辺は今後解決されることを期待しつつ #define GC_MALLOC malloc 的な手段で（メモリリークを気にせず）やろうかなとも思ったんですが、Gaucheはatomic_opsにも依存しているしGC_baseもあるし、ちょっとだけ手を入れる必要があるみたいだし、といったあたりで気力を失ってしまいました。

まあ、ふだんあまり触らないような低レイヤーの領域の知識がちょっとだけ増えたのでよかったかなと思います。

chibi-schemeをNaClで動かす

で、気分を変えてchibi-schemeを動かしてみることにしたわけです。chibi-schemeを選んだ理由は、scheme処理系のなかでは実装がコンパクトっぽい（と聞いたことがある）のと、自前のシンプルなgcを持っているので↑のようなしんどい目にはあわなくて済みそう、という理由です。

で、こっちは動きました。あまりにも簡単に動いたので逆に拍子抜けしたぐらいです。Gaucheは（というかGCは）なんだかんだで一週間弱ほど苦闘していたわけですが、chibi-schemeにはほとんど罠がありませんでした。

chibi-schemeはpnaclでも普通にビルドができたので、動作環境をふつうにウェブページとして公開しておきます→こちら

pnaclとNaClについて書いておくと、NaClは普通のネイティブコードバイナリを配布するものなのですが、いまだに利用環境に制限があり、通常のウェブページには埋め込めません。 Chromeアプリとして配布されたものでしか使えないのです。pnaclはportable NaClの略で、NaClと違ってネイティブコードでは配布されません。LLVMのビットコードを使ったpexeというファイルで配布され（よく知らないのであやふやな表現）、ブラウザのネイティブ環境に変換されて動きます。こちらはなぜか制限がなく、普通のブラウザでも――ってもちろんNaClに対応しているブラウザなのでChrome限定ですが――見ることができるようになっています。

ppapi_simpleとnacl_ioについて

さて、NaClで苦戦した「遊び」でしたが、多少はほかのことも習得できました。ここではppapi_simpleとnacl_ioを紹介したいと思います。

そもそもNaClのコードは、ちょっと特殊な構造になっています。はじめにこういう名前の関数が呼ばれる、こういうクラスのサブクラスを作っておくと、JSからpostMessageが届くとこのメソッドが呼ばれて、そのときの値はこれこれで、などなど。

ppapi_simpleはその辺のことを面倒見てくれる便利ライブラリで、NaClのSDKに添付されています。普通のCのint main(int argc, char* argv[])のような関数を定義し、PPAPI_SIMPLE_REGISTER_MAIN()というマクロでその関数を登録しておくと、「初期化する」とかいったこまごましたことをひと通りやってくれて、mainのなかでループを書いてメッセージを受け取る、といったことができます。メッセージを標準入出力をとして受け渡しするようなこともでき、REPLの実装などがラクになる感じです。stderrに出力するとconsole.errorになってくれるというのもppapi_simpleの機能だったような気がします。

nacl_ioはファイルIOのためのラッパーです。スクリプト言語を動かす場合、初期化するにしてもライブラリを読むにしても、どこかにあるファイルを読む必要があります。ところがこれが厄介でして、HTML5のfilesystem APIはNaCl用の独自のAPIを呼ばなければなりませんし、NaClバイナリと同じディレクトリにファイルでも置いておくかと思えばHTTPでフェッチしないといけないし、かなーりめんどうなわけです。

nacl_ioはディレクトリをマウントすることでその辺をラップしてくれる便利ライブラリです。"httpfs"という擬似ファイルシステムが指定できて、こいつを指定するとファイルをopenするだけでフェッチしてどうこうみたいなことをまるっとやってくれています。上で指定したchibi-schemeでもこれを使っているので、様々なライブラリをロードできますが、その都度ロードしているのでimportするとネットワークを感じます。

naclportsに入っているLuaやPythonなどでは、必要なライブラリファイルなどをまとめてひとつの .tar ファイルにしておき、これをhttpfsで開いてlibtarを使って（やはりnacl_ioでmemfsとしてマウントされている）ディレクトリに展開する、といったことをやっているようです。都度ロードはやっぱり遅いですからね。

そういうわけで、「NaClで遊ぶ」の一部始終でした。