Mozillaのパーサーが不正な文字コードのXMLに対してエラーを投げないのは元からしってたけど、それXMLのスペック違反だよねって話。これを調べてみてわかった話がこれ、Bug 174351。オーナーじゃないからレビュー出してない。
そもそもIUnicodeDecoderの実装の動きが文字コードによって違う。UTF-8だと不正な文字が見つかった時点でエラー終了なんだけど、それ以外は違うんだよね。って、そこは元々Frankが実装したどころだっけ？
WorkItemバグとして昔ファイルしておいたけど、離れた数年間で誰も修正してくれなかったやつの一つ。Dougと話中
Google-breakpadというエラーレポーターがあるんだけど、そのダンプの生成方法について、いろいろ直そうとしてる。というのも、今のLinuxクライアントのコードはx86にべったりしすぎなコードになってて、他のプロセッサへのポートが困難。
RedHat Enterprise Linux 5.2が出てから約1ヶ月たったけど、そのクローンのCent OS 5.2がリリースされました。
http://lists.centos.org/pipermail/centos-announce/2008-June/014999.htmlUpdating from CentOS-5.0 and 5.1
If you are already running CentOS-5 ( either 5.0 or 5.1 ), all you need to do is run : "yum upgrade" on your machine, and that will bring in the new packages from 5.2 and update your machine. Note that the command required is 'upgrade' and not the usual 'update'. Refer to the yum man page for details on how those two differ in operation.
Should the CentOS-Base.repo file on your existing CentOS-5 install be modified, you might need to pay more attention to the output from the 'yum upgrade' command. If the following command produces no output, your CentOS-Base.repo file is intact :
rpm -V centos-release | grep CentOS-Base
Bug 439199 - Enable SSE2 for MSVC++
Microsoft Visual C++を使っている場合にSSE2の最適化コードを使ってないので、それようのbugを開いた。NSSなんて、wtcやnelsonといったレスポンスの悪い人たち相手なので、すぐチェックインができるわけでもないし、Thunkツリーに入れるので、Fx3.1とかで使うコードになるかどうかは微妙だけど。
それはそうと、GCCを使っている場合は、NSSでSSE2の最適化コードが使われるんだけど、それって、Intel CPUじゃないと動かないのね(Intel以外は無効にしてる)。今初めて知った。
今回の買収話ってのは、おそらく後ろで提言したのは、Kevin Johnsonらへんじゃないかなぁって思うんだが。彼がLive担当になって（今はどうだか知らないけど）出した結論が、今のようにLiveをやってても勝てないということかと。
Yahooに話を持って行って、それがダメになるのは重々承知でなおかつ、それが失敗したとしてもYahooという会社の存在価値をもなくす魂胆だんたんじゃないかなぁと。プレーヤーが1つ減るということは、ある意味チャンスでのあるから(米国だとGoogleに全部持っていかれる危険性があるが。ただ、そうなると独禁法の関係で、Googleが米国政府 (EUも含めて) 管理下におかれて、やりたいように出来なくなる。ある意味Googleにとってもおいしくない部分になる。MicrosoftがAppleを泳がせたように、GoogleにとってもMicrosoftを泳がせないといけない)。
Microsoftのダメなところは、Windows NTやSQL Server、Exchange Serverで見せたような粘りがLiveに見られないところ。Liveチームはある意味ぬるま湯でもあると言われていたから、どうしようもない機がするけど。ヨーロッパらへんのベンチャーを買って、そこを本拠地で立て直すのが賢明かと思うよ、実際。
とりあえずメモ書き程度。Fedora 9上の話だけど、Ubuntuでも大丈夫かと。
待っていれば、自動的にインデックスが作成されて、Trackerのツール上で検索ができるようになる。
mozilla-centralに移ってから、初のチェックイン。とりあえずメモ書き程度に残しておく。
とりあえず、hg commitで変更をローカルへコミット。本当は、-mをつけてログをコマンドラインで書く方がベター。
makoto@localhost:~/Development/mozilla-hg/mozilla/xulrunner$ hg commit app/xulrunner.exe.manifest stub/xulrunner-stub.exe.manifest
ちなみにコミット内容は、これ。
makoto@localhost:~/Development/mozilla-hg/mozilla/xulrunner$ hg log -l 1 changeset: 15286:039430d96985 tag: tip user: Makoto Kato <m_kato@xxxxx> date: Sat Jun 07 08:14:56 2008 +0900 summary: Bug 437046 – Support x64 for xulrunnder.exe.manifest. r=ted.mielczarek
ローカルにコミットした後、hg pushで本体のmercurial serverへコミット。
makoto@localhost:~/Development/mozilla-hg/mozilla/xulrunner$ hg push Enter passphrase for key '/home/makoto/.ssh/id_dsa': pushing to ssh://hg.mozilla.org/mozilla-central/ searching for changes remote: Could not chdir to home directory : No such file or directory remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 2 changes to 2 files
これで終了。cvsの時に比べればhg pushのような作業が増えるけど、ローカルにリポジトリを持っているので作業効率がいい。
会社でOpenOfficeを使ってて、納得いかないことが多々あったので、ちょっとコードを持ってきてみた。コードも巨大だけど、うまくまとまってないコードにしか見えないなぁと。ビルド環境作るもの大変そうなのは、閉口状態。
そう言えば、あの会社のOfficeアプリケーションもビルド環境作るの大変という話を聞いたなぁ、そういえば。
So when can we expect CentOS 5.2 then, well using the same 3,5 weeks we end up with a date of around June 14th 2008. This is of course a estimate it can be later or earlier.
http://misterd77.blogspot.com/2008/05/centos-52.html
Redhat Enterprise Linux (RHEL) 5.2がすでにリリースされていますが、それのコピーのCentOSも、5.2が6月14日くらいにリリースされそう。今度借りようと思っているレンタルサーバーはこれでも使おうかなぁと。
Googleをまねて、いろいろな会社が社員の働く環境を良くしようとしているが、とある会社の場合でのこと。
椅子が老朽化してたので、会議室の椅子がVitraのに変わる -> 満足せず
椅子が老朽化してたので、各個人の椅子がハーマンミラーのアーロンチェアーに変わる -> 満足せず
ここらへんで、豚に真珠という言葉が。。。(家で使っているVitraの椅子って10万くらいしたよ...)。で、こりずに
全ミーティングルームにプラズマ (プレゼン用) を設置！ -> 満足せず
じゃー、社員専用のスターバックス！ -> 値段が高いといって満足せず (ドリンクは割引だったんだけど)
試しに無料のバナナを置いてみる -> 大満足。ファシリティの満足度急激アップ
(バナナ以外の順番はちょっと違うんだけどね)
結局、ファシリティの満足度を上げるベストプラクティス (あの会社が好きそうな言葉) は、無料でバナナを配置するだけだったという。。。価値のわからない人に高価なものを渡しても、それは職場環境の改善にはならないわけで、誰もがわかりやすいものを与えないと、その費用は無駄にしかならない。
まぁこの後、バナナのおいてある場所が悪い (取りに行きづらい) だとか、各営業所にも置けとかいう意見が来たのは言うまでもない話だけど。
ARMのマーケティング側の人間からはFlashもFirefoxも動くという話はでるが、それは正しい。Mobileで考えてもFlash Lite 3がNokiaのS60 (CPUはARM) でも動いているし (Nokia Web Browser上で、YouTubeを見ることができる)、N800/N810もOSは、LinuxだけどFlash動くし。(日本の携帯電話だって、大多数がARM系なんだしね)。FirefoxもARM Linux (というか、N800/N810に乗っているWebブラウザって、今はFirefox 3ベースのもの)でも動く。
ただ、ARM用の最適化なんてしてないけど。
Intelがしきりに優位性を話すx86のプラットフォームだと、いくつかのレイヤーに対しての最適化が入ってる。
Firefoxにおけるx86最適化の部分はこれだけ。後はコンパイラがどういう風にコードを吐けるかがポイント。ほかのブラウザを考えてもその最適化は似たり寄ったりだけどね。ARMとx86のコードにおけるポイントは、コンパイラによるところが大きい。ARMだとatomic系の実装が面倒というのもあるけどさ。
世の中のインターネットデバイスで必要とされているものって、Flashサポートと各コーデック(h264など)くらいだから、どのCPUであってもパワー効率がよければどれ選んだって構わないと思う (Windows Mobileというか、Pocket PCがARMになったのもiPAQがヒットしたおかげで、ARM以外やらねぇって決めただけの話だし)。コーデックに関してはDSP経由でやれば、ARM上だってそこそこ速いんだけど (今のTIのプラットフォームなんてDSP込みみたいなもんだし)、情報がなさすぎだし、ARM上でのプラットフォーム間の互換性の問題にぶち当ってコストに跳ね返る。どっちもどっちだな。。。
mozilla2 (Firefox 3.x / 4.0等) 用のMercurialツリーのmozilla-centralがdeveloper向けにオープンしたんだけど、 試したところ、
という初期トラブルはあったものの、動いている。
ちなみに、
NSPRやNSSなどは、もとのCVSのままなんて、CVSと併用することになる。(client.pyはその辺を考慮しているが)
以下の記事を見て、倒れた。。。
「爆速! Firefox 3登場」直前 - Mozilla Party JP 9.0開催
http://journal.mycom.co.jp/articles/2008/06/01/mozillapartyjp9/index.html
Gecko 1.9のCairoは、1.6.2 (w/ pixman 0.10) ベースを採用しているんだけど、これは、ATSUI (Apple Type Services for Unicode Imaging) のサポートを止めたバージョン。なので、コードを見ればわかると思うけど、ATSUIを使っているなんて記述はありえんはず。PangoのQuartz Backendじゃあるまいし。 そもそもATSUI自体がobsolutedなものなので、それをやめて、Cairo 1.6ではCoreText (CGFontベース) に変えてる。そもそもATSUIはCarbon時代のAPIセットだったはずで、64bit版のMac OS Xじゃサポートされてないはず。(SDKを確認したけど、64ビットサポートはない)
そもそもメールを掘り出すと、2008/3/17にVladimirがこうポストしてる。
Here's a patch that renames the current ATSUI font backend to a Quartz font backend, in preparation for eventually dropping the ATSUI dependancy internally and using CGFont directly. This patch makes --enable-quartz give you both quartz surface and quartz font support; otherwise, I would've needed to use "cairo-quartz-font.h", breaking the usual pattern. I also can't think of a reason to compile with just one of those -- even if you only use one or the other, it won't hurt to have them both available (since they have the exact same dependencies).
というか、そのチェックインしたVladimirはmozilla.comの人じゃん。。。
