今日は2007シーズン開幕戦、2階席で見てました。 歌詞カードを見ると、新曲が2曲発表されたようだ。1曲しか聞いてないが、メロディを思い出したり忘れたりしている。今は忘れているところ。今年もコールリーダーは西野君のようです(私の席からは上半身だけ見えていた)。 久しぶりの等々力はほぼ満員に。開門くらいに到着すると7番ゲートの末尾はゲートボール場に達し、ゲートボール場内で幾重にも折り返されていた。常に観客動員を気にするキャプテン伊藤宏樹をして「あのお客さんの入りで2万人ですか（20,295人）。もっと入ってるのかと思いました(jsgoal.jp)」と言わせるほどの客入り。みんな試合を待ち望んでいたんだなぁ。 スタジアムではとりあえず新発売(？)のドーナツを食いつつ、ファンキーズのホットドッグはトッピングが自分でできるように改良されていたのでひとまずカレー味を食し、試合を待つ。ほどなくして座席が次々に埋まり、川島が出てきて試合前の練習を始めた。 試合のほうは昨年鬼のようなキープ力を誇った我那覇がすぐに囲まれ、前線でのキープに苦しんだこともあって、序盤はかなり鹿島ペースで進んだ気がするが守備意識が高くチャンスを作らせない。このへんで昨年との違いを見せてくれる予感を感じさせた。守備陣は試合が終わるまでバランスを崩すことなく集中を続け、昨年はあまり見ることができなかった無失点試合を達成。終盤にはジュニを引っかけた鹿島のDFが2枚目のイエローで退場に。鹿島は川崎戦で退場になることが多いですよね。 鹿島はキャプテンマークは柳沢が巻いていた(川崎は憲剛)。得点シーンは右サイドで粘って得たボールが中央の憲剛を経由して左サイドの村上へ。村上が放りこんだボールは正確にファーサイドのマギヌンの頭にヒットしたもの。 流すのが大好きな吉田主審の流しに対応しきれないシーンが気になったなぁ。終盤に箕輪がセルフジャッジしたシーンなど。この試合は荒れ気味な時間もあったけど、ACLを考えると綺麗にやることに固執するほうが危険なように思う。欲を言えば何度かあったチャンスにジュニが決めてほしかった。本人も決めて気分良く終わりたかったろう。交替は我那覇に代えてテセ、村上に代えて西山。テセは悪くない動き。西山は残念ながらなかなか試合に入りきれず。 次は水曜にインドネシアでアレママラン戦(行けず)、その次の日曜はアウェイ神戸戦です(これは行くつもり)。

ひとつ前の続き。 xpsに入っているバイナリファイルの内、odttfはほとんどttfでした。jhdでダンプするとすぐに特徴的なttfのテーブルが見えまして、少し書き換えるとttfとして使えます。ただしそのxpsに必要な文字だけしか入っていません(当然ですが)。ヘッダの長さが44バイトに変わっていて44バイトの中身はよくわかりませんが、ttfに変換するスクリプトをgitのリポジトリに入れておきました。

# cg-clone /xps.git/
# cd xps
# python odttf.py xxxx.odttf ...

のようにしてみると、odttfがttfに変換されます。次はこれを利用してttfを作り、XPSの表示に生かすことになるわけですが、それはまたいずれ。

ここの続き。「とりあえずパス」と言いつつ、書いてみたので公開しておくよ。 xps2txt.py

# python xps2txt.py hogehoge.xps
  :

