近頃のパッケージツリーでは setup.exe で新しい lib*.dll がインストールされると、ほぼ確実に autorebase が postinstall で動いてしまい、どの都度 unable to remap 地獄に突入することになる。
前回 offset がぶっ壊れた DLL を再インストールして、丁度良い offset を探せば良いと書いたが、どうも rebase 再実行はしなくても動くっぽいことがわかった。
というわけで unable to remap が発生したら
を再インストールしてやれば少なくともシェル起動まではいけるはずなので、あとは必要に応じて、怒られる DLL を再インストールしてやれば、普通に使えるようにはなるはずである。
冷やし中華はてなブログはじめました。
はてなブログ に移行しました。
おそらくもうこちらへの記事の追加はないです。
複数の port で待ち受けられるプログラムを簡単に書く方法を考えてみた。
続きを読む探してみたら IO_Bit というのもありました。
string をがっつり渡して、integer などに変換するインタフェースっぽい。resource から string にするまでは関与しないということらしい。
以下、これらを踏まえてのインタフェースについての考察を述べてみる。
PHP は基本的に resource からの入出力データインタフェースが string である。そのため、バイナリデータを扱うためには string に対して pack / unpack や ord を使うのが定石っぽい。
PHP の文字列は言語仕様を見ると Java における byte[] に近い *1 とは言え、ストリームからのデータが string を経由することを利用者が意識しないといけないのはあんまりスマートじゃない気がするため、resource を渡したオブジェクトから直接 readXXX したら、その型のデータで得られるインタフェースが望ましいのではないかと思っている。(つまり java.io っぽいやつ)
去年の年末の話なんですけどね。（；＾ω＾）
ONKYO WAVIO ワイヤレススピーカーシステム DLNA対応 15W+15W ブラック GX-W70HV(B)
そろそろなんかちゃんとしたコードを公開しないとプログラマとして淘汰されるなあと強迫観念みたいなものを感じてる今日この頃です。
ここ一年くらい業務でログ集計系のコードを書くことが多く、その際に毎回、ログをパーズするためのプリミティブなファイルシステム関数の一連のコードをおまじないのようにコピペすることに抵抗があったため、java.io みたいなクラス群にまとめられないかなと思った。
既にこの要求を満たすものがあれば、それを使えばいいわけであるため、調べてみると当然ながら既に同じようなことを考えている人はいた。
前者はまさに java.io のインタフェースに沿っているなあという印象で、後者はバイナリデータ周りの実装がきちんと整っている。ただし、いずれも名前空間を使っていない。
とりあえずこの 2 つのいいとこどりをしたものを書いてみるというところから始めてみることにしてみようと思う。
ちなみに repo はつくってあるけど、中身はまだない。
レビューで
$msg = $flag ? 'hoge(foo)' : 'hoge(bar)';
のようなコードを見て、まとめたいなあと思ったので、
$msg = sprintf('hoge(%s)', $flag ? 'foo' : 'bar');
と指摘したら、かえって可読性が落ちた。
何でもかんでもまとめるのは良くないなと反省した。
