息切れなんて言ってらんねぇ忙しさ。
まあ休日はしっかり休むんですけども。
今までRDだった日記のスタイルをMarkdown+拡張のkramdownにしてみた。 見た目的にはほとんどかわらんはずだけれども。 表作れたり、ソースコードのハイライトが標準であったりして便利なんだよね。
IronRuby使ってRubyプログラムをexeにしちゃうirpackの0.2.4を出しました。
詳しい使い方などはHomepageのところから飛べるgithubにあるREADME読め。下の方に日本語もあります。
0.2.3からの変更点は、
--completeオプションの追加上のは分かりやすいですね。IronRubyやDLRの必要なdllと標準ライブラリを全部埋め込むとそれだけで7MB越えのexeが出来ますが今時数MBくらい気にすんな。どうしても気になるなら--compressを指定すると圧縮するので小さくなります。
下のはこの前の日記を見てもらうとわかるんですが、0.2.3では作ったexeを実行した際にライブラリの検索パスとしてIronRubyがインストールされていればその標準ライブラリがあるパスが設定されていました。おかげで必要な標準ライブラリを埋め込んでないexeを作ったときに、IronRubyをインストールしたマシンではexeをどこに置いても実行できるのに、インストールしてないマシンではファイルがないと言われて実行できなくなってました。
0.2.4からはIronRubyがインストールされているマシンでも勝手にインストールされてる場所から標準ライブラリをひろってきたりはしないので、いずれの環境でもファイルが無いというエラーを出します。
もちろん--completeで標準ライブラリを埋め込んだ場合はどちらの環境でも標準ライブラリを読みこんでくれます。--completeを使わない場合は「exeのあるディレクトリ/stdlib」を標準ライブラリのパスとして検索するので、その場所にファイルを置いておくことで検索させることが可能です。
今後の予定は、
の三本です。
Rakeタスクはまだちょっと微妙だが、それ以外は近いうちにやってしまいたい。
あれー？試したけど日本語を含むパスでも問題ないぞ。会社では問題出たりしてたんだがWindows7では大丈夫だとかあるのかなぁ？謎だ。
休日しかいじる暇ないのに、土曜日はだらだらしてるもんだから日曜夜しかいじれてない。
普通に配信見るのに使ってたら例外で落ちた。IPEndPointのポート番号に負の値をつっこもうとして文句言われたようだ。どうして負の値なんか……。
PeerCastのプロトコルでは多くの場合ポート番号は16bitの符号無し整数でやりとりしてるんだが、PeerCastStationではそこを符号付き16bit整数でパースしてた。なので52000とかいうポート番号が来ちゃうと-10000いくらかとかになっちゃうわけだ。おとなしく符号無し整数にすりゃいいんだが、.NETでは符号無し整数はCLSとやらに無いとかいうのであまり推奨されてないみたい。このJavaかぶれが！J#とか作ってみたくて符号無し整数を非推奨にしたのかもしれないが世の中Cでかかれた物もいっぱいあって符号無しがある前提なのでJavaなんかに合わせないでください。Java関係ないかもしれないけど。
非推奨といってもべつに問題無く使えるので関係ないわなーといってもよかったんだけど、そもそもIPEndPointのPortプロパティがintなのでそれに合わせてメソッド内部ではushortでパースしてintで返すようにしてやった。受け取る時も同様。ちょっと気持ち悪いんだけどねー。
配信するとバッファ気味でなかなか安定しない問題が発生。ちょっと待てば安定するかと思ったが安定しないし。配信再起動すれば大丈夫かなーと思ったが全くだめだったし。しかしPeerCastStationのバグなのか普通にリレーの問題なのか判然としないので対処のしようもない。思い当たるところもないんだけどなぁ。
デバッグしようとしたら急に安定しやがるし。そんなことを30分以上やってたら安定した。なんか普通にリレーが詰まり気味なだけだったのかも。
PeerCastStationが複数起動しちゃうよという問題があったので対処したい。そもそもの問題は一部のYPブラウザにチャンネル再生する際PeerCast.exeにチャンネルIDを引数として渡して起動させるものがあるという物。PeerCast.exeは既に立ち上がっているインスタンスがあればそのチャンネルIDをそっちに転送して自分は終了する。ということは複数起動を抑制するだけじゃだめで、既に立ち上がっているインスタンスに引数を転送するプロセス間通信しないといけないんじゃないですか！すげーめんどい！！
PeerCastはウィンドウ検索してSendMessageで送り付けていた。それWindowsでしか動かないじゃないですか。しかもGUI有りじゃないといけないし。Windows.Formsだと超めんどいし。
そもそもGUIの構造を大きく変えるつもりなんでこんなところすぐにいらなくなる予定なんだよね。だからあまりちゃんと作りたくない。
簡単にプロセス間通信するなら共有メモリか何かだけど、共有メモリを実現するメモリマップトファイルは.NET4からだよ！なんでだよ！.NET3.5で作ってるから使えないじゃん！P/Invokeで作るとかめんどいしなぁ。
仕方ないから真面目に通信するかーと思ったけどやっぱりめんどい。非同期I/OするとなるとBeginReadとか使うんだが、こいつらキャンセル方法がちゃんと書いてねーからどうやってキャンセルすればいいのかとか、むりやり閉じると何が起きるのかとか動かさねーとわかんねーんだよくそが！！
で困ったなーと思ってたんだけど、System.Runtime.Remotingてのがあるじゃないですか。これ.NET4だと使うんじゃねーぞWCFつかえよって書いてあるんだが.NET3.5だし、Monoで動くかよくわからんけどべつにすぐいらなくなるコードだし、使っちゃうか。
ということでサンプルコードをコピったらすんなり動いて拍子抜け。 あんまり高度なことをやってくれるので中で何が起きてるのかさっぱりわからんが、まあいいでしょう。すぐ消すコードだし。今動けばおっけー。
そんなわけでインターフェースの整理は全く手をつけられずおしまい。
ASP.NETをアプリからホストするApplicationHostをちょっと調べたけど、これってやっぱり新しいAppDomain立ち上げるのかー。いやーそうするべきなのは確かなんだが、めんどいからやりたくねーなーとか思ってたんだよねぇ。MarshalByRefをあちこちつけて回るか、もしくはラッパをかまさないとだめかぁ。まあGUIとロジック部分の分離もAppDomain立ち上げるべきなんだよな。