ページに含まれるテキスト情報だけ抜き出して表示する簡単なプログラムです。少なくとも、Vistaのメイリオの情報(microsoft.com)のXPSは正常と思われる程度に処理できました(Windowsを使っていないので本当にこういう内容のファイルなのかは不明)。 「XPSのサンプル(microsoft.com)」と称されるものはLicense Agreementを読む気になれず手元にないので試していません(たぶん大したことは書いてないと思いますけど＞ライセンス)。機能がtext変換という単純なものなので、問題があるにしても多少の変更でどうにかなると思います。「FixedDocSeq.fdseqとFixedDocumentSequence.fdseqの問題」にはやられたけど。ひどいなこれは(笑)。本来のrootは別のファイルらしい。これから探します。 いずれHTMLかOpenDocument(odt)くらいに変換したいなぁ。まあでもtextの次はreStructuredText(planewave.org)とかWiki形式かな。 もしかしたら今後も続くかもしれないので、gitのリポジトリを公開しておきます。

# cg-clone /xps.git/

XPS(XML Paper Specification)(microsoft.com)というのがあるらしい。MS製PDFみたいなものだ。紙を表現するXMLということだが、ビューワもWindows用にしか存在せず(.NETのなんたらを入れる必要があるとかないとか？？)、孤高のファイルフォーマットという感じがする。最初はプリンタ用の言語(PSの代わり？)として作られたらしい。紙をXMLで表現するなど、なかなかよろしい話ではないか。だが仕様のダウンロードにLicense Agreementが必要なので仕様は落としてない。その代わり、サンプルにいくつかファイルをダウンロードしてみた。しょせんXMLだし、当分はこれで充分だろう。 というわけで仕様はともかく、MS配布のXPSファイルの中身を見ると、zipで束ねられた複数のXMLファイルだ。データとしてjpegやpng、内容は良く分からないが「odttf」という拡張子のファイルも入っていた(フォントだろうか？)。こういう構造はODFと同じようなもので、流行りかな。かなり効率は悪いと思うんだけど、何も考えなくても圧縮されるし解析がしやすいからオープンな規格にしようとするとこうなってしまう。XMLを見ているといろいろ冗長で、単純なものを扱うデータがどんどん複雑に表現されていく。入力と出力を共通化するだけのためにここまでやる必要があったのだろうか？ YAMLとかJSONが出現した理由が分かるよね。 印象としては、MSはUTF-16のテキストファイルが好きですね、というのと、いろいろな流儀のXMLファイルが混合しているので生成するのはどうやってるのかが疑問、という感じ。 まず最初のUTF-16というのは、US-ASCIIしか使ってないファイルがUTF-16で書かれていたりする。「<?xml」宣言でエンコーディングを指定しなければUTF-16という感じのルールにも見えるが、全部のXMLファイルがUTF-16であるとは限らないのが気持ち悪い。 あといろいろな流儀のファイルが混合しているというのは、上記のXMLで「<?xml」の宣言がないXMLファイルとあるファイルの違いとか、タグ間にスペース/改行が入っているのと入ってないのとか、MSがXMLの出力方法をどうやっているのかが疑問に思えたりする。普通に内部表現でXML用のツリーを作って一箇所で出力するように書いてないのかなぁ。不思議だ。普通にプログラムを書けば同じ流儀になるはずなんだ。たまに適した流儀に変更するというのはあるが(個々の文字をエスケープしないでCDATAにするとか)。 zipに入っているファイル名も「[Content_Types].xml」(なぜ大括弧が必要なの？)とか「_rels/.rels」(なぜにドットファイル？？)とか、ちょっと気持ち悪かったりしている。 ファイルの解析としては、トップディレクトリにあるFixedDocSeq.fdseqを見てFixedDocumentSequence/DocumentReferenceのSourceに書いてあるファイル名のファイルにページのリストが書いてあり、1ページ1ページが別々のXMLファイルになっていた。紙を表現するだけあって、かなり細かい指定までできる。すばらしい。最後はodttf(フォントファイル)のパースが一番面倒になるかも。バイナリだしな。 というわけであまり積極的に見ていく気にならない気もするのだが、XPS対応のビューワかコンバータをPython/Tkinterか何かで書ければ、MacやLinux等でXPSが使えてけっこう偉いかもしれないなと思ったりもしている。 しかしもう休暇が終わってしまうのでとりあえずパスだな。いつかやろう。MSがXPSを見捨ててからやるか(笑)

