某日記

(中期)

平成16年7月11日(日曜日)

昨日

伊賀ずきん(2) / たなか のか」 を読んで寝た。乙女ちっく忍者。

GTK+ の話

ふむ 。 この話は根が深い。

実はうちかわさんの言う GTK+ の問題と SunOS4 流の a.out マイナーバージョンの廃止はあまり関係ありません。 マイナーバージョンの廃止で何が困るかというと、 「古いライブラリと新しいアプリケーション」 という組み合わせを検出できないという一点です。 ここでは、新しいライブラリでは常に後方互換性が確保されていることが 前提条件となっています。一方で GTK+ 問題における論点は、 新しいライブラリで後方互換性が確保されていないという話ですね。 後方互換性が崩れた場合には、a.out では so のメジャーバージョンアップを要求しますし、 ELF では soname の変更という形になります。 この場合には a.out も ELF も大して違いがありません。 いずれにしろ、GTK+ はこの辺をちゃんと守れていなかったのかもしれません。

しかしながら、うちかわさんの言う問題はそもそも、 バイナリ後方互換性どころかソース後方互換性が崩れてしまっていますね。 こういう場合、 a.out のメジャーバージョンとか ELF の soname の仕組みすら無力です。 なぜならば、ソースの後方互換性が存在しない場合には、 あるアプリケーションをコンパイルする時やリンクする時に、 このアプリケーションと相性の良いバージョンのライブラリに対する インクルードファイルや lib ファイルを「明示的に」 指定する必要があるからです。これを行うためには、 メジャーバージョンや soname ではなくて ライブラリ名そのものを変える必要がでてくるわけです。 libgtk12.so なんてやり方はまさにこれですね。 まあ LD_LIBRARY_PATH や、リンカの -L や -R オプションを 使う手もなくはないのですが、そういう暗示的に近い方法は混乱の元でしょうな。

ソース後方互換性とバイナリ後方互換性の関係ですが、

  1. ソース後方互換性が崩れているときは、普通バイナリ後方互換性も崩れる
  2. ソース後方互換性が崩れていないからといって、 バイナリ後方互換性が崩れていないとは限らない
となります。2 に関して説明すると、C の場合はたとえば、 構造体の要素のうちでライブラリ内部でしか使っていないプライベートな メンバを変更したような場合には、ソースの後方互換性は保たれますが バイナリの後方互換性は崩れたりします。 C++ ではこれが特に顕著になりまするな。 so のメジャーバージョンアップや soname の変更は、 まさにこういうケースを救うための仕組みなんですね。 Objective C のように ABI に byname な方法を使うと これすらも防げるんですが、 まあオーバーヘッドとのトレードオフになりまするな。 いずれにしろ、a.out のメジャーバージョンとか ELF の soname の仕組みを うまく動かそうとする場合にこそ、 ソース後方互換性というものへの配慮が必要になるんですね。

FreeType の本家のやり方がこのことを如実に表わしています。 FreeType は(構造体のプライベートなメンバが変更されることに起因して)、 バイナリ後方互換性はそれこそひんぱんに崩れるので、それに伴って soname (あるいは so のメジャーバージョン)はひんぱんに変わります。ところが、 私の知るかぎりソースの後方互換性は比較的ちゃんと確保されてるようです。 一回ソースレベルのインターフェースに大きな変更があったのが バージョン 1 からバージョン 2 に上がったときで、 このときには soname ではなくてライブラリ名そのものを libttf から libfreetype へと変更しています(まあ、必ずしもインターフェース変更だけが その理由ではないでしょうが)。

まあ、私は上に述べてきたようなことからの自明な帰着として 「ライブラリにとってインターフェースのソース後方互換性は必須」 だと思っていたりするんですが、これは結局は理想論なので、 大きなオーバーホールが必要になったときには次善の策として、 FreeType のようにうまく立ち回ることを目指すのがよいのでしょうな。

