Universalchardet - やる気向上作戦

(via odz さんとこ)

以前から，shiki のファイル読み込み時のエンコーディング判別をどうしようかと悩んでいて，とりあえずは Gauche のを暫定的に使っていたんだけど，Shiro さん曰く

- Gaucheのエンコーディング検出アルゴリズムはオートマトンを並列に回して確率を取ってるだけですが、パラメータが適当なので結果も適当です。ちゃんと学習させれば良くなるはず。Firefoxとかに組み込まれているものの方がまじめに開発されてて認識率も良いはずです。

本当に30日でエディタが出来上がるのかを試してみるBlog (4)

とのこと．しかし，Firefox の中身を追う気力が無かったので放置していたのですが，まさしく渡りに船 ！
これは試してみるしかなかろうなのだ．ライセンスも，LGPL で使えるらしいし．

とりあえず，ソースを持ってきて，テキトーに展開．
インストールは，make/make install だけらしいんだけど，configure が無いので，多少微調整が必要．

・ いきなり，libtool が無いといわれたので，とりあえず apt しておく．
・ うちの環境だと，libstdc++ のリンクに失敗する

g++ -c -O -D_REENTRANT -I./src -I./include dll/dll.cpp -o dll.o >/dev/null 2>&1
libtool --mode=link gcc -O -o libuchardet.la dll.lo src/*.lo \
-rpath /usr/local/lib -L/usr/lib -lstdc++ -version-info 0:0:0
gcc -shared .libs/dll.o src/.libs/CharDistribution.o src/.libs/JpCntx.o src/.libs/LangBulgarianModel.o src/.libs/LangCyrillicModel.o src/.libs/LangGreekModel.o src/.libs/LangHebrewModel.o src/.libs/LangHungarianModel.o src/.libs/LangThaiModel.o src/.libs/nsBig5Prober.o src/.libs/nsCharSetProber.o src/.libs/nsEUCJPProber.o src/.libs/nsEUCKRProber.o src/.libs/nsEUCTWProber.o src/.libs/nsEscCharsetProber.o src/.libs/nsEscSM.o src/.libs/nsGB2312Prober.o src/.libs/nsHebrewProber.o src/.libs/nsLatin1Prober.o src/.libs/nsMBCSGroupProber.o src/.libs/nsMBCSSM.o src/.libs/nsSBCSGroupProber.o src/.libs/nsSBCharSetProber.o src/.libs/nsSJISProber.o src/.libs/nsUTF8Prober.o src/.libs/nsUniversalDetector.o -L/usr/lib -lstdc++ -Wl,-soname -Wl,libuchardet.so.0 -o .libs/libuchardet.so.0.0.0
/usr/bin/ld: cannot find -lstdc++
collect2: ld returned 1 exit sta

$ ls /usr/lib/libstdc++*
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.a /usr/lib/libstdc++.so.5
/usr/lib/libstdc++-3-libc6.2-2-2.10.0.so /usr/lib/libstdc++.so.5.0.7
/usr/lib/libstdc++-libc6.2-2.a.3 /usr/lib/libstdc++.so.6
/usr/lib/libstdc++-libc6.2-2.so.3 /usr/lib/libstdc++.so.6.0.8

どうやら，gcc の今の版だと，-lstdc++ は不要らしい ? ライブラリだから ???

というわけで，ためしに Makefile から取り除いたら，make / make install 成功した．謎．

----------------------------------------------------------------------
Libraries have been installed in:
/usr/local/lib

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------

とりあえず，Wiki のサンプルコードをコンパイルしてみる．

#include "universalchardet.h"
#include <stdio.h>
#include <string.h>

int main(int argc, char* argv[])
{
  char encoding[32];
  chardet_t det = NULL;
  const char* str  = "あいうえお";

  // 判別器を構築
  chardet_create(&det);
  // データを処理
  chardet_handle_data(det, str, (unsigned int)strlen(str));
  chardet_data_end(det);
  // 判別結果を取得
  chardet_get_charset(det, encoding, sizeof(encoding));
  printf("Encoding = %s\n", encoding);
  // 破壊
  chardet_destroy(det);

  return 0;
}

アプリケーションから使うときは，-lstdc++ が無いと，リンク時にエラーになる．

$ gcc ucahrdet.c -luchardet -lstdc++
$ ./a.out
./a.out: error while loading shared libraries: libuchardet.so.0: cannot open shared object file: No such file or directory

あー，LD_LIBRARY_PATH とか設定するの面倒だな．

$ gcc ucahrdet.c -luchardet -lstdc++ -static
$ ./a.out
Encoding = EUC-JP

なるほど．文字コードをいろいろ変えて保存して試してみたら，ちゃんと合ってるみたい．

文字列の形で判別結果が返ってくるのか…

とりあえず，これは扱いやすくて素晴らしい感じなので，後で shiki に組み込もう．読み込みのところをちゃんと Glib とこれを使って書き直せば，よくわからないクラッシュも無くなるかもしれないし．

linux の方は，よりいっそう微妙な環境依存が多くなってコンパイルが面倒になりそうだけど…

---

shiki-0.0.3-rc2.tar.gz

だいぶ間が空き過ぎで，作者自ら記憶があいまいになっているくらいなので，一応もう一度説明しておくと．

shiki ってのは，Gtk2 で Scheme (Gauche) でクロスプラットフォームな xyzzy (emacs) を目指しているテキストエディタです．ちなみに完成 (ver 1.0 リリース) 予定は 2016 年です (ホントか)．北海道新幹線なみのペース．最近の激動の計画再編成の動きに合わせて，山陰新幹線ばりに途中で頓挫するかもしれませんが．

ようやく Gauche 0.8.8 に対応しました．その影響で，Gauche 0.8.8 以上でないと，たぶんコンパイルできません．

Debian は Unstable にパッケージがある，と教えていただいたので，適当に gauche と gauche-dev を拾ってきて dpkg -i でインストールしてみてください．

新 API に合わせて，以前は面倒でただ Scm_EvalCString("hoge") とかしてるだけだった部分を，ちゃんと ScmEvalPacket を使ってエラーチェックするようにしました (というか，ちゃんと書かざるを得ない API に変更された)．これで Scm_Eval_CString 回りで落ちまくる問題が解決するかと思いきや，実は全然違うところで落ちていることが判明しました （ちゃんとエラーチェックするようにしたので，発見できた ← そもそも，最初からちゃんとしたコード書け…）．

今の shiki は，各バッファごとに無名の環境を Scm_MakeModule(NULL, FALSE) で作って持っているのですが，どうやらコレが，ある程度時間が経ったり，大きなオブジェクトを作る （大きめのファイルを開く，とか．gauche の文字コード自動識別ポートを利用してファイルを開いているので，ファイルを開くたびに巨大な文字列とか一時オブジェクトが作られてしまう） と，GC の対象になってしまって，エライことになるみたいです．

というか，近年まれに見るくらい根本的で致命的なバグだなぁ… よく今まで動いていたもんだ．いや，動いてなかったんだけど… （酷過ぎる）

# GC されるまでにある程度ランダムな間が生じるので，いままでバグの発見が遅れた… 同じ操作をしても，落ちたり落ちなかったり，毎回落ちる関数が変わったり変わらなかったりなので．いやぁ，GC の世界と手動メモリ管理の世界の境界のバグは，ホントにやっかいだな．恐や恐や．

これは，C の世界からはポイントされてるのに，Scheme の世界ではポイントされていないのが原因．通常，これを防ぐために，C の世界から指すときに，Scheme の世界でも define かなんかして環境に束縛しておいて，C の世界で不要になったら束縛を外す，みたいなことをする必要があるのですが．

問題は，対象が，バッファごとの環境そのもの，ということ．

ということは，環境に環境を登録しても無意味だから，たぶん，環境を，gauche の VM 内のグローバル変数に引っかけておかないとマズイと思う．

てなわけで，とりあえず SCM_CURRENT_MODULE() に引っかけておくことにした．これは predefine 済みのモジュールのはずだから，これに登録しておけば，グローバルに束縛されるはず．

/* バッファを作る関数 */
GtkTextBuffer *Shiki_new_buffer_create(gchar *filename) {
．．．

  /* 環境が GC されるのを防ぐ */
  Scm_Define(SCM_CURRENT_MODULE(), SCM_SYMBOL(SCM_INTERN(tabinfo->name)), tabinfo->env);  

/* バッファを削除する関数 */
void Shiki_delete_buffer(GtkTextBuffer *buffer) {

．．．

  /* Scheme 世界の束縛を絶つ */
  Scm_Define(SCM_CURRENT_MODULE(), SCM_SYMBOL(SCM_INTERN(tabInfo->name)), SCM_FALSE);

バッファを削除するときには，テキトーに #f とかを束縛して絶っている．

# シンボルごと根こそぎ不要な束縛を削除する方法とかはあるのかな ?

とりあえずこれで，落ちなくなった (ような気がする）．

ただし，今のところ，xyzzy とかと違って，同じファイルを開くと同じバッファが作られちゃう (xyzzy だと，filename を 2 回開くと，2 回目は "filename <2>" とかになったはず) から，前のバッファの環境が上書きされてしまうのでマズイ．同名の大きめのファイルをいくつか開くと，最初の方が SEGV を起こして死ぬことがある．

まぁ，そこらへんはおいおい．真面目に xyzzy に組込み関数の挙動を近付けていく過程で勝手に直っていくと思います．

---

放置しすぎ．もう 2 ヶ月近く更新してないよ．

そもそも，なんでこういう事態になっていたかというと （遠い記憶を呼び起こしてみる）

C 言語プログラミングに飽きた．

gauche の GC メカニズムをあんまり理解してない & コードがイイカゲン過ぎて，たぶん C の世界からはポイントされているオブジェクトが，scheme の世界からはポイントされてないせいで GC の対象になってしまっているかなんかして，やたら SEGV るようになってしまった．

やっぱ，手動メモリ管理の世界と GC の世界が混ざっていると，いろいろ相性が悪くて大変よね．ということで，しばらく gauche 以外の可能性を模索していたのであった．

しっかし，Haskell も ML も Common Lisp も，Gtk を使うのが面倒臭すぎて，なんでこれらの言語がマイナなのかという要因をマザマザと痛いほど実感しただけ，という結果に終わったのであった．そもそも Windows と UNIX でクロスプラットフォームな処理系自体があんまりないし．

そして，そんな中途半端な開発状況と，ボロボロのコードという最悪の間の悪さでオレンジニュースに取り上げ (られ | ていただいて)，いろいろと残念な思いを一人でしていたのであった．

まぁ，gauche の C API は，今後も動くかもしれないから，そっちを安定させてコードを整理するのは，gauche 0.9.0 がリリースされて，C API が mature になるまで待っても良いと思っている （けど，現時点で，Windows と UNIX のコードベースが違っているのがキモいので，早急になんとかしてたいとも （思っているだけ）．Debian の gauche は，この調子だと，永遠に 0.8.7 のままバージョンアップしなそうな感じだし）．

そんな体たらくだったものの，さっき大学からの帰り道に，define-key の実装を思い付いたので，メモしておく．

要するに，キーマップのオートマトンを表現するツリー構造 (keymap) を作っておいて，define-key するたびに再構築していけば良いのではなかろうか ?

各ノードがキー入力に対応していて，キー入力のイベントが発生するたびに対応するツリーを手繰っていって （それ以上辿っていけなかったら，エラー），もし辿った先に S 式 （クロージャ） がくくりけてあったら，それを発火 (eval) させて，キーバインドに対応するアクションを起こせば良い．

例えば，

(define-key '(Ctrl x Ctrl w) '(save-buffer-as (selected-buffer)))
(define-key '(Ctrl x Ctrl s) '(save-buffer (selected-buffer)))

みたいなのがあったら，

(Ctrl nil) -> (x nil)  -> (Ctrl nil)  -> (w  '(save-buffer-as (selected-buffer))
                                   |
                                   ------> (s  '(save-buffer (selected-buffer)))

みたいな木構造になってる．nil (でも NULL でもなんでもいいけど) だったら，次の入力を待っていて，なんか S 式が結び付けてあったら，キー入力受理ということでそれを発火 ！ （eval）

これを実装すれば，任意のキー入力シーケンスと，任意のクロージャを結びつけることがユーザ定義でできるようになるから，.shiki みたいなカスタマイズファイルがようやく作れるようになる．

まぁ，これもまた，sheme 世界と C 世界のインタラクション問題が起こって，なかなか面倒な予感がするけど．

早いところ，できる限り面倒ごとは scheme の世界に持ち込んで，C 世界は必要最小限の Gtk に対する作用だけに分離して，なるべくかかわらないような体制にもっていきたい．あと，今は，エディタのバッファ操作とかのための組込み関数を，全部 C でハードコードしてるんだけど，こっちもなるべくならできるだけ gauche で書けるようにしていきたい．生産性が悪すぎる．

あんまりプログラミングをする時間が取れないので，まだまだ先の話になりそうだけど．

いや，時間は作るもんだよ ！ ってのはもっともなんですが，最近は (低水準言語による，コーディングに近いレベルの) プログラミング熱が急激に低下しているというか．

---

う〜ん．とりあえず，一番最新っぽい　clisp + cells-gtk という組合せをとりあえず試してみた．

INSTALL.txt とか読むと，インストール自体は非常に簡単な雰囲気を醸し出しているのですが．

clisp の場合は，とりあえず　tar.gz を解凍して，ソースディレクトリに入って，load.lisp　というやつを開いて，例えばボクの場合は　/home/aloha/src/cells-gtk-2005-06-30 みたいに解凍したから

(make-pathname :directory '(:absolute "home" "aloha" "src" "cells-gtk-200
6-06-30")))) ; <=== CLISP users

とか変えておく．そして　clisp 起動して，(load "load") だけで終了のはず…　だったんだけど．なんか，途中でコケる．う〜ん謎．

というわけで，SBCL を試してみようかと．

前回，apt でインストールしようとしたら，(SBCL はネイティブスレッドを使ってる　?) カーネルが古すぎて無理だよ　！　とか言われたので，ソースからのインストールを試みる．

しかし，ここで問題が．Common Lisp の処理系をコンパイルするためには，Common Lisp　のネイティブコンパイラが要るのである　！！

なるほど…　では，SBCL をインストールするためには，SBCL のバイナリパッケージをインストールする必要があるのか．あれれ，バイナリから入らなかったからソースから入れようとしてるんじゃなかったっけ　???

というわけで，SBCL をコンパイルするために，CMUCL (SBCL は　CMUCL のブランチ．マルチプラットフォーム，UNICODE サポートなど，配布ライブラリの簡素化などの点で異なる方針を取っている)　をまずはインストール．

こっちは，以前　apt から普通に入ったはず．

…　なんか，CMUCL 自体は入ったみたいなんだけど，恐い感じのエラーが．

cmucl (19d-20061116-1) を設定しています ...
Installing Common Lisp Controller in CMU CL ...
Error in batch processing:

Error in function UNIX::SIGSEGV-HANDLER: Segmentation Violation at #x10044FB8.
FAILED

なんか　Common Lisp Controller とかがコケてる．

まぁ，cmucl　(lisp) コマンド自体は使えるみたいなので，とりあえず行ってみよう．

$　sh make.sh 'lisp -batch -noinit'

とかすると，すごい勢いでコンパイルが始まるので，しばし待つ．

待ってる間に　INSTALL ファイルを眺めてみると，とりあえずビルドが終わったら，

$ cd tests && sh run-tests.sh

でテストをして，後はバイナリ配布版と同じように

# sh install.sh

とかすれば良いみたい．デフォルトの　/usr/local 以外にインストールしたかったら，SBCL_HOME　を　INSTALL_ROOT/lib/sbcl とかに設定しておけば良いらしい．

いや〜，なんとなく　SBCL ってコンパクトなイメージがあったんだけど，よく考えれば　ANSI CL に　(ほぼ完全に．非商用で，完全準拠のコンパイラってあるのか　?)　準拠してるんだから，んなわけない．でかいです．

---

やっと終わった．実はもういっこコンパイル中に記事を書いてたんだけど，途中で　Firefox が落ちた…　orz

# clisp は 800 を超えるライブラリ関数やマクロのうち 600 以上は C で記述されていて，libsvm (Support Vector Machine) なんてものまであるのか…　とか．SBCL/CMUCL みたいに，ほぼ全てが　CL で書かれているものとは対照的．いろいろ個性があるのう．

# あと，libsigsegv なんてものを使って，スタックオーバーフロー検知ができるらしい．これは末尾再帰最適化が保証されない　（Commo Lisp の変数は，Sheme みたいな単なるプレースフォルダーとは限らない　(スペシャル変数)　場合があるから，必ず末尾再帰がループに変換できるとは限らない，みたいなことを，Shiro さんが　lingr かどっかで言っていたような　?　（うろおぼえ））)　CL ではありがたいような．そして，たぶん，コンディションシステムとかを使って，簡単に例外を通知したりハンドルしたりでるんだろうね．

//build started: Thu Dec 7 13:48:28 JST 2006
//build finished: Thu Dec 7 15:30:20 JST 2006

40 分か．まぁ，gcc とかを考えると，消費メモリ・タイムともに妥当なのかもしれない．というか，たぶん同規模の　C++ よりは速いと思う．むしろこんだけ安定して大きなコードをコンパイルできる　CL　の成熟度をなめていたというか．生粋の　CLer には常識なのかもしれませんが，けっこう衝撃的．
Common Lisp ってのは，本物のネイティブコンパイル言語なんだなぁとしみじみ．CMUCL ぐらいになると，数値計算では　Fortran や　C と同等かそれ以上のコードを吐くらしいし　(もちろん，スパコンメーカ純正のカリカリに気合いが入った最適化がかかる　Fortran コンパイラには勝てないでしょうが．プログラムの複雑さがある程度以上になったら，たぶん　CL　の方が速いだろうけど)．

とりあえず，テストとかを走らせている．なんかたまに　catch fatal error とかいう文字が見えて恐いんですけど…

---

エライ時間がかかったけど，無事に終わったようで何より．苦労して生んだぶん，バイナリに愛情が　（それは）無い)

Finished running tests.
Status:
Expected failure: debug.impure.lisp / (UNDEFINED-FUNCTION BUG-353)
Unexpected success: debug.impure.lisp / (THROW NO-SUCH-TAG)
Unexpected success: debug.impure.lisp / (BACKTRACE MISC)
Expected failure: external-format.impure.lisp / (CHARACTER-DECODE-LARGE
FORCE-END-OF-FILE)
ok
//apparent success (reached end of run-tests.sh normally)
Thu Dec 7 16:37:47 JST 2006

ボクはまぁ，普段は面倒だからテストとかはしない子なんだけど，さすがにコンパイラが違うブートストラップコンパイルとかは恐すぎるので．一応．

あとは sudo sh install.sh とかするだけ．無事にインストール完了したみたい．

今は，ふたたび　cells-gtk を解凍して，(load "load") している最中．

clisp と違って，特別な設定は要らないし，一から全てコンパイルしている感じなので，なかなか期待が持てそうな感じ．undefined alien とかが大量に出てて，嫌な予感がするけど…

お，終わったみたい．良かった良かった．

Done! Now try (test-gtk:gtk-demo) or if problems, (test-gtk:gtk-demo t)
T

しっかし，(test-gtk::gtk-demo) が　(やはり)　動かない…

ここの人と，まったく同じ症状みたいだから，Gtk のバージョンの問題とか，比較的一般的なトラブルなのかな　？
[beep-announce] mostly successful installation on SBCL / Linux

>> I downloaded the pre-built library from the cells-gtk site,
copied it to /usr/lib, and reran (test-gtk::gtk-demo) successfully.

とか書いてるんだけど，プリコンパイルライブラリって，どこにあるんだ　? サイトには

>> The patch also allows libcellsgtk.so to be located wherever it was built, rather than having to copy it to /usr/lib, etc.

とか書いていて，なんか無くなってる感じ．

---

なんか，やっぱり　CL も，GUI toolkit 回りは微妙だねぇ．
まぁ，Linux 限定とかならいくらでもあるんだけど．

wxCL とかもあるのか．でも，まだいろいろ微妙な感じ．これが成熟してきたら，いろいろ素晴らしい感じだけど　(こっちはむしろ，Win/Mac より)．

lambda-gtk とか　clg は，cffi ライブラリを別途インストールしないといけないみたいだしなぁ．面倒よのう．

やっぱり，今まで通り，gauche でコツコツポートしながら作っていくのが良いのかもしれない．Gtk の全てが必要なわけじゃないからね．

# CL の　FFI とかは，まだあんまりよくわかってないしねぇ

---

Windows の SBCL は，非常に簡単にインストールできる．

本家からたどれるここから sbcl-1.0-x86-windows-binary.msi とかを持ってきて，いつものようにダブルクリックするだけ．

しっかし，wxCL のインストールのしかたがわからない．

とりあえず，ダウンロードのところから wxcl-all-platform-1-3-0.tar.gz とか，tar.gz 拡張子のやつ (asdf が認識できるように) を持ってきて C 直下とかに置いて，SBCL を起動して

* (require 'asdf-install)
* (asdf-install:install "C:/wxcl-all-platform-1-3-0.tar.gz")

とかすると，それっぽい感じにはなるんだけど… なんか止まってしまって，それ以上先にいかない．ぬーん．なんか tar.exe が上手く動いていないような ???

ちなみに，Debian の apt みたいに，cliki.net にパッケージがあれば，(asdf-install:install 'package-name) みたいな感じで，自動でネットワークインストールできるんだって．素晴らしい．

ただ，wxCL が無いのよね… Windows で GUI を使いたい人ってのは，やっぱり Allegro か LispWorks みたいな商用のに行ってしまうのだろう．

# Mac だったら動くのかね ? 単に Windows の SBCL 1.0 は，experimental だから ?

---

なんか様々な諸問題により，行き詰まってきた感じが　（主に僕の中で）　するので，大きく路線変更を考えています．

とりあえず，shiki　を　Common Lisp でリライトしてみようかなと．せっかく　gauche　にも慣れてきたところなので，若干もったいないですが．やはりネイティブコンパイルしたいのと，全部　Lisp の世界で書きたくなってきたのです　(gauche-gtk は，Windows では動かないので，今までは手動でポートしつつ書いてたのです)．

ただし，標準の　CLX は使いたくない　(主に，ダサくて国際化とか面倒だから．あと，ネイティブな半面，ポータビリティが X 環境に限定される．できれば　Windows/Linux/BSD/Mac 全部で使えるようにしたい)　ので，まずは Gtk のバインディングを探すことに．

# 関係ないですけど，im を kinput2 から anthy-uim に変えたばかりなので，違和感がある．

まずは言語処理系．しかし，クロスプラットフォームな処理系は，いきなりかなり限定される．

完成度的には，Alleglo > CMUCL 的な感じなんだろうけど，片や商用，片や　UNIX　英語圏　(非　Unicode) 環境限定．

クロスプラットフォームで，Unicode な　CLisp は素晴らしいんだけど，バイトコード (?) 処理系なので，たぶんネイティブコンパイルできない．

というわけで，対応度と完成度に若干不安が残るものの，最近　1.0 がリリースされたばかりの SBCL に，自動的に決定してしまう．ある意味，迷いが無くてよい．

次に，Gtk bindings を探す．

CLiki the common lisp wiki GTK binding

なんか，clg が，

・　自動生成だからコンプリートだし，ベリーリスピッシュ　(全ての Gtk クラスが CL Standard Class のサブセットというデザイン)　だからヴェリーナイセストだぜ　★　…でも，いまのところ　CMUCL/SBCL でしか動かないよ．

らしい．ただ，β版か…

λgtk とかもある見たいだけど，なんか　Mac/Linux 限定みたいな感じ．cl-gtk とか　lgtk は致命的に古い (updated: 2004) みたい (いつのまにか，debian のパッケージからも無くなってるな…)．

なんか，CMUCL と SBCL が強いな．単に普及度なのか，それとも移植がしやすいなんらかの特徴があるのか．

結局，cells-gtk ってのが，非常によさげ．一応　Linux/Windows で動くみたい．ただ，Win 版は　clisp 限定みたい．clisp は　clisp で，m.hiroi さんとこに解説があったりとかいうメリットもあるんだけど．

というか，debian に，CMUCL/SBCL の　gtk　バインディングはパッケージングされてないみたい．インストールから始めないと．

---

うは，インストールすらよくわかんね．しかも　cells-gtk は，微妙に使えないウィジットがあるみたい．debian の　clg パッケージは，なんか消えてるし…

というか，SBCL すら入らないや．

# apt-get install sbcl
パッケージリストを読み込んでいます... 完了
依存関係ツリーを作成しています... 完了
提案パッケージ:
sbcl-doc sbcl-source slime
．．．
fatal error encountered in SBCL pid 1419(tid 16384):
This version of SBCL is compiled with threading support, but your kernel
is too old to support this. Please use a more recent kernel or
a version of SBCL without threading support.

これはきっと，さっさと　kernel を　2.6.x に上げなさいという天からのお告げ　(面倒で未だに　2.4.27 とか)．

なんか，CL では，ASDF っていうパッケージシステムでライブラリをインストールするのが一般的らしい．わかればディモールト楽なんだろうけど，門外漢にはさっぱりですな．

まだ SBCL パッケージのバージョンが　0.9.16 とかだし，1.0 への対応もよくわからないので，しばらし (しばし　+ しばらく) 様子見かね　?

ところで，これはなんか素晴らしい感じ．いや，eclipse とか使ったことないんだけど．

EclipseでLisp - Cusp登場

SLIME on SBCL in Eclipse IDE　という構成らしい．SLIME が入っているので，CLtL2 とかハイパースペックとかを簡単に引いたりできるのはもちろん，Eclipse の補完機能とかも使えるらしい．

Windows とかだと，Eclipse の方が emacs よりもインストールが楽そうだしね．

あと，やっぱり多国語対応は　gauche の方が優れているみたい．例えば　CL には，文字コードの自動判定とかは，あんまり無い感じ　(開発のメインが英語圏なんだからあたりまえだけど)．

う〜ん，いろいろ難しいのう．

---