ReleaseNotes/1.9 -- Clozure CLの内容を日本語訳したものです。内容の正しさは保証しません。

サポートされるプラットフォーム

Clozure CL 1.9は以下のプラットフォームで動作します。

• Mac OS X 10.5以降（x86、x86-64）
• Linux（x86、x86-64、ppc32、ppc64、armv7l/armv6）
• FreeBSD 6.x以降（x86、x86-64）
• Solaris（x86、x86-64）
• Microsoft Windows XP以降（x86、x86-64）

Subversionを通してClozure CLを手に入れることをお勧めします。例えば、x86で動作するMac OS X向けのCCLを手に入れるためには、シェルプロンプトから以下のコマンドを実行します。

$ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.9/darwinx86/ccl

他のプラットフォームでは、darwinx86をlinuxx86、freebsdx86、solarisx86、windows、linuxppc、linuxarmのいずれかに変更してください。

すべてのバージョンに32ビットと64ビットのバイナリの両方が入っています。（ARMを除きます。ARMは32ビットのみです。今のところは……）

CCLではSubversion 1.5で導入された機能に依存した使い方をしています。多くのプラットフォーム向けのSubverisonクライアントが http://subversion.apache.org/packages.html で入手できるようになっています。

より詳しい情報については、SystemRequirementsを見てください。

バグの報告

既存のバグ報告を見たり新しく報告したりするには、 http://trac.clozure.com/ccl のTracインスタンスを使ってください。

プラットフォームごとの注意点

Mac OS X

CocoaベースのIDEはMac OS X 10.6以降を必要とします。コマンドラインのLispはMac OS X 10.5でもまだ実行できます。

Mac OS X 10.7以降では、スタンドアローンのClozure CL.appがクラッシュしたときでも、AltConsoleアプリケーションが自動的に起動しないかもしれません。DockのAltConsoleのアイコンをクリックすることで起動し、普通に動作するはずです。

CCL 1.9は、OS X 10.8（Mountain Lion）のヘッダをベースにしたインターフェイスと一緒に配布されます。

GDBデバッガのAppleバージョンではCCL 1.9以降のデバッグに使えません。実際にこのレベルでCCLをデバッグする必要が出た場合、AppleのGDBが少しだけ変更されたバージョンが http://ccl.clozure.com/FTP/gdb-768-limited-mach-exceptions.tar.gz （OS X 10.5用）と http://ccl.clozure.com/FTP/gdb-1820-limited-mach-exceptions.tar.gz （OS X 10.6〜10.8用）にあります。繰り返しますが、これはCCLやCCLベースのアプリケーションをGDBでデバッグする必要のあるユーザだけに関わりがあることです。

FreeBSD

バイナリはFreeBSD 6.3システムでビルドされています。FreeBSDのそれ以降のバージョンで実行させる場合、Lispカーネルをあなた自身のシステムで再コンパイルすることで、トラブルが起こることなくLispを実行できるはずです。

$ cd ccl/lisp-kernel/freebsdx8632   # もしくはfreebsdx8664。必要に応じて
$ make

Linux x86

Linux/x86バイナリはDebian 5.0システムでビルドされています。十分に古いので、Lispカーネルバイナリを実行するにあたって、ほとんどの人が問題には遭遇しないはずです。ですが、もし提供されているバイナリが実行に失敗し、glibcの存在しないバージョンに対してリンクされているというエラーが出ている場合、Lispカーネルをあなた自身のシステムで再コンパイルすることで、それ以上トラブルが起こることなくLispを実行できるはずです。

$ cd ccl/lisp-kernel/linux8632  # もしくはlinux8664
$ make

Lispカーネルをビルドするためにm4プログラムがインストールされている必要があることに注意してください。

Linux ARM

ARMv6かARMv7プロセッサが必要です。様々なARMプロセッサの識別に使われる命名法は極めてややこしく、 http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores （訳注：日本語ではARMアーキテクチャの項にリストがあります）が助けになるかもしれません。

ARM Linuxの世界では異なるC関数の呼び出し規約に移行しているところですが、この変更は、どのように浮動小数点数の引数と結果が処理されるかに関係してきます。新しいディストリビューションは（一般的には）新しい"hard float" ABIを使う傾向があり、古いディストリビューションでは伝統的な"soft float" ABIを使っています。一部のディストリビューションでは同時に両方の規約をサポートします。

CCLが利用している規約は、Lispカーネルをビルドするのに使われるオプションに依存します。カーネルのビルドプロセスはccl/lisp-kernel/linuxarm/float_abi.mkファイルで指定されているオプションを使います。配布されている状態では、このファイルはFLOAT_ABIをsoftfpと定義して（そして、FLOAT_ABIをhardとした定義はコメントアウトされて）います。"hard-float" ABIを利用するLispカーネルをビルドするには、

