Lisp準拠のネイティブコードコンパイラです。2007年以前はOpenMCLを名乗っていたため、古い情報ではOpenMCLと呼ばれていることが多いです。OSへのサポートが強みです。Associates社の技術者を中心に開発しているため、同社の有料サポートがあります。Lispの開発を始める。Lispに改名してFranzと共同で販売。Digitoolが買収。ByersがLinuxへの移植のためにforkする。Byersのforkのオープンソース化を認め、OpenMCLプロジェクト開始。DigitoolがMCLをオープンソース化。CLから自分の環境に合ったもの(linuxx86またはlinuxarm.tar.gz)をダウンロードします。ftp://ftp.clozure.com/pub/release/1.11/ccl-1.11-linuxx86.tar.gz好きな所に展開します。ccl環境変数を設定します。CLのディレクトリに設定します。起動スクリプトをパスの通った所に置きます。CLのディレクトリの中のscriptsディレクトリにあるcclとccl64です。32ビット環境ならccl、64ビット環境ならccl64を使ってください。32ビット環境ならccl64の代わりにccl起動スクリプトが実行できるようになっているか確認します。実行フラグが立っていなければ、パーミッションを変更します。~/opt/ccl/scripts/ccl64終わりです。起動するか確認してください。CLからWindows向けのZIPファイルをダウンロードし、好きな場所に展開します。次に、環境変数を設定します。CLのディレクトリに設定し、PATHにも同じディレクトリを追加します。起動するときにはwx86clを実行してください。(WindowsX8632)!?もし上の説明で分からなければ、Lispboxを使ってください。インストーラで全部自動的に設定してくれます。ダウンロードできます。10.6以降を必要とします。10.5でもまだ動作します。CL.appがクラッシュしたとき、AltConsoleアプリケーションが自動的に起動しないかもしれません。AltConsoleのDockアイコンをクリックすれば、起動して正常に動作するでしょう。8.1でビルドされています。6.xや7.xを使っているなら、Lispカーネルを自分のシステムで再コンパイルすれば、問題なく処理系を動かせるはずです。freebsdx8664。5.0でビルドされています。十分に枯れていますので、Lispカーネルバイナリの実行にあたって、ほとんどの人は問題が起こることはないでしょう。存在しないバージョンのglibcに対してリンクしているというエラーによって、提供されているバイナリが実行できない場合、Lispカーネルを自分のシステムでコンパイルすれば、問題なくLispを動作させることができるでしょう。makeLispカーネルをビルドするためにはm4プログラムがインストールされている必要があることに注意してください。ARMARMv7プロセッサが必要です。これは、残念なことにいくつかの興味深い小さなARMベースのシステムを排除してしまいます。Piで、ARMv6アーキテクチャチップ(ARM1176JZFSコア)を使っていますが、CCLは動作しないでしょう。様々なARMプロセッサの識別に使われる命名法は極めてややこしく、http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores(訳注:日本語ではARMアーキテクチャの項にリストがあります)が助けになるかもしれません。ticket:865(それとできる限り他のものも)メモ一般的な変更シンボル:ccl-1.8が*features*に入りました。付属のASDFのバージョンが2.20になりました。標準のtimeマクロによる出力の書式が、数値をより良く整形するように変更されました。関数directoryへの:directories引数がデフォルトではtになりました。出力がデフォルトではファイルとディレクトリの両方を含むということを意味します。:follow-linksがtのとき(デフォルトでのように)、directoryはディレクトリへのシンボリックリンクを処理するようになりました。read-line関数がWindowsでも行をより速く読むようになりました。UNIXベースのシステムで、user-homedir-pathnameを初期化するために、HOME環境変数がデフォルトで使われるようになりました。無効にするためにはccl:*trust-paths-from-user-environment*をnilに設定します。コードカバレッジの結果がどのように提示されるかについて、いくつかの改善が加えられました。コンパイラARM版に対して多数のバグフィクスと性能の改善が行われました。x86バックエンドは不要なスタックへの転送を減らすように努めます。x86とARMにおいて、少数の固定された引数を伴う自身への末尾呼び出し(訳注:末尾再帰)がいくらか速くなりました。特定のケースで、特定の型とキーの範囲に対して、caseと関連する構文は、定数時間で実行できるジャンプテーブルにコンパイルされるでしょう。GCとランタイムデッドロックを避けるため、GCはすべてのガベージコレクションが可能なポインタの後始末をスレッドが再開するまで延期します。これによる小さな副作用は、特定の到達不能な他のオブジェクトを、次回のガベージコレクションまでGCが覚えておかなければならないことで、いくらかの外部のリソースが、不要になるまでよりも少し長い間拘束されるかもしれません。Xで、デフォルトのヒープイメージが見付からない場合、アプリケーションバンドルの中にいると仮定して、".../Resources/ccl"を探します。互換性のない小さな変更:Lispカーネルは、イメージの名前としての単独のコマンドライン引数を取り扱わなくなりました。これによって、いくつかのケースで、単純な「スタンドアローンバイナリ」のためにユーザがシェルスクリプトのラッパーを書かなくても良くなります。逆アセンブル逆アセンブラの出力の書式が、インストラクションの後ろにあるコメントの中で、インストラクションのアドレスを表示するように変更されました。逆アセンブラは、caseのジャンプテーブルを認識し、表示します。この例を見るためには、以下のつまらない関数を逆アセンブルしてください。'ten)))CocoaベースのIDE変数ccl:@はインスペクタによってインスペクトされるオブジェクトを設定されますが、これをリスナーの中で利用できます。"ccl-application"のような名前が"CCLApplication"に変換されるように、"CCL"が特別なObjective-Cの単語になりました。このプリフィクスはCCLが私的に使うために予約されています。関数execute-in-guiは、別のスレッドの同期のメソッドを使うために書き直されました。新しくエクスポートされたシンボル以下の新しいシンボルがCCLパッケージからエクスポートされるようになりました。