今さらですが、ソーシャルブックマークを利用しはじめてみました。 wtnb75(icio.us) まだタグのつけ方がそれほど確定していない。

いま中原区には雪が降ってますね。 それだけ。

Pythonのモジュールをインストールするのにbdist_rpmを使ってrpmから入れている人で、Fedora Coreでこんな感じのエラーになるときは、

Checking for unpackaged file(s): /usr/lib/rpm/check-files /usr/tmp/scanf-1.1-1-buildroot
error: Installed (but unpackaged) file(s) found:
   /usr/lib/python2.4/site-packages/xxxx.pyo
 
 
RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/python2.4/site-packages/xxxx.pyo

こうゆうふうに変更するとよい。/usr/lib/python2.4で以下のパッチを当てる。 root# patch -p1 < patch-file

--- python2.4/distutils/command/bdist_rpm.py.orig	2007-01-19 18:57:07.000000000 +0900
+++ python2.4/distutils/command/bdist_rpm.py	2007-01-19 18:57:43.000000000 +0900
@@ -488,6 +488,7 @@ class bdist_rpm (Command):
             ('build', 'build_script', def_build),
             ('install', 'install_script',
              ("%s install "
+              "--optimize 1 "
               "--root=$RPM_BUILD_ROOT "
               "--record=INSTALLED_FILES") % def_setup_call),
             ('clean', 'clean_script', "rm -rf $RPM_BUILD_ROOT"),

RedHatのbugzilla(redhat.com)より。upstreamの問題として報告してclosedにされてしまっている。rpmを作るときに修正できる(し、その方法も分かっている)のに放置とは、いいかげんなものだ。 rpmに入れる場合のパッチは以下の通り。変更内容は同じです。

--- Python-2.4.4/Lib/distutils/command/bdist_rpm.py.orig	2007-01-20 09:56:37.000000000 +0900
+++ Python-2.4.4/Lib/distutils/command/bdist_rpm.py	2007-01-20 09:57:03.000000000 +0900
@@ -488,6 +488,7 @@ class bdist_rpm (Command):
             ('build', 'build_script', def_build),
             ('install', 'install_script',
              ("%s install "
+              "--optimize 1 "
               "--root=$RPM_BUILD_ROOT "
               "--record=INSTALLED_FILES") % def_setup_call),
             ('clean', 'clean_script', "rm -rf $RPM_BUILD_ROOT"),

正月休みを利用して、青空文庫のファイルをOpenDocument(OpenOffice.org 2.0とかで使われているドキュメントフォーマット)に変換するスクリプトを書いてみました。 まだイマイチなところもありますが置いておきます。odt.py zipの状態でも食わせることができます。

# python odt.py 789_ruby_5639.zip saruno_koshikake.txt
789_ruby_5639.zip -> wagahaiwa_nekodearu.odt
吾輩は猫である 夏目漱石
saruno_koshikake.txt -> saruno_koshikake.odt
さるのこしかけ 宮沢賢治

もともとはOpenDocumentのフォーマットを調べてみるのが目的でした。縦書きにしようと思いましたが普通にやると(OOoのバグだと思いますが、)ルビがずれるので…直す方法はあるらしいですが、横書きのままで。

