勢い込んでしまったけど、どうもまだMacRubyと打ち解けきれてないみたい。ちなみに、CRubyの方でやるとこんな感じになる。}$stack.push(72)$stdout.print($stack.pop.chr)$stack.push(105)$stdout.print($stack.pop.chr)$stack.push(33)$stdout.print($stack.pop.chr)$stack.push(10)$stdout.print($stack.pop.chr)exit(0)Hi!うーん、ちゃんと動いてるよなぁ。該当の箇所を調べたら、本来encodingがUTF-8のStringが来てなきゃいけないところで、MacRubyの場合はUS-ASCIIなStringが来てしまっている。あるぇ?その文字列がどっから来てるかを辿って行くとARGF.readしてるとこなんだけど、MacRubyでは既にその時点でUS-ASCIIとして読み込んでしまっている。CRubyでやったらちゃんと動くのだから、$stdin.external_encodingはちゃんとUTF-8になるはずなんだけど、そもそもそこがnilだし、opneとかset_encodingとかで指定しても変化なし。force_encodingとかしても上手くいかない。このあたりでもっと色々なことがおかしいということに気付く。MacRubyでStringが期待した挙動をしてない件いまいち良くわからないので、試しにこんなことをしてみた。0おぉう...どういうことなの...なんでこんなに違うの...。わかってないんだけど、こんな感じなのかしら。commentを見てないようで、試しにeuc-jpで書いてみたらバイト列をそのままUTF-16の文字列だと解釈してStringクラスにしていて、化ける。IOからの読み込みはASCIIとして扱っている。ARGFでもopenでも同じだった。comment、読まれるファイルのencodingに関わらず同じ。String#encodeやString#force_encodingが何もしないでselfを返してるように見える。NSStringのメソッドを使って変換してやれば変わるんだろうか?Unicodeリテラルを解釈するときに、\uXXXXの後ろ二桁しか見てないっぽい。"\u0069"がtrueって何の冗談かと思った。Unicodeリテラルの扱いが、文字列リテラルの中なのか正規表現リテラルの中なのかで違っている。/\u3069/はfalse。言えば、"(ど)"は正しくパースできるのに/(ど)/はSyntaxErrorになるところを見ると、Unicodeリテラルに限らずそもそもそこのパースのロジックが微妙に統一されてない感じ。日本語を正規表現でマッチさせてるところがまずい(ちなみにBrainf*ckは完全に、Whitespaceは不完全ではあるけど一応動いたので、ソースコードと入力にNON-ASCIIな文字列が含まれてなければ問題ないらしい)なら、完全にバイト列だと思って扱ってやるとか、正規表現じゃなくて==しか使わないとか(もちろんバイト単位で比較)、ObjCでまず入力を正規化してやった上でMacRubyに渡すとか(本末転倒!)、そういう風にすれば動かないでもないかもしんないけど、そういう文字列処理みたいなObjCであんまり書きたくないところをRubyでさらっと書けるから良いんであって、それ以外のところはそもそもObjCで書いたって大して難しくない。performSelectorとかランタイムAPIとか使いまくればいいんだよ!というわけでちょっと残念な感じ。余談esotericに付属のesocコマンドを使うとDTやBrainf*ckのコードをRubyのコードに変換できるので、出来たコードをmacrubycにかけてやれば最終的にMacOSXで動作するバイナリができます。DTのコードがなんと高速で動作するネイティブのバイナリに!...と思ったけど結構遅かった。なんかこう、色々読み込むののオーバーヘッドが馬鹿にならない感じ。deepで動かないような深い再帰のコードでも動いたりする。いうかexamples/fact.*、macrubycでコンパイルしないと動かないんですけど。何でこんなコード入れてんだ俺。Tweet2009年11月09日MacRubyさんがいけず表題通り。MacRubyとMacFUSEでファイルシステムを作ってみようとしたんだけど、なんかいまいち上手く行かない。HotCocoaがちゃんと機能してない。hotcocoaコマンドでアプリの雛形を作ってくれて、macrakeすればビルドが走って.appの形にパッケージされるんだけど、できたアプリを起動しても起動するだけで落ちる。これだけだとあまりにも分からなすぎるので、アプリの形にしないでスクリプトのまま起動してみる。`'一応hotcocoaのソースを読んでったんだけど、どうやらメニューバーを生成してるところでコケてるっぽい。したらってんでlib/manu.rbに書いてあるHotCocoa#application_menuの中身を丸ごとコメントアウトしたところ、一応動いた。作ろうとしてるのはFUSEのファイルシステムをマウントするアプリなので、別にメニューも要らないしViewも出さないしいっか、と思って、気持ち悪いけどそれは特に原因追わずそのままにして、前回のコードをアプリケーションとして起動できるように直してやる。macrubyで起動させてみると、どうやらちゃんとマウントできるようだ。よしよし、と気を良くしてmacrakeを走らせたらNamakeFS.appはできたものの、こいつをダブルクリックしても起動して直後に落ちる。スクリプトのままだと行けるんだけどアプリにするとダメ。そもそもHotCocoaでアプリを作るのが今回の主目的じゃないので、もういいや調べるのは別な機会に、と放置することにして、今度は素直にデーモンとして動くように作り直す。これは概ね上手くいって、namakefsコマンドを叩けばNamakeFSが/Volumesの下にマウントされて、FinderからNamakeFSをアンマウントしてやればnamakefsのプロセス自体も終了してくれるようにできた。次は早速AtomPubで取得した情報を出してみよう、と思ってatomutilをインストールしてみたが、どうにもこれが動かない。そもそもatomutilは1.9系でちゃんと動くのかって言われると正規表現回りでコケたりして結構微妙なんだけど、まぁ中身読んだのでごまかす手段は知っている。MacRubyから使おうとしたらどうもその問題の箇所にまで到達していない。落ち着け、こういうときは慌てず騒がず冷静に、「おかしも(おさない、かけない、しゃべらない、もどらない)」の精神が大切だ、と自分に言い聞かせて、とりあえず素のnet/httpとrexml/documentでサービス文書を取得してみる。したら何てことだ、もうその時点でダメだよ。REXML::Document.new(res.body)とかしてみたら、そこでもうコケる。ドキュメントオブジェクトすら作れん。ここでatomutil版の方のスクリプトを動かしてみたら、出てるエラー一緒でやんの。ちなみにCRubyの1.9.1ではもちろん何の問題もなく動くコード。期待通りの動作をするのは確認済み。ええい、もうあれだ、REXMLが使えないとかちょっと正直どうかと思うが、MacRubyにはまだあれがある!そうさ、NSXMLDocument(※Cocoaのクラス)!察しの良い方はお気付きかと思いますが、わざわざMacRubyで書いてるのにも関わらずMacFUSEやらNSXMLDocumentやらを使ってるせいで、段々中身はRubyっぽい文法のObjective-Cのコードと化して来ている。本末転倒な感は否めないけども、とりあえずnet/httpでWSSE認証かましてGETしてきたatomのデータをNSXMLDocumentに食わせればなんとか必要な情報は取れるところまでできた。...だと?!なんだか良くわかりません。疲れたよパトラッシュ...。結論から言うとMacRubyはぶっちゃけバグとか地雷とかが多すぎて涙が出てくるので、まだこれでどうこうしようとかは無理です。RubyKaigiのセッションで開発者自ら”Crazy"と言わしめただけあるぜ、MacRuby0.5。これみたいにすごいナチュラルにObjCとRubyの融合ができちゃうっていう「可能性」には期待しているのだけども、まだ早いみたいね...。MacRubyに深入りするのはそれはそれで楽しそうではあるんだけど、そんなことしてる内にFUSEのこと忘れちゃいそうだしなぁ。ObjCで書くかなぁ。Tweet2009年11月07日MacRubyとMacFUSEでファイルシステムを作ってみるこないだAtomPubとWebDAVの話をしてて、あーそうかAPIをWebDAVとして実装してたらファイルシステムとしてマウントできて面白かったかもなぁ、でも実装面倒なんじゃないのかなどうだろやったことないし、でもvimで記事書いて:wで投稿されてmvしたらカテゴリ変わってrmで記事削除されてとか何それ胸膨らむ、じゃなかった夢膨らむし胸踊るね、なんて考えたところでふと気付いた。あるじゃん、ファイルシステムじゃないものをクライアント側でファイルシステムにしちゃう仕組み。