鳥取の鈴木さん

Squeak

「鳥取の鈴木さん」といってもたくさんいそうであるが、それで一意に決まってしまう世の中もまた存在する。

鳥取の鈴木さんLA来訪。あちこちに展開するという話は大いに広がったが、いつもと同じで、それを実際に実装する要員をどうやって確保するのか、という問題が残るわけである。

SqueakNihongo6 beta3

Squeak

ひそかに作っていたSqueakNihongo6 beta3は、あまりにもお間抜けな間違いがあって正にがっくり。あまりにもがっくりきたので、最近良く見かけるがっくりAAを自分の日記に使いそうになるところであったが、とりあえず今回は踏みとどまった。危ない危ない。なにしろ、自分のところのテストでも分かるようなものをサボってはいけませんでしたな。

京都大学の盟友、某吉正君からのリクエストに対応しようとコードを追っかけているうちに、めでたいことにプロジェクト保存時に水色のバーがずっとぐるぐる回り続けていつまでもとまらない状態になってくれました。見てみたら、なるほど、このバグの原因はそういう理由だったわけですね。うーむ。やっぱり普通じゃないコンフィグレーションとかもいろいろ試さなくては駄目だよな。でも、一つバグつぶしできたような気がするので良かった良かった。

squeakland.org

メール

別に必要はなかったのでほっておいたのだが、ふと思い立ってyoshikiというメールアドレスをsqueakland.org上に作ってもらった。ACMの会費を払う余裕がなくなったらそれがメインのアドレスになるかも。

Short quantity

Squeak

16-bitデータの配列がプラットフォームを越えて正しくセーブできないという問題は、一度直したつもりになっておきながら実はまったく直っていなくて、思ったよりはややこしい、ということだけは分かっていたわけだが、もう一度見直してみたところ、前回コードを書いたときに立てていた仮説が間違っていたのは無理もないよな、ということで納得。

squeak-harvestには、かっこつけて"But the margin of this email is too small to contain it."などと書いてみたが、せっかくだから書いておこう。

digitAt:はプラットフォームのエンディアンに関わらず、同じレシーバーと引数ならいつも同じ値を返す、つまり実質的にエンディアンを吸収するので、Stream>>nextWordsPutAll:がデータを書き出すときはバイトオーダーはどうであれ、常にワード内のLSBから書き出していくことになる。何でLSBからなんだ、という疑問もありうるわけだが、LargeIntegerとの互換性を考えればそのほうが便利なわけだな。ただし、ワード内のshortワードの順番はエンディアンによって変わっているので、objectForDataStream:ではshortとして16ビットの値を入れ替えたものを返すようにすれば、ビッグエンディアンのプラットフォームでもリトルエンディアンのプラットフォームでも同じ順番で書かれるようになる。

一方、読み込むときには基本的にBitBltがエンディアンを吸収してしまうのでワードないでのバイトスワッピングはしなくてよいのだが、16ビットワード内をみると、バイト順が狂ってしまっているので、0と1、2と3バイト目をそれぞれ入れ替えないと元に戻らない、という次第。

短くまとめれば、思わぬところに出てきたバイトオーダー変換の非対称性とでもいうべきだろうか。