最近は低レベル系の人が張り切ってますね。一応言っておくと「低レベル」と言っても技術者の言う「低レベル」は一般の人の意味とは違います。レイヤが低いという感じの意味ですね。 というわけで私もBinary Hacks(amazon.co.jp)という本が意外に面白いので買ってみたり。この本は100個の"Hack"と称して低レベルな話が載っていますが、誰しも101個目のHackを持ってるんじゃないでしょうか。私はあまり凄い人ではないので、あの本よりも高いレイヤにはなってしまいますが、役に立ちそうなものを1つ紹介しておきます。 ★Hack #10101 initrdで遊ぶ Linuxのブート時のある時期に、initrdというファイルが読み込まれます。ブート時に指定できるんで、指定しなければ読み込まれないんですけど、grubもliloもsyslinuxもpxelinuxもinitrdを読み込む機能はついていますから、普通は読み込む。そんでこのinitrdの内容が一旦/としてマウントされた状態になるんです。本来の/がマウントされる前にちょっとした処理ができるようになっている。 initrdのフォーマットは昔はext2とかのファイルシステムが圧縮されたものだったんですけど、最近はcpioが圧縮されたものになってます。通常このinitrdファイルを作るのはmkinitrdというコマンドで、中身はスクリプトになってます。特に難しいことはしていません。nashがinitとして動いてモジュールをロードしてデバイスを作り、マウントして/を切替えているだけです。 nashは大したスクリプト言語ではなく、条件判断もできませんが、insmodやmount、echo、sleepなどの内部コマンドの実行に加えて、外部コマンドを呼び出すことができます。mkinitrdが作るinitrdのnashスクリプトは、initrdの中に入っているディスクのドライバモジュールを読み込んでmountするわけです。サンプルを見たいなら、gzip+cpioでシステムのinitrdファイルを展開してスクリプトを見てみるといいです。man nashにも有用な情報が書いてあります。 initrdとnashを応用すればいろんなことができます。1FD LinuxやCDで上げるLinuxではけっこう変なinitrdが使われてるんじゃないかなという気がする。 ●カーネルのリコンパイルなしでNFS Rootを実現する 例えば、NICのドライバを読み込んで自分のIPアドレスを設定し、NFSのドライバを読み込んでNFSを/にマウントすることもできます(nashの内部マンドのmountはNFSに対応していないので外部コマンドとしてinitrdの中に入れる必要があります)。普通はNFSを/にするにはカーネルをリコンパイルする必要がある、とされていましたが、initrdに必要なドライバとスクリプトを入れておけばわざわざリコンパイルする必要はなく、ディストリビューションのカーネルをそのまま使うことができます(少なくともRed Hat Enterprise Linux 4系やFedora Core 3〜5は大丈夫でした)。 とは言え、システムにはNFSで他のマシンと共有できないディレクトリもありますので、Root環境を快適に使うにはもう少しの工夫は必要になります(大したことではないです。/var/runや/var/lock/subsys、/etc/mtabの処理とかそういう)。 NFSと同じ要領で、iSCSIを/にマウントすることもたぶんできます(iSCSIrootは私はやったことがないです)。 ●tmpfs rootでディスクレス環境 また、本来の/自体を全部initrdの中に埋め込んでおき、tmpfsを/にマウントしてファイルを展開してswitchrootしてディスクレス環境に、というのもなかなかおもしろいテクニックです(これが意外に快適なんです！)。 ●まとめ initrdはちょいと遊ぶに値するということを説明しました。面倒なので実例は出してませんが、暇ができたら遊んでみるといいと思いますよ。ブートローダにもよりますが、けっこう無謀なこともできちゃいますので。

私は現地に行けませんでしたが、丸亀にてシーズンは終了してしまいました。 3大大会全てでベスト4というのが川崎の年初の目標でしたが、ナビスコカップベスト4、リーグ2位といい調子でクリアしていったものの、天皇杯はベスト16止まりとクリアには至りませんでした。それでも上出来だとは思います。リーグ終盤に守備のバランスを大きく崩しながら、敢えて修正せずに勝点のみを追求してしまったのが裏目に出たんでしょう。最もプライオリティの高いリーグ戦でそれで表目(？)を出したわけで、特に文句はありませんよ。 注目の入替戦はアウェイゴールルールにより神戸が昇格。劇的でしたね。微妙なシーンもありつつ。 そんなこんなで、思っていたよりも少し長いオフになります。