大晦日は、友人の家に泊り込んでデスタンクとか人生ゲームとか色々やってました。それと、ミリタリー系の雑誌を初めて読みましたね。楽しかったです。
2000年問題は特に大きな問題は起こらなかったようですね。めでたいことなんでしょうが、少しだけ残念です。
年賀状は、まだ一通も書いておりません。さてさて、どうしたものでしょう。
広瀬隆氏の「地球の落とし穴」を読みました。こういう事について論じられる人は、ウチの学校にはどれだけいるのでしょうかね?
なんか、ISO 2022 で、内部コードが規定されていないことが、最大の弱点かも。とか書いたり書かなかったりしたことを思い出した。ってゆーか、一言で言うと面倒。概して、国際化/多言語化とかってのは面倒臭いか。例えば、ISO2022だと、SS2やSS3の後の1文字は、それぞれG2とG3の文字になるんだけど、それがいったい何バイトなのかは扱う文字集合に依存する。いや、SS2/SS3だけじゃなくて、文字単位での処理を行なう場合はいずれも同じなんだけどね。とにかく、扱う文字集合すべてについて、プログラムは事前にそれを知っている必要がある。そういえば、Unicodeも同じか。サロゲードペアもあるし、結合文字がどのような場合に発生するかとか・・・
いや、何にしてもまともな処理を行なうためには、文字集合について知っていなくちゃいけないってのは当然っすよ。でも、それはOSだとか基本ライブラリの話であって、個々のプログラムがそれを知ってなくちゃいけないってのは酷だと思うし、非効率的だ。だから、そのようなOSだとか基本ライブラリが欲しいな〜
System1には依然として興味はあるが、フリーではなかった模様。配付の条件を緩くすると言う話らしいけど、Webも更新されていないようで最近は一体どうなっているのでしょうかね〜
現状では、地域化(Localization = L10N)があって、国際化(Internationalization = I18N)があって、その先に多言語化(Multilingualization = M17N)があるという認識が多いだろうけど、本当は多言語化が一番根本に来なくちゃいけない。多種の文字を同時に扱える環境が土台にあって、その上にロケールなどの国際化機能が実装され、その上に地域化が来る。地域化は、メッセージの言語や通貨単位などをNativeなものにするのが主な役目だろう。
MIDIが聴けるようになったので、最近はBachoを聴いている。ちょっと高い音の響きがいまいちだが、全体としては悪くない。良くできた曲は音源にあまり関係なく、良く聴こえる。一方、ヘボい曲は想定している音源以外で聴くと、かなりヘボい。Bachoは良いね〜 さて、高めの音の響きを改善するにはどの辺をいじれば良いんだろ。FM音源って扱いが難しそうだな〜 そういえば、BWVを見ただけで曲名がすべて解るとかいう通の人って世の中にはきっといるんでしょうね〜
以前にSymonの話を書いたが、結局Symonではなくて、一太郎に付属していたJS明朝を使うことにした。ライセンス的にも問題は無いはず。そういえば、最近のやつは補助漢字も引き出せるらしいです。手元のでは無理でしたけど。
Internetと法について、ちょっと考えた。現在の法律はInternetにはあわないといった話は比較的良く聞く。そのための新法を作ろうという話も良く聞く。でも、少し考えてみれば解るが、Internetが既存の法秩序を崩壊させているような現象ではなくて、潜在的に存在した法の不備がInternetによって顕在化しただけのことである。これまではまず問題にならなかったような、もしくは起こり得なかったようなケースが、Internet上では普通に起こる。
例えば、甲が乙の名誉を毀損するような発言をしたという事実があったとする(笑)。その場合、甲は「乙の名誉を毀損する」であろう(おそらくは日本語の)言語情報を、音声(すなわち空気の振動)を用いて他者に伝達し、それを乙は「自分の名誉が毀損された」と認識したわけだ。そして、乙はそれを憤慨し裁判を起こした。乙が裁判に勝つためには、その集団に属する裁判官か陪審員に、上記のような事実をある程度の客観性をもって認識されなくてはならない。かなりまわりくどい書き方をしたが、法はさまざまな前提に依存していることを解ってもらえたと思う。例えば、甲と乙が世界中でこの2人しか理解できない言語では、到底問題にならないだろう。
すべての情報は、情報そのもの(コンテンツ)と、伝達手段(プロトコル)から成ると言える。我々は暗黙のうちに特定のプロトコルを前提としてきた。Internetはこの前提を崩し、プロトコルを多様化したと言える。いまや、我々は任意のコンテンツを任意のプロトコルで伝達可能である。続く次回
決定論的世界においては、未来は確定しているが、過去は不定である。単純化したモデルで説明するならば、転がっているボールは質量, 運動エネルギー, 接触面の抵抗などから、どこまで転がるかは原理的には知り得る。一方で、既に停止したボールがどのように転がっていたかを知る術は存在しない。同様に、犯人を特定するに足る情報が常に存在するとは限らない。故に、完全犯罪は原理的には可能である。証明終り。・・・アホらし。
O'REILLY®から出ている「オープンソースソフトウェア - 彼らはいかにしてビジネススタンダードになったのか - 」を買いました。面白いです。引き込まれますね。たしか、Internetで全文が公開されていたと思うので、それを読んだ方が早かったかな。
GIMPについて色々考えたのだ。 以下はこころさんのところの掲示板での発言です。
GIMPはフリーなのにPhotoshopと張り合えて凄いな〜と昔は思ってた。でも、今は逆にフリーであったからこそ、Photoshopと張り合うような事が出来たんだと思います。GIMPのメニューの「ヘルプ」→「GIMPについて」を見ると100人近い人間のクレジットが表示されます。(これには同梱されていないプラグインの著者はこのリストにはきっと入っていないでしょう。) フリーでなければこれだけの開発者を引き付けることは出来なかったでしょう。(日本人の開発者も何人かいます。)
余談ですが、GIMPのプラグイン機構は、他の同種のソフトとはかなり設計が異なっているんですよ。というのは、プラグインの機能はGIMPのPDB(Procedual DataBase)というものに登録されていて、GIMP本体だけでなく他のプラグインからも名前を指定して呼び出すことができるのです。それだけではなく、GIMPはLispの一種であるScheme言語を内蔵していて、それらからも透過的に呼び出すことが可能になっています。(GIMP-Perlモジュールを使えばPerl言語で同じことが出来ます。) さらには、そういったスクリプト自身もPDBに登録されていて同様に呼び出せるのです。素晴らしい設計ではありませんか? モジュールの再利用性が極めて高くなっています。(ちなみに、手元のGIMPには340個の機能がPDBに登録されていました。手元の環境ではPerl関係を切り捨てているので普通よりだいぶ減っています。)
GIMPに何故こんなにプラグインが沢山存在するのか? という問いに対する答えは明白です。それは、GIMPが画像処理のインフラとして機能しているからです。新しい機能を持ったソフトウェアを作りたいとして、実際に書かなくてはいけないのは、その新しい機能だけではなくて、画像を表示する機能, 画像を保存する機能, etc...のような機能を書かなければなりません。この種の作業は一般に退屈で(←ハッカー文化において「退屈」や「単純作業」は一般に悪です。)、しかも「車輪の再発明」と呼ばれるような無駄な行為です。また、画像の入出力においてはユーザーを満足させるだけの画像形式をサポートするのはなかなかに困難です。さて、ここでGIMP登場! ジャジャジャーン!! GIMPのモジュールとしてその機能を実装することで、プログラマはその種の無駄を避けることができます。画像の表示も入出力も、みんなGIMPが肩代りしてくれるのです。この辺は、Emacsの成功をうまく追随していると思います。同様の理由で、人々は「何とかファイル」を編集する専用のエディタを開発する代わりにEmacsのモードを書いて来たのですから。そしてその結果、Emacsは知っての通り、(数多くのファイルの編集支援機能を持つ)エディタであると同時に、バイナリエディタ, ウェブブラウザ, ニュースリーダー, メーラー, ファイラー, 組版プログラム, 情報管理ツール, ゲーム等でもある。
では、何故Photoshopや他の同種のソフトではなくてGIMPかというと、GIMPがフリーだからです。無料で入手でき、また誰にも独占されていない!! (フリーは「自由」だが、「結果」として無料ないしは、極めて安価で入手可能である。) 無料であることの利点は、ユーザーはがそのプログラマの書いた機能を使いたいがために$1500もの金を他者に払う必要がないということである。(私がWindows用のソフトウェアを書かなくなったのも同じ理由による。私がWindows用にソフトを書くならば、私のソフトを使いたい者は例外なくマイクロソフト税を払わなければならないが、私はそれを望まない! また、それによって、我々の自由を圧迫するものを富ますことを望まない。) フリーなプラットフォームは誰に対しても開かれている。そして、誰によっても独占されていない。あなたは、「proprietaryなソフトウェアでも、それなりの価格で入手可能ならばそれで良いじゃないか」と言うかも知れない。しかし、proprietaryなソフトウェアを選んだ代償は、往々にしてあなたが思っているよりも高くつく可能性があることを肝に命じて置く必要がある。一例を上げるならば、Alan Cox氏の指摘しているように、AlphaCPU版のWindowsNTの使用者が2000年問題でどれだけの代償を支払ったかである。また、手前ミソな問題ならば、私は以前にDibas32という無料のソフトウェアを使用しており、またそのプラグインを書いていた。しかしDibas32は既にしてメンテナンスされていない。オープンソース化の申し入れに対しても返事をもらえなかった。そして、私にはどんなに小さなバグすら(もしくは、「どんなに大きなバグすら」の方が適当かもね ;-)直すことは出来なくなってしまった。LinuxやGIMPはフリーでオープンであり、この手の問題が発生するとは到底考えられなかった。一方、WindowsやPhotoshopが、WindowsNT/AlphaやDibas32の二の舞いにならないことを誰が保証できようか。いやできない。私はこれを恐れたのだった。そしてGIMPを選択した。それは(思想的なものを抜きにしても、)最も合理的な選択だったと思う。
ちょっと政治論争モードに入っちゃいました。不愉快に感じたらごめんなさい。さて、話を戻して、なんでソースのみで配布されているプラグインが多いかという事について説明しようと思う。人によって違うかも知れないが、プラグインの作者にとって、それは最も手軽で、面倒くさくないからだと思う。GIMPは現在、UNIXライクなOSのほとんどとBeOSとWindowsで動作します。そのプラットフォーム種類たるや凄まじいです。一般にバイナリは特定のCPUの特定のOSの特定のバイナリフォーマット専用になってしまいます。GCCにはクロスコンパイル機能があって、市場に存在するほとんどすべてのプラットフォームに対応しているとはいえ、プラグイン作者にとってすべてのプラットフォーム向けのバイナリを提供するのは現実的ではないのです。自分のプラットフォーム向けのバイナリを提供していないことについては別の技術的な理由があるようなのですが、ちょっと調査中なのでパス。(ヒント: ELFのDLLの名前空間の解決の問題。)
さてさて、GIMPってとにかく凄いのよ。みなさんも、是非GIMPを使ってみてはどうです? Windows版については昔のバージョンしか使ったことがないので、最近では改善されているかも知れませんが、不安定で描画速度が遅かったです。もし、その種の問題に出くわしても大概はGIMPそのもののせいじゃないので、そういう理由でGIMPを嫌いにならないでね。:-)
偉そうな事言ってすいませんでした。m(_ _)m 私もプラグインを作ってみたので、Plugin Registry に登録しようかな〜 とかぼんやりと考えていますのでお許しを。
以下は、こころさんのところの掲示板での発言です。
GIFそのものではなくて、GIFの使っているLZWという圧縮アルゴリズムがまずいんでやんす。知っている人も多いとは思いますが、いちおう背景を解説しておきます。LZWというのはLZ78と呼ばれる考え方を効率的に実装したものです。これが1984年に発表されて、それ以後UNIX標準の圧縮ツールcompressをはじめとしてLZW法を使った圧縮ソフトはたくさん登場したのでした。ところが、このアルゴリズムはSperry(のちのUnisys)が、論文が出る一年前くらいに特許を出願してて、1985年に特許が成立しちゃったんですね。(当時は、というか比較的最近まで、アルゴリズムは数学の公式のようなもので特許の対象ではないと考えられていたんだけどね〜) そして、CompuServeが1987年にGIFフォーマットを公開しました。CompuServeももちろんLZW特許のことは知らなかったので、圧縮法にLZWを採用しました。そして、GIFフォーマットが普及するきっかけとなったのが、Webブラウザのモザイクで採用されたことです。ちなみに、モザイクがGIFを採用したのは、モザイクがアカデミックなソフトウェアであったために(特許の問題などがないはずの)自由に使えたフォーマットを選択したことによります。そして、WebではGIFフォーマットが広く使われるようになったのですが、1995年にUnisys社は「LZWおよびそれを利用したGIFは自社の特許に関わるもので〜(中略)〜ライセンスを結ぶ必要がある。」と発表したのでした。個人的には、普及してから特許を主張して金を巻き上げるなんてフェアじゃないと思います。特許が存在すると判っていたら、LZW/GIFは明らかに普及しなかったのですから・・・
書き込みに関しては、抜け穴もあります。というのは、特殊なランレングス圧縮を使うと、普通のGIFとして展開できるファイルを、LZWを使わずに作成することができます。もっともファイルサイズは大きくなりますけどね。 GIMPも時期バージョンではGIFのサポートが外されるとの噂があります。って、プラグインの配布(or 同梱)を中止するだけだと思いますが。
Unisysとライセンスを結んでいないソフトウェアを配布、または使用した場合は有責らしいです。でも、私が思うに、問題なのは「ソフトウェア」の指す内容です。たとえば、こんなことがすぐに思いつきます。外部のDLLを使ってLZWを扱うソフトが存在したとして、LZWのアルゴリズムが直接実装されていないそのようなソフトは対象となるか? 汎用的なプラグインインターフェースを持つソフトには、違法なGIFプラグインを排除する義務が存在するか? ソースコードは「ソフトウェア」か? 仕様書を喰わせるとソースコードを吐き出すようなツールがあったとして「仕様書」はソフトウェアか? 僕は法律に詳しくないし、合州国の特許法には問題が多いので、答えは知りません・・・
パテントの問題ではMP3なんかも、色々あります。合州国ではMP3がらみの特許が幾つか成立していて、それで潰されたフリーソフトウェアプロジェクトもあります。例えば、8hz-mp3とかです。もっとも該当する特許は日本では成立していないのですが、なにかと、やりにくいです。あと、ソフトウェア特許を認めていないスウェーデンで公開されているBladeEncなんかは日本でもけっこう使われているんじゃないかと思いますが、これも合州国とかで使うとヤバイかも知れません。
ソフトウェア特許については、League for Programming Freedomが詳しいです。
画像をトンネル状にマッピングするプラグインはPlug-in Registryに登録してしまった。ちょっと緊張しましたね。
それにしても、高校数学の「情報処理」というのは酷い。センター試験の数IAの問題など、「こういうプログラムを書いてはいけません」という見本のようなプログラムだった。それにそもそも何故にBASIC? C/C++, Pascal, Javaあたりならやる気も出るんだけどね〜
100 INPUT "K=";K 110 INPUT "L=";L 120 INPUT "M=";M 130 INPUT "N=";N 140 X=0 150 FOR B=K TO L 160 FOR C=M TO N 170 PRINT "B=";B, "C=";C 180 D=B*B-4*C 190 IF D < 0 THEN GOTO 250 200 E=(-B+SQR(D))/2 210 IF E-INT(E) 220 S=S+1 230 PRINT "解1 = ";E, "解2 = ";E-SQR(D) 240 GOTO 260 250 PRINT "整数の解なし" 260 NEXT C 270 NEXT B 280 PRINT S 290 END
ぐはっ、「死ねよ、テメエ」。って感じですな。無造作にGOTOとか使っているプログラムを見ると殺したくもなるでしょう? いくら何でももっとまともな書き方が可能だと思うんだけどね〜、こんなタコなプログラムで前途有望な若者の脳味噌を汚染しちゃダメっすよ。入出力の部分を省いてCで書くとこんな感じ? これはこれで気持悪い部分があるが(気づくよね?)、上のよりはましだろうと思う。
#include <stdio.h>
#include <stdlib.h>
int input(char const *prompt)
{
int i;
char *buffer;
fputs(prompt, stdout);
getline(&buffer, 0, stdin);
i = atoi(buffer);
free(buffer);
return i;
}
main()
{
int k, l, m, n;
int b, c;
int s = 0;
k = input("k = ");
l = input("l = ");
m = input("m = ");
n = input("n = ");
for (b = k; b < l + 1; b++) {
for (c = m; c < n + 1; c++) {
int d;
printf("(B, C) = (%d, %d) : ", b, c);
d = b * b - 4 * c;
if (d >= 0) {
double e = (-b + sqrt(d)) / 2;
if (e == floor(e)) {
printf("X = %d, %d\n",(int)e, (int)(e - sqrt(d)));
s++;
continue;
}
}
puts("整数解なし");
}
}
}
う〜む。Cだと数学と関係ない部分が多いか? じゃあ、Pascalはどうだ?(というか、これってObjectPascal? スマン、純粋なパスカルの文法は知らんのだ、というかパスカルってそーいう規格あんの?) 整数以外を入力すると例外投げて死ぬがそんなことは知ったこっちゃないっす。ウシシ
program hogehoge;
uses SysUtils;
function InputInteger(Prompt: string): Integer;
var Tmp: string;
begin
Write(Prompt);
Readln(Tmp);
InputInteger := StrToInt(Tmp);
end;
var
K, L, M, N : Integer;
B, C : Integer;
D, S : Integer;
E : Double;
begin
K := InputInteger('K = ');
L := InputInteger('L = ');
M := InputInteger('M = ');
N := InputInteger('N = ');
S := 0;
for B := K to L do begin
for C := M to N do begin
Write(Format('(B, C)=(%d, %d): ', [B, C]));
D := Sqr(B) - 4 * C;
if D >= 0 then begin
E := (-B + Sqrt(D)) / 2;
if E = Trunc(E) then begin
Writeln(Format('X = %d, %d', [Trunc(E), Trunc(E - Sqrt(D))]));
Inc(S);
continue;
end;
end;
Writeln('整数解なし');
end;
end;
Writeln(IntToStr(S));
end.
あ、どっちも実際にコンパイルしてはいないので動かなかったらゴメンなさい。
ゲイツがCEOを辞任してCSA(で良かったっけ?)に就いたのを、中村正三郎さんのページで「ナベツネがジャイアンツの監督になるみたいなもんですね」とあって、笑ってしまった。的を得てますよね〜
ところで、ハロッズが「エディンバラ候御用達」マークの使用契約を今年いっぱいで打ち切られる件はどう思います? 何かありそうだと思いません? ちなみに、ハロッズの現在のオーナーがモハメド・アル＝ファイドです。彼の息子が、ドディ・アル＝ファイドで、彼の義兄があのアドナン・カショーギなんですね〜
そういえば、FreePascalにもBSDへのポート作業を行なっている人がいるようですよ。いいですね〜
だいたい、「kya」で「きゃ」と入力した後、確定する前にバックスペースを押したら、「ゃ」だけじゃなくて、ちゃんと「き」まで消して欲しいものだ。これで一音節なんだから。細かいけど、いつもイライラ。
ライブラリにおいては、WindowsのDLL作成時に使うDEFファイルのようなものを使って外部から参照できるシンボルを制限できるべきだ。FreeBSDやLinuxで通常使われているELFによるDLL(*.so)で、そのような機能を利用する方法はあるのでしょうか? そのあたりに非常に興味があります。外部から参照されたくないシンボルに、「PRIVATE」のようなのつけて宣言しておいて、ライブラリにするときは
#define PRIVATE static
#include <source1.c>
#include <source2.c>
#include <source3.c>
.
.
.
というようなすべてのソースファイルをインクルードしてコンパイルするというローテクもありますが・・・ちょっとね〜 つ〜か、staticなグローバル変数で同じ名前を使ってるかも知んないし。
VDKとVDKBuilderをインストールした。VDKBuilderを起動してみると、InpriseのC++Builderにけっこう似てた。C++Builderは体験版しか使ったことが無かったので良くは判らないけど、Delphiにはお世話になったので、似ているというのは嬉しいこと。VDKはヘッダファイルざっと見たところだけど、個人的にはGtk--よりも随分気に入ってしまった。イベント・メソッド接続はコンパイル時には一連のマクロを使って簡単に出来る。(これって、C++Builder/VCLでWindowsメッセージを扱ってた方法に似てる。) vdk-1.0.2/example/hello/hello.ccから引用するとこんな感じ。
class MyForm: public VDKForm
{
VDKObject* helloButton;
VDKObject* closeButton;
VDKLabel* label;
public:
MyForm(VDKApplication* app, gchar* title):
VDKForm(app,title) {}
~MyForm() {}
void Setup()
{
VDKBox* box = new VDKBox(this);
box->Add(helloButton = new VDKLabelButton(this,
"Hello",
"Says \"hello\""));
box->Add(closeButton = new VDKPixmapButton(this,
kill_xpm ,
"DISMISS",
"Closes hello application"));
box->Add(label = new VDKLabel(this,""));
Add(box);
SetSize(200,100);
}
bool SayHello(VDKObject*)
{
label->Caption="Hello world !"; return true;
}
bool Quit(VDKObject*) { Close(); return true; }
DECLARE_SIGNAL_MAP(MyForm);
};
DEFINE_SIGNAL_MAP(MyForm,VDKForm)
ON_SIGNAL(helloButton,clicked_signal,SayHello),
ON_SIGNAL(closeButton,clicked_signal,Quit)
END_SIGNAL_MAP
動的な接続には、「SignalConnect("clicked",&MyButton::Clicked);」というようなコードを書く。(SignalConnectはVDKObjectで定義されているメンバ関数。このメンバ関数はオーバーロードされているので他の書き方も出来るかも?) 独自のコンパイラを用意していないため、言語を拡張することが出来ないことを考えれば、良い方ではないかと思う。よーするに、扱うすべてのクラスをVDKObjectから派生させることで問題を解決しているようだ。(C++のメンバ関数へのポインタは、属するクラスをシグネチャに含むからムカツクのだ。) Gtk--のテンプレートを利用した大がかりな仕組みに比べるとだいぶシンプルで(悪くいえば)原始的だ。・・・ただ、これってイベントハンドラメソッドのシグネチャをユーザーが自分で定義して使うって事は可能なの? ちょっと疑問だ。どうして不安になったかというと、私がざっと見た限りではすべてのイベントハンドラメソッドは「bool Onclick(VDKObject* sender);」の様にVKKObjectへのポインタのみを引数として受け取るものしかなかったからだ。出来たとしてもあまりキレイな方法では無いかも知れない。それにしても、イベントメソッド接続ってのは、C++ではどうもウマイ解決法が無い気がする。(もちろん、Observerパターンとかは知っていますよ。ただやっぱりイマイチなんです。Javaのこのあたりが気になる。アダプタとリスナってのはどういう仕組みなんだろ?) あと、プロパティーの定義方法が面白かった。「VDKReadWriteValueProp<VDKObject,bool> Enabled;」の様に書く。へえ、テンプレートってそういう使い方も出来るのかと感心してしまいました。国際化はあまり考慮されていないよう。とにかくしばらく使ってみようと思う。
Linuxカーネルのfs/nlsのなかを眺めて見たけど、これも多バイト文字の存在をほとんど無視したコーディングだった。マルチバイト文字とユニコードの変換テーブルが登録できない構造になってます。しかも、UCS-4ではなくてユニコードをそのまま使っているあたりが更に邪悪だ。それにしても何とかなんね〜のかな〜 (これって愚痴なんだけど、開発に参加してそういうのを直すだけの能力がない自分に対する不満であって、Linuxを開発している方々への不満じゃないです。当然ですが。) 個人的にはユニコードは大嫌いなんだが、ユニコードが如何に使えないコードかを証明するためにも、一度そのへんのコードを書いてみたいような気もする。そういえば、SoftwareDesignの2月号の「岩谷宏の Open Noises Mining」で、「インドにおけるLinux」という報告記事を, 『Performance Computing』(PC) の'99年10月号に見つけました
というような事が書いてありました。文字コード云々の話はありませんでしたが、デヴァーナーガーリー文字の扱いってのはユニコード(及びISO-10646)でかなり批判されている部分だと思うので気になります。
それと、シャリシャリ(?)したリンゴは嫌いだ。なんつーか、砂食ってるみてー ムシャムシャ。つ〜か、受検勉強せねば、とにかく。
*** Warning: This library needs some functionality provided by -lintl. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it.
そういえば、何かgettextがらみで問題が発生するときは、コンパイル時にこのメッセージが出ていたな〜 見てみると、たしかにintlライブラリのDLL版は見当たらない・・・ やっぱ、glibc2に乗り換えた方が良さげだな。(pthreadもデフォルトで使えるし。) その祭には、Plamoも悪くはないがKondaraやDebianの方が興味が湧くな。DebianベースでKondaraノリでPC-98シリーズに簡単にインストールできれば確実にそれにすると思う。・・・多分。
VDKBuilderは国際化を考慮していないと書きましたが、最新版のVDKを取って来たら、ちゃんとgtk_set_localeを呼ぶようになってましたから、GTKのロケール機能はそのまま使えるはずです。スンマセン。って誰に謝ってんだろ。これを読んでる人っているの?
javaのアダプタとリスナについてちょっと調べました。良い仕組みだと思います。ただ、これが可能なのはクラス宣言を入れ子に出来たりするjavaの構文による部分が大きいでしょう。C++とかで応用できる方法ではありませんね。まあ、それだけjavaの言語設計が良いという証拠でもあるでしょうけど。
前述のLinuxのfs/nlsですが、この実装ではユニコード自身の要請であるサロゲードペアも扱えませんね。多分、この部分のコードは遠からず前面的に書き換えることになるでしょう。・・・そういえば、日本人でLinuxの開発に深く関わっている人っているのでしょうか? ローカルパッチが色々あるのを見ていると、これが本家に取り込まれれば楽なのにな〜とか思います。なんというか、かみあってないんですな。例えば、Linux/98も本家に取り込んで欲しいし、VFAT-jpパッチも日本語に限定しない仕組みにした上で本家に取り込んでしまえば良いのにと思います。
+--------+
Linux/98 Branch -> +---! !
based on 2.2.14 ! +--------+
!
!
+--------+ +--------+
----! 2.2.13 !----! 2.2.14 !---- <- The main trunk
+--------+ +--------+
!
!
! +---------+ +---------+
Linux/98 Branch -> +---! !----! !
based on 2.2.13 +---------+ +---------+
!
!
! +---------+ +---------+
自前の修正 -> +---! !----! !
+---------+ +---------+
といったような感じでLinuxとLinux/98のソースをCVSに登録しておきたいとおもったんだけど、やり方がいまいち良く判らない。CVSのGUIフロントエンドがあると便利そうだなと思った。変更をツリーで視覚的に表示して、ドラッグでチェックアウトや変更のマージができるやつ。
jperlじゃ動かないスクリプトが増えて来ましたね。そろそろ、乗り換えなくちゃな〜
これだけは読んでおかなくては。bit誌のバックナンバーは、近くの図書館には置いていないので残念です。ちょっと遠くまで行けば見つかりそうなんですが、なかなか機会が無くて・・・ あと、『Robert T. Nyers、新・辛口テクノロジ批評「Unicodeの自滅」、Interface、Apr. 1996、CQ出版』というのも読んでみたい。
昨日、Unicode Envolves( http://www.byte.com/art/9703/sec7/art5.htm )という文章を見かけたので読んでみたら、けっこう笑えました。一例をあげると「Multibyte encodings lack the fixed-width simplicity of ASCII」とかあったんですけど、すっかりUnicodeの結合文字や合成文字、そしてサロゲードペアの存在を忘れた発言ですね。もっとも「March 1997」とあったので、この時点ではサロゲードペアは存在しなかったのかも知れませんけど。また、「The specific appearance of a font is an artistic issue, whereas Unicode itself provides only plain text. A glyph that "looks wrong" for a particular language can be remedied by changing the typeface instead of requiring a new character set.」とありましたが、何をもって「文字 = Character」とするかという定義をせずにこの手の話をしても無駄です。そんな事を言うなら「a(エー)」と「α(アルファ)」をフォント切替えてで使うような環境を想像してみれば良いんですよ。漢字統合で統合されている漢字の中には、「a(エー)」と「α(アルファ)」どころじゃないぐらい違う文字も含まれています。
getext周りのトラブルは、libintlがDLLとしてコンパイルされていないのが原因のようだ。