Google App Engine

忙しさにかまけていたら,こんなに面白いモノがでてたのを見逃してた。
http://code.google.com/intl/ja/appengine/
早速 Hello world! 的なものを作ってみる。
http://iwate.appspot.com/
ActivePython の x64 版だと SSL のモジュール (_ssl.pyd) がなくて,dev_appserver.py 動かすときや appcfg.py update するときに,怒られる。

AttributeError: 'module' object has no attribute 'HTTPSHandler'

自分で入れてもいいんだろうけど,(XP x64 や Vista 64bit ユーザでも)面倒な人は x86 版を入れるのが吉。っていうか,何で x64 には入ってないんだろ。
もうこれから作るアプリ全部 Python でよくね?という気もするくらいおいしいが,Perl で今まで書いたのをゼロから作り直す気はしないんで Perl サポート希望。

Windows XP x64 Edition で Visio のデータベースモデル図を作成しようとするとハングする件

日本語で検索しても全然情報が出てこないが、visio database hang 等で(日本語のページに限定せずに)検索するといくつか情報が出てくる。
どうやらプリンタドライバに問題がある場合にハングする(応答なしになる)とのこと。とりあえず、適当に違うプリンタ(Microsoft XPS Document Writer)を指定してからデータベースモデル図を新規作成したらうまくいった。
Visio 2003でも2007でも同じ症状。OS が Vista x64 でも同じらしい。

たかがビルドでハマりにハマる

何台かでソースからビルドした NetBSD の /usr/bin/ld のうち一台だけ動かない。

$ ld
ld:built in linker script:1: ignoring invalid character `20' in expression
ld:built in linker script:1: ignoring invalid character `37777777646' in expression
ld:built in linker script:1: parse error

それぞれバージョン違いで,動かないのは netbsd-4 のツリーをビルドしたもの。netbsd-4 のバグかと思い,別のマシンにもたまたま netbsd-4 のソースが展開してあったのでビルドするとうまく動く。
あれこれやって,生成された eelf_x86_64.c がおかしいところまでは突き止めたが,何故おかしくなるかわからないので,ビルドログを比較してみると,エラーが出ているのを発見。

 #    create  ld/eelf_x86_64.c
unset MACHINE || true;  LIB_PATH=/usr/lib
/bin/sh /usr/src/gnu/usr.bin/binutils/ld/../../../dist/binutils/ld/genscripts.sh /usr/src/gnu/usr.bin/binutils/ld/../../../dist/binutils/ld /usr/lib "/usr"  x86_64--netbsd x86_64--netbsd x86_64--netbsd  elf_x86_64 /usr/lib no elf_x86_64 "x86_64--netbsd"
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory
+sed: stringify.sed: No such file or directory

その手前で stringify.sed が作られていない模様。

-#    create  ld/stringify.sed
-rm -f stringify.sed
-ln -s /usr/src/gnu/usr.bin/binutils/ld/../../../dist/binutils/ld/emultempl/astring.sed stringify.sed

で,結局あれこれいじっていると,/usr/src/gnu/usr.bin/binutils/ld/stringify.sed (シンボリックリンク)があるのを発見。既に存在するので作られないが,実行時に使われる /usr/obj/gnu/usr.bin/binutils/ld/stringify.sed がないというオチ。
結論としてはこんなかんじ。

  1. 何かの拍子に(過去に)ソースツリー内にシンボリックリンクを作ってしまった。(多分自分のミス)
  2. オブジェクトのディレクトリがソースのディレクトリとは別(NetBSD本体のビルドでは常にそうなる)であってもソース側にターゲットが存在してしまっているとオブジェクト側に作られない。(makeの仕様)
  3. ビルド中に使っている binutils/ld/genscripts.sh の中でエラーを起こしてもビルドが止まらない。(?)
  4. 結果として出来上がった eelf_x86_64.c が壊れているにも関わらず,コンパイルが通ってしまう。具体的には char * で内蔵 ldscript を返す関数が,stringify.sed がないせいで何も作られず,return; となってしまっているのにエラーにならない。(?)
  5. 存在しない戻り値(メモリのどこか)を ldscript だと思って読み込むが,当然ぐちゃぐちゃなのでエラー。

まあ発端は自分が悪いんだけど,バグで同じようなことが起きる可能性も考えると,ツール類も -Wall … -Werror つきでコンパイルできると本当はいいんだろうねえ。