ところで、バイナリ後方互換性ですが、 これも理想を言えば崩すべきではありません。 組み合わせ問題が発生してしまうからです。 あるライブラリのバイナリ後方互換性を崩してしまった場合、 通常はそれに依存するすべてのライブラリとアプリケーションの 再ビルドが必要になります。 たとえば、libc のバイナリ後方互換性を崩した場合には、 他のすべてのバイナリを再コンパイルする必要が出てきます。 FreeBSD のメジャーバージョンを上げたときに、 旧バージョンでコンパイルした X のアプリケーションのバイナリを ldd で眺めると libc が二つリンクされてるのを 目撃したことがある人も多いでしょう。 したがって、NetBSD はある時期から libc のメジャーバージョンを 上げないで済むように非常に苦労してます。本当は SunOS4 流の マイナーバージョンが使えるとなお良いんですけどねぇ。 メジャーバージョンアップが必要になりそうなときは、 ライブラリ名自体を変えてしまえば多少はマシになりますが、 所詮は「多少マシ」程度です。 あるいは FreeBSD の libmap.conf って、 ほとんどこれを解決するためだけの仕組みですわね。 Darwin はもっと別の仕組みをもっていたような気もしますが 気のせいかもしれません。

さて、この方面にオープンソースの弊害があるとすれば、 それは「『コンパイルしなおせば済む』という言い訳によって、 後方互換性確保のための努力を放棄しがちである」 というまさにその精神的堕落を引き起こしてるところなんでしょうな。

もちろん、「コンパイルしなおせば済む」というのは単なる言い訳に 過ぎないということは賢明な人なら誰でも気づくことなので、 そういう堕落をしていないプロジェクトも多数存在しますし、 あるいは逆にクローズドなライブラリですらその努力を放棄している ケースが存在するというのも事実ですが、 しかしながらオープンソースが 賢明でない人々に対する口実を与えているのも事実でしょう。 「だからオープンソースはダメだ」なんて言うつもりはないけど、 しかしながらこの点を「瑣末なこと」として切り捨てるべきではないでしょう。 少なくとも「落とし穴の一つ」として直視する必要はあります。

平成16年7月12日(月曜日)

昨日

ニニンがシノブ伝。川澄はツッコミ向きではない。

玄米ブレード 雷句誠短編集 / 雷句 誠」 を読んで寝た。

今日

当然のようにメールが溜まっているわけです。

フロア引っ越したけなわ。

夕方

ふと思い立って、 技術員やってる後輩を呼び出して母校の立体視システムを見学。 なかなか気持ち悪いぞ。

んで恩師と話し込んでから別れて、後輩と焼肉食って帰ってきた。

今夏の予定

8/5 夜から 8/14 朝まで旅行行きます。

朝の時点で 8/6 長崎、8/7 長崎、8/8 博多、8/9 鹿児島、8/10 小倉、 8/11 倉吉、8/12 青森(昼)、8/13 釧路(寝過ごすと根室で死亡)、 8/14 上野となっております。

詳しくは知りませんが、 今回のキーワードは肥薩線、はまかぜ 6 号餘部停車、あおもり号、16 行程超、 ゾーン券二枚といったところのようです。

GTK+

大きく外してはいないんじゃないかと思いますです :-) 。 私が書いたことは技術的な部分での補足と、枝葉の訂正ですね。 いずれにしても、 「後方互換性をきっちり確保することが、使う側にも作る側にもメリットになる」 というところがポイントなのでしょう。

夜中

復活 。よかった。

平成16年7月13日(火曜日)

昨日

月刊1年2組(1) / 桑田 乃梨子」を読んで寝た。

エディタ

某 irc にて、 Windows のメモ帳でデカいファイルを開くと以下略という話に関連して、 エディタ実装の話。

エディタの実装の意外な難しさというのはあまり知られてないのかもしれない。 実は、データ保持の方法がかなり奥深い。

この辺 この辺 にリンクしときましょ。

夜中

これ が irc で話題。おかしいって。

細かい禁則はともかく、ありえない禁則を踏むなよ。 たとえばサンプル 3 曲めの最後、メロディが 3 でフェルマータに入ってるのに、 そのすぐ下の声部が 4 でけい留するアレンジは、私には新鮮過ぎる。 どこの世界に sus4 と 3 が共存するコードシステムがあるというのか。 というか音を聞いておかしいことに気づいてほしいなりよ。

平成16年7月14日(水曜日)

昨日

月刊1年2組(2) / 桑田 乃梨子」を読んで寝た。

今日

なんかここ 2 日くらい、アマゾンアソシエイトセントラルにログインできないな。

フロア引っ越し佳境。

ねもい。

平成16年7月15日(木曜日)

昨日

GBA 用クロス gcc のページ を改定した。gcc を 3.3.4 ではなく 3.4.1 にしたのは若干勇み足かもしれない。 パッチは多分 gcc 3.3.4 でもオフセットが出るだけで当たると思うけど。

おそろしくて言えない(文庫判)(1) / 桑田 乃梨子」 半ばで力尽き。

今日

神保町経由。

そういうのは商売とは言いません

平成16年7月16日(金曜日)

昨日

ちゃお DX。乳首キターーー!! 。他には陣名まいといわおかめめが面白かった。 いわおかめめは未だに本誌連載経験がないからコミックスも出ないわけですが、 頑張ってください。

学園アリス(5) / 樋口 橘」を読んで寝た。

今日

フロア引っ越し完了。

IPA 謹製 font

ほえー 。 GRASS って GPL なので改変自由なわけですが、 改変版の GRASS にこのフォントくっつけるのはアリなのかな。 アリなら、

rm -rf *
というようなスキームによる「改変版 GRASS」を作って (まあ COPYING くらいは残しといてあげよう)、 それに添付するという形だったらどうなんだろう。

こんなややこしいライセンスにするのは、 やっぱり IPA にはまだ変なしがらみが残ってるということかのう。

UTF-8

これ困ったなぁ 。 en_US.UTF-8 以外の UTF-8 は生やしたくないんだよなぁ……。 別に I hate UNICODE とかそういうわけではなくて、 「増やすとなったら ja_JP だけでは済まんだろう」 「したがって、Latin1 あたりと同じ方針でやると、 でかくて同一内容の LC_CTYPE が大量に複製される羽目になる」 という理由なんだよね。

FreeBSD は割り切ってパッケージになってるな。

下手に symlink とか使うと将来に遺恨が残りそうだから、 locale.alias でも導入して当面は逃げるのかな。 2.0 置いてけぼりになっちゃうけどな……。 困ったなぁ。

でも今のところ一つあたり 85kbyte か。まあでも少ないに越したことはないな。

夜中

この辺 読んでジェネレーションギャップを感じたりとか。 私は歌代さんの「Little Perl Parlor」で perl4 を覚えたなぁとか、 perl-5.000 が出たのは 1994-10-18 だから、perl5 系列はもうすぐ 10 年か、 とかそんな話を。

平成16年7月18日(日曜日)

おととい

1+1 / 藤崎 真緒」を読んで寝た。 双子の場合は、先に生まれたほうは妹であって姉ではない、 と我田引水してみる俺。 最後までヤらなかったのでいぶかしげに思っていたところ (最後の 2p の間でヤっちゃってると解釈することも可能だが)、 連載再開するらしいので多分いつかはヤるのでしょう<何をだ

昨日

ピンクでいこう! / 原田 妙子」 「聖・ドラゴンガールみらくる(2) / 松本 夏実」 を読んで寝た。原田妙子はリボン向きだわな。

今日

ドトールでマターリ。

GSM

GSM 06.10 lossy speech compression 。 GSM のエンコーダ/デコーダライブラリとツール。 基本的に AS IS ライセンス(といっても GSM 自体が patent tainted だが)。 NetBSD の pkgsrc には含まれてる。

GSM なので音楽のエンコードには全く使えないけれども、 人の声ならそれこそ携帯電話クオリティで 13kbps まで圧縮できる。

平成16年7月19日(月曜日)

昨日

蒼紫の森 / 桑田 乃梨子」を読んで寝た。 コミックスの穴埋めとして収録されていた短編を集めた文庫。 だいたいすでに読んでるものばっかりだったりするわけですが。 「制服の高校生中心の読み切りを集めた本」と書いてあるけど、 どっちかといえば 「制服の高校生中心の話ぱっかりだから自然とそうなった」 が正しいような。

今日

ドトールでマターリ

国際化の一側面: メッセージの翻訳 その 1 (メッセージカタログシステム)

そのうちまとめるとしてメモ。

メッセージを翻訳するためには、 まずメッセージをプログラムから分離する必要があります。 分離するためのシステムをメッセージカタログといいます。 UNIX 環境では

  1. POSIX カタログ
  2. gettext
の二つが存在します。gettext はいくつか種類がありますが、 普通は GNU gettext を指します。もともとは GNU の物ではないんですけどね。

ちなみに、個人的には gettext はクソで、 POSIX カタログのほうがまだマシだと思っているんですが、 ツールの補助がない場合や、あとから国際化する場合には gettext の方が使うのが楽なんですな。 本当は筋の悪い gettext ではなくて、POSIX カタログのツールを 整備すべきだったんですが、GNU が筋の悪い gettext の方を選んで その上に各種ツールを拡充していってしまったので、 ウンコシステムのほうがデファクトスタンダードになってしまいました。 悪貨は良貨を駆逐するわけですな(POSIX カタログが良貨かというと疑問だが)。 この点では Windows のほうがマシだったりします(所詮は「マシ」程度だけど)。

とはいえ、今どき POSIX カタログもなんなので、gettext について説明します。 GNU がツールを整備してるおかげで gettext 化は割とシステマチックに 行えます:

  1. ソースの文字列リテラルを N_() みたいなマクロで括る
  2. xgettext を走らせる
  3. 得られた .pot ファイル を LANG.po にコピーする
  4. LANG.po を翻訳する
  5. msgfmt で .mo を生成する
みたいな感じです。また、ソース本体が更新されたら
  1. xgettext を走らせて .pot ファイルを再生成する
  2. msgmerge で .pot の変更点を LANG.po へとマージ
とすると変更点がマージされます。詳しくは GNU の info を参照。

国際化の一側面: メッセージの翻訳 その 2 (Subversion でやってみる)

なんか適当に翻訳してみましょう。 手元に Subversion があったのでこいつでやってみます。 trunk の Subversion は親切なことに TRANSLATING という翻訳のための 解説文章がついてますし、上で書いたような .po の作成やマージの作業は make 一発でできるようになってます。

まず指示通り configure してから make locale-gnu-pot を走らせます。 すると、つぎのようなコマンドが実行されています:

(cd /usr/home/tshiozak/project/svn/svn/subversion/ ; \
 find . \
  -name .svn -prune -or \
  -name tests -prune -or \
  -name bindings -prune -or \
  -name "*.c" -print -or \
  -name "svn_error_codes.h" -print | \
 /usr/local/apps/gettext-0.14.1/bin/xgettext --sort-by-file -k_ -kN_ -kSVN_ERRDEF:3 \
  --msgid-bugs-address=dev@subversion.tigris.org \
  --add-comments --files-from=- -o po/subversion.pot )
(この引数の解説はあとで追加しよう)。 これによって subversion/po/subversion.pot というファイルが生成されます。 中身は次のような感じ:

まずはこれを subversion/po/ja.po へとコピーします。 そして、指示通り autogen.sh からやり直すと、ビルドシステムが ja.po の存在を認識してくれます。これでスタートラインに立ちました。 

なお、Subversion のカタログは UTF-8 で書くことになっているので、 UTF-8 が編集可能なエディタが必要です。あしからず。

国際化の一側面: メッセージの翻訳 その 3 (粗訳)

メッセージカタログの翻訳は結構奥が深いのです。 まず、メッセージカタログの粗訳からはじめます。

基本的には、ja.po の msgid に書いてある文章を翻訳して msgstr へと書くだけです。たとえば、

#: clients/cmdline/diff-cmd.c:67
msgid "Can't open stdout"
msgstr "標準出力が開けません"
のようにします。訳を「ですます」にするか「である」にするかはお好みで。 ただし、なるべく統一する必要があります。

こういう単純なものはいいのですが、 中には printf の % を含んでいるものがあります。 単純なものならば、

#: clients/cmdline/blame-cmd.c:162
#, c-format
msgid "Skipping binary file: '%s'\n"
msgstr "バイナリファイルのスキップ中: '%s'\n"
のように翻訳すればいいのですが、難しいのは
#: libsvn_wc/adm_files.c:912
#, c-format
msgid "URL '%s' doesn't match existing URL '%s' in '%s'"
みたいな奴です。これは自然な日本語にしようとすると、 2 番めと 3 番目の %s の位置を入れ換えねばなりません。

解決法は 2 つあります。一つは訳のほうで無理して語順を崩さないようにする 方法です。上の例ではたとえばこうします:

msgstr "URL '%s' が、存在する URL '%s' ('%s' 中の) と一致していません"
かなり苦しいですな。もう一つの方法はポジショナルパラメータを 使う方法です:
msgstr "URL '%1$s' が、'%3$s' に存在する URL '%2$s' と一致していません"
訳文としては後者のほうが熟れていますが、 必ずしも後者のほうがいいとは言えません。なんでかというと、 いまだに printf ファミリがポジショナルパラメータを サポートしていないシステムもあるからです(NetBSD はその一つ)。 ちなみに、私は個人的には、このポジショナルパラメータという奴を printf に組み込んだ奴は万死に値すると思ってますけど。 すごく実装が面倒くさい。Subversion は APR の printf ファミリを使っていますが、 どうやらこいつはポジショナルパラメータをサポートしていないようなので、 いずれにしろ前者にせざるを得ないようです。

で、こういう風にどんどん翻訳していくわけです。 時間さえかければ簡単ですね。簡単なのが粗訳の粗訳たる由縁です。 この後にさらに面倒くさい作業が待ってるのですけど時間切れ。 粗訳したのは この辺 に置いときます。

平成16年7月20日(火曜日)

昨日

異界繁盛記ひよこや商店(2) / 巣田 祐里子」 「乙女の才能 / 松乃 美佳」 を読んで寝た。ひよこや商店は例によって例のごとし。 乙女の才能の方は、初っぱなから大野さんが喜びそうな展開なのですが、 それはそれとして、 かわかっこいい男の子とかかっこかわいい女の子とかが出てきてよいです。 立ち読み。 りぼんは他の少女漫画誌と違って、 コミック化に連載経験縛りがないので良い。もっとも外れも多いけど。 さすがにデビュー作集からチェックする気力はないが。

GPL は契約か

ということがちょっと気になったのでぐぐったら 出てきた 。 そりゃそうだよな。

まず、そもそも GPL は契約として意図されたものなのかどうかという点について 異論があると思うのだけれども、ひとまずそれを置いておいて GPL が 契約として有効かどうかを考えてみると、 ちょっと状況は違うけど、たとえば畑の横の無人販売所で野菜を買ったら、 一見契約のようには見えなくてもお金を払った時点で売買契約が 成立してたりするわけだから、GPL に基づく複製を行った時点で、 明示的なサインとかをしていなくても GPL という「契約」に 同意したと見なされても不思議ではない。

で、GPL が契約なのか、それとも不行使宣言なのかという点に関して言えば、 GPL というのは著作権法に基づく権利を行使しないわけではなくて、 (とりあえずその行使の仕方が公序良俗に適ってるかどうかは置いといて) むしろその権利の行使によって成り立っているものなので、 明らかに不行使宣言ではないだろう。 それに、GPL を契約と解釈しないと (あるいは契約への同意と解釈されないケースでは)、 免責などの条項が完全に無意味になる可能性があるのは リンク先の指摘の通りなので、 (少なくとも契約かどうかという点に関して注釈なしに使われた場合の) GPL というものは、コピー許諾契約として解釈されるべきという意図を もって用いられていると判断するに足る蓋然性があるものと思われる。

そういう意味で、GPL は契約と解釈したほうが自然だと思うのだが、 一方で GPL は契約としてはなかなか不完全だったりする。困ったものだ。

そういえば

今さらながら 「田中角栄研究―全記録(上)(下) / 立花 隆」を読了。いやー、これ今読んでも面白いわ。

思いつきの政策で一見リーダーシップを取っているように見せかけて、 その実官僚にいいように使われてたり、人気取りのために日本海を渡ったり。 はて、田中角栄よりもスケールは数段小さいし、金権こそ使わないものの、 最近どっかに似たような人がいるような。