Squeak 3.7 alpha

Squeak

多言語化版のメインストリームへの統合に向けて、昨日の夜は五輪サッカーの速報をWebでみながら、粛々とSARの作成に励む。文字オブジェクトの上位ビットにいれるタグを、はっきりと「言語タグである」と規定したり、ぞぞっと増えたインストール済みフォントの数に対応するべく、レンダリングできないときのフォールバックフォントみたいな概念を入れようと考え出したり、まあ要するに自分でもソフトウェア開発者が持つ自己破壊衝動を発動しつつある今日この頃であるらしい。

トゥーンタウン・オンライン

ディズニー

日本語版も出る出ると言っていたのでどうなっているのかな、と思っていたが、Disneyの子供向けオンラインゲームToontown Online日本語版のサービスもようやく始まるらしい(http://www.disney.co.jp/disneybb/toontown/index.html)。

以前、Walt Disney Imagineering R&D内の一部としてVR Studioと呼ばれていた部門があったのだが、Toontown Onlineはそこで開発されていたゲームである。僕のいたオフィスと道を挟んだ反対側(つまり今僕がいるところの隣)にオフィスを構えていた。このようなゲームを作るときは、当然ながらプラットフォーム依存性の低い3Dエンジンと、世界を簡便に記述するためのスクリプト言語の組み合わせというシステムになるわけだが、当初はSqueakを使っての開発が始まっていたりしたわけである。Panda 3Dエンジンも最初はSqueakベースだったわけだ。ただ、VR Studioの人は、ソースのバージョン管理などをファイルベースでやらないと気がすまなかったため、本来のSqueak開発ツールを使わずに、CVSにファイルアウトを入れて、ということをちまちまやっていたようである。

残念ながら、VRの人はSqueakになじめなかったのか、結局はSchemerの集まりだったためか具体的な理由は知らないが、比較的早い段階で彼らはSqueakを使うのをやめて、Pythonベースのものに移ってしまった。Alanのグループからシリアスなサポートがなかったのも大きな原因であろう。Alanは製品開発の段階になると飽きちゃって、Andreasとかそういう貴重なチームメンバーの労力を取られるのが気に入らなかったりもしただろうし。

そんなあんなはあったものの、アメリカでのサービスは結構前から始まっていて、僕もなぜかいまだに毎月お金を払っていたりする。

日本語版は旧T&Eソフトが関わっていたはずであるが、今見るとそれもまた話は変わってしまっているようだ。当初彼らは同様なコンセプトのゲームを自力で開発する、という契約を結んだもののそれが果たせず、困っているところでToontown Onlineを見せられて、「これをやらせてくれ」、という方針転換があったらしい。一時は良く日本からの人を見かけたし。だが、結局はDisney Wonderlandなるサービスは離陸したわけだな。それもまたよし。

それはともかく、Disneyが小さな会社を扱うやり方を見れば、少々株を持たれたりプロジェクトを一緒にやったりするからといって、社名までDisneyに関係ありそうなものに変える、というのはかなりばかげた行動のようにも思えるけどね。

VR Studioは僕がlay offされたときと同時に部門ごとWalt Disney Internet Groupの下に移って、今でもToontown Onlineの改良をしているはずである。

スペイン行き

Squeak

Diego達がスペインでやっているLinExプロジェクトがEUからなにやら賞をもらうことになって、DiegoはBrusselに行かなくてはいけなくなったらしい。そのため来月半ばに予定されていたスペイン行きは5月に延期になってしまったという噂である。それもまたよし、ではあるが。

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バイト目をそれぞれ入れ替えないと元に戻らない、という次第。

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