1. cd ccl/lisp-kernel/linuxarm
2. (edit float_abi.mk so that FLOAT_ABI is defined as "hard".)
3. make clean
4. make

としてください。

修正されたチケット

ticket:869 ticket:1012 ticket:989 ticket:933 ticket:881 ticket:1055 ticket:1050 ticket:1054 ticket:1049 ticket:1053 ticket:1052 ticket:1046 ticket:1045 ticket:1042 ticket:1041 ticket:1040 ticket:1038 ticket:1036 ticket:1037 ticket:682 ticket:1035 ticket:1033 ticket:933 ticket:1031 ticket:1030 ticket:1015 ticket:1027 ticket:1018 ticket:975 ticket:1011 ticket:1013 ticket:968 ticket:1005 ticket:1007 ticket:1000 ticket:996 ticket:992 ticket:985 ticket:980 ticket:981 ticket:926 ticket:977 ticket:976 ticket:858 など

多くの数学関数のバグが修正されました。David Findlayのおかげです。

注記

ロード時のOPTIMIZE宣言のエクステントの制限

公開されて利用できる多くのCommon Lispのコードが（そしておそらく多くのプロプライエタリなCLコードも同様に）

(declaim (optimize {some set of OPTIMIZE settings))

というイディオムを使っています。これは

(eval-when (:compile-toplevel :load-toplevel :execute)
  (proclaim '(optimize {some set of OPTIMIZE settings}))) ; :COMPILE-TOPLEVELではコンパイル時の環境を操作して良い

のような何かになり、加えて、例えばDECLAIMフォームがCOMPILE-FILEによって処理されるとき、コンパイル時と同じようにロード時にも効果を持つと定義されています。OPTIMIZE宣言のロード時の効果は明確に規定されていますが、そのようにされることはほとんどなく、LOADから戻って以降は効果が持続しないよう、多くの処理系がエクステントを制限しています。（少なくとも、そのように動くある処理系が、その動作はANSI CLに準拠していないと自身のドキュメントに書いています）

それがユーザのためになるかははっきりしませんし、今までそうあったように、人々は(DECLAIM (OPTIMIZE ...))イディオムの（誤った）使用について寛容にも見えますが、CCLは、この点でANSI CLに準拠しようとしている唯一の処理系かもしれません。CCL 1.9では、LOADが呼ばれたときにCCL:*LOAD-PRESERVES-OPTIMIZATION-SETTINGS*変数が真だった場合、最適化の設定に対するロード時のどんな変更も、LOADから戻ったあとには残りません。

CCL:*LOAD-PRESERVES-OPTIMIZATION-SETTINGS*の既定値はNILです。定期的に多数のサードパーティのコードをコンパイルしたり、グローバルな最適化の設定をするためのコードをロードする行為を好まない人は、初期化ファイルでこの変数をTに設定したくなるかもしれません。

文字エンコーディングとデコーディングの検出の問題

例えば入力ストリームからオクテットを文字にデコードするとき、オクテット列がストリームの文字エンコーディングで有効な文字を表現できなかった場合、CCLは伝統的に#\Replacement_Characterを生成してきました。同様に、与えられたエンコーディングで表現できない文字をエンコードしようとするとき、#\Replacement_Characterか#\^Z（#\SUB）が代わりに生成されます。この場合、関係する情報の損失があるため、このような問題が起きたところでエラーを通知するのも悪くない（多分少しだけ多くコストがかかりますが）でしょう。（その損失あるいはその情報が重要かどうかは、READ-CHARのようなものの支払うコストより上のレベルの判断です）

CCL 1.9では、関心を持っている、より高いレベルのコードがこういった状況を検出するのを楽にするため、この一種の文字の置換がまさに起ころうとするところで、CCL:DECODING-PROBLEM（あるいはCCL:ENCODING-PROBLEM）型のコンディションが通知されます。加えて、(CCL:WITH-DECODING-PROBLEMS-AS-ERRORS &body body)と(CCL:WITH-ENCODING-PROBLEMS-AS-ERRORS &body body)マクロは、コードの本体部分を実行し、実行中に遭遇したDECODING-PROBLEM（ENCODING-PROBLEM）をERRORを通して通知します。

NO-APPLICABLE-METHODによって通知されるコンディション型

NO-APPLICABLE-METHODのデフォルトメソッドがCCL:NO-APPLICABLE-METHOD-EXISTS型のエラーを通知するようになりました。以前のバージョンではSIMPLE-ERRORを通知していました。

CCL:DEFAULT-FILE-CHARACTER-ENCODINGとCCL:TERMINAL-CHARACTER-ENCODING-NAMEの新しい既定値

これらの変数が:UTF-8を既定値にするようになりました。CCLの以前のバージョンでは、NILと:ISO-8859-1を既定値としていました。

高分解能クロックへのアクセス

CCL:CURRENT-TIME-IN-NANOSECONDSはある任意の時点（おそらくシステムブート）から経過したナノ秒を返します。

文字エンコーディング名と別名の操作とアクセス

新しい関数です。

• (CCL:LIST-CHARACTER-ENCODINGS)は定義されているすべての文字エンコーディングの「正式な」名前（キーワード）のリストを返します。
• (CCL:LIST-CHARACTER-ENCODINGS :INCLUDE-ALIASES T)は定義されているすべての文字エンコーディングの正式な名前と別名のリストを返します。
• (CCL:DEFINE-CHARACTER-ENCODING-ALIAS alias existing)はalias（キーワード）が既存の文字エンコーディングexisting（CHARACTER-ENCODINGオブジェクトかそれを名付けているキーワード）の別名として認識されるようにします。
• (CCL:REMOVE-CHARACTER-ENCODING-ALIAS alias)はalias（キーワード）がどんな文字エンコーディングの別名としても認識されないようにします。

SIGNAL-EXTERNAL-PROCESSと外部プロセスの終了

CCL:SIGNAL-EXTERNAL-PROCESS関数が:ERROR-IF-EXITEDキーワード引数を取るようになりました。この引数の値がNILで、すでにプロセスが終了しているという理由で送信が失敗した場合、CCL:SIGNAL-EXTERNAL-PROCESSは黙ってNILを返します。引数の既定値はTです。

ファイルオプション行でファイルのEXTERNAL-FORMATを決定できる

テキストファイルの最初の行がEmacsスタイルのファイルオプション行（;;; -*- .... -*-）を含んでいて、ファイルが入力のために:EXTERNAL-FORMATが:INFERREDで開かれている場合、（存在していれば）「coding」オプションの値がファイルのCHARACTER-ENCODINGを決定するために使われます。（:EXTERNAL-FORMAT :INFERREDはファイルの改行についても、以前持っていたものであるとして決定しようとします）:EXTERNAL-FORMAT :DEFAULTで呼ばれたとき、LOADとCOMPILE-FILEの両方が OPENを:EXTERNAL-FORMAT引数を:INFERREDにして呼び出すように手配します。

ARRAY-TOTAL-SIZE-LIMITを超えたときの（願わくば）より明確なエラーメッセージ

ARRAY-TOTAL-SIZE-LIMITは、32ビットバージョンのCCLでは(ASH 1 24)で、64ビットバージョンでは(ASH 1 56)です。この制限は、CLの配列の中にある要素の総数と、他の種類の「ベクタ状」のオブジェクト（BIGNUMや特定のプラットフォームでのFUNCTIONなど）の総サイズの両方に影響します。ベクタ状のオブジェクトを割り当てるようなとても低レベルなコードが、要素の数が制限に到達したり超えたりする何かを割り当てるよう求められているところに出会ったとき、これまでは、引数のひとつが (UNSIGNED-BYTE [24|56])でないと訴えるTYPE-ERRORが通知されてきました。技術的には正しいのですが、ユーザはこのエラーを分かりにくいと感じていました。（特に、明示的に割り当てを要求していないかもしれないので）この状況で（ERRORを通して）特殊なSTORAGE-CONDITIONを通知し、そのコンディションに対する報告用の関数が、割り当てられているオブジェクトの種類と、なぜ割り当てが失敗したのかを説明しようとするようになりました。

RUN-PROGRAMでの引数の文字列のエンコーディング

UNIXシステムでは、OSレベルのプロセスは、引数の数と、終端が#\NULのC文字列のベクタを、引数として受け取ります。Cランタイムシステムは、これらの引数をアプリケーションのmain()関数（慣習的にargcとargvと名付けられています）に渡すように手配します。RUN-PROGRAMは、自身の:EXTERNAL-FORMAT引数で指定されたエンコーディングに、（argvの中の）文字列をエンコードするようになりました。

新しくエクスポートされたシンボル

以下の新しいシンボルがCCLパッケージからエクスポートされるようになりました。

• *load-preserves-optimization-settings*
• no-applicable-method-exists
• encoding-problem
• decoding-problem
• with-encoding-problems-as-errors
• with-decoding-problems-as-errors
• current-time-in-nanoseconds
• unsetenv
• list-character-encodings
• define-character-encoding-alias
• remove-character-encoding-alias