LISPUSER

[GC threshold exceeded with 10,411,328 bytes in use.  Commencing GC.]
[GC completed with 990,320 bytes retained and 9,421,008 bytes freed.]
[GC will next occur when at least 8,990,320 bytes are in use.]

A: 初期化ファイル ~/.cmucl-init に (setq ext:*gc-verbose* nil) という行 を通過してください．ガベージコレクターのチューニングに関してより詳細に 知りたければ CMUCL User's Manual を見てください．

A: これは，あなたがトップレベルで未定義の変数に対して SETQ を使用した場 合に発生します．このような状況での CMUCL のデフォルト動作は，スペシャル 変数を宣言します．（その宣言はレキシカルに束縛変数をダイナミック束縛変 数に変換します）

(setq foo 42)

この foo が（DEFVAR や DEFPARAMETER などで）事前に宣言されていなかった 場合，CMUCL は暗黙に

(defvar foo)

このような宣言を自動的に行います．これはユーザーの利便のために行なわれ るものですが，もしこの動作を予期していないならば奇妙な動作が引き起こさ れる可能性があります．たとえば，`*asterisks*` のようにスペシャル変数の 名前をアスタリスクで囲むような記法を導入している場合などは混乱の元とな ります．これが，CMUCL が警告メッセージを出力する理由です．また，もうひ とつ注意しておく必要がありますが，SPECIAL 宣言を元に戻す（レキシカルな 束縛のみを許す変数に戻す）方法は存在しません．

変数 `ext:*top-level-auto-declare*` の値がこの動作の制御します．

A: CMUCL は実行形式としての配布をサポートしていません．御不満があるので したら，他の大部分のプログラミング言語の実装について指摘しておきます: 例えば Sun の Java 実装はクラスファイルのバンドルを要求します．

CMUCL による Common Lisp アプリケーション配布の標準的な方法は，アプリケー ションコードを全て含んだイメージをダンプし（詳細は CMUCL User's Manual を参照してください），そしてこのイメージと，Lisp ランタイムと，ランタイ ムからイメージを起動するシェルスクリプトを含んだ tarball を配布する事で す（サンプルとして CMUCL 配布物に含まれている sample-wrapper を見てくだ さい）．また，後続のヒントには Lisp ファイルを実行形式にする方法があり ますのでそちらも御覧ください．

A: CMUCL のネイティブコードコンパイラは Python と呼ばれています．この名 前は他のスクプト言語が存在しはじめるよりも前からそうでした．

A: 問題の詳細を記述したメールを cmucl-help か cmucl-impl メーリングリス トのどちらか一方に送ってください（これらのリストの詳細はサポートページ を参照してください）．お使いの CMUCL のバージョン（起動時の表示など）， プラットフォーム， features 変数の値などは必ず含める必要があります． また，問題が個人的なもしくはサイト固有の初期化ファイルによるものでない 事を確認してください．また問題を再現する最小の構成を探すよう努力してく ださい．

A: The short answer is that this really depends on your needs. Most free implementations are fairly easy to install, and you should be able to obtain evaluation copies of the commercial implementations, so it isn't difficult to make a choice yourself.

A: 簡潔に答えるなら，

A longer answer is that compared with the various commercial Common Lisp implementations (see lisp.org for a list), CMUCL is free: you can use it for zero upfront cost, and it has a very liberal license that imposes few restrictions on its use and redistribution. You also have access to the source code if you wish to customize the implementation to your requirements. However, you can't get a support contract from the vendor (though you could probably find experienced CMUCL developers prepared to freelance – contact the cmucl-imp mailing list), and CMUCL is missing certain features present in the commercial implementations (portability to Microsoft Windows platforms, graphical browsers, GUI widgets, add-on libraries …).

Compared with CLISP, CMUCL runs on fewer platforms and has significantly higher memory usage. CLISP has better internationalization support, in particular support for UNICODE. Since CMUCL compiles to native code, it is an order of magnitude faster on most applications than CLISP's bytecode execution model, and generally provides more useful debugging output. However, the mathematical primitives in CLISP are very fast, in particular its bignum operations. CLISP also provides floats of unlimited precision, while CMUCL is limited to IEEE-754 single-float and double-float (and extended-precision on certain platforms). CMUCL has a more powerful foreign function interface than CLISP, and supports multiprocessing on x86 platforms.

Compared with SBCL (a fork from the CMUCL implementation), CMUCL a different set of features (it includes a Motif interface, but does not have SBCL's native threads on Linux/x86 platforms, nor Unicode support). CMUCL has a faster compiler, but compiled code runs at a similar speed to SBCL-generated code. SBCL is closer to the ANSI CL specification in some respects, and generally emits more warnings about ANSI-compliance. SBCL runs on a larger number of platforms than CMUCL, and in general is more actively developed than CMUCL.

A: Many people like to use SLIME in Emacs.

A: Short answer: fairly difficult. There are two aspects to porting: writing a backend for the new the CPU architecture, and handling the runtime's interaction with the operating system.

Writing a compiler backend to target a new CPU involves deciding on a register allocation policy, and writing assembly definitions for the CMUCL virtual machine operations (VOPs). There are also a number of utility routines to write in assembly, and some CPU-specific constants (number of registers, how FPU exceptions are reported to user land, how wide floating point registers are) to define.

Targeting a new operating system involves getting the runtime to compile. This means stuff like deciding on a memory map, implementing memory management routines. The trickiest bit is probably signal handling, and extracting the address of the faulting instruction from a ucontext_t.

A: You may have done something like

USER> (setq *print-array* nil)
USER> (defvar *big* (make-array 42000000 :element-type 'double-float))
;; use big, then get rid of it
USER> (setq *big* nil)
USER> (gc :full t)    ;; :full only with generational collector

You no longer have any references to the array, so were expecting it to be garbage collected. However, according to (ROOM) it wasn't. The reason is that the read-eval-print-loop maintains variables called `*`, `**` and `***`, that reference the values of the last three forms evaluated, and the array is still accessible from these. Try evaluating a few other forms (like 1), then call the garbage collector again.

(This question isn't specific to CMUCL; you'll observe the same in other implementations.)

A: This is the generational conservative garbage collector telling you that you have exhausted the available dynamic space (the memory zone that is used for normal lisp objects). You can increase the size of the dynamic space reserved on startup by using the -dynamic-space-size commandline option (see the CMUCL User's Manual for details). You can determine the amount of dynamic space currently available as follows:

USER> (alien:def-alien-variable ("dynamic_space_size" dynamic-space-size) c-call::int)
#<ALIEN::HEAP-ALIEN-INFO
  (SYSTEM:FOREIGN-SYMBOL-ADDRESS '"dynamic_space_size") (ALIEN:SIGNED 32)>
USER> dynamic-space-size
536870912

A: This means that CMUCL has received a signal indicating a segmentation violation from the operating system, at an unexpected address (it already uses SIGSEGV for normal operation of the garbage collector). This can be due to:

you have linked with some alien code (such as a shared library) which is generating segmentation violations. This can be due to a bug in the alien code, or to you passing it invalid pointers. you have lied to the compiler (written incorrect type declarations), and compiled your code in unsafe mode (with the speed optimization quality higher than the safety quality). For example, you may have declared that a variable was an array, and actually passed a list to the function. Make sure that you compile and run your code in safe mode before trying to increase its speed. you may have encountered an internal bug in CMUCL. It's quite unlikely that a bug should manifest itself in this way, though, so please check the first two possibilities before reporting a bug.

A: Try the #lisp channel on the freenode network. A number of CMUCL users and developers (as well as SBCL creatures) can occasionally be found wasting time there.

A: You may encounter this problem when porting code written for CMUCL to another Common Lisp implementation – such as LispWorks or OpenMCL – which is more conservative than CMUCL in propagating declarations to the evaluation environment. For instance, consider the compilation of a file containing the following code:

(defconstant +foo+ #\a)
(defun foo () #.(char-code +foo+))

This code will compile in CMUCL, but some other implementations will complain that the symbol foo is not bound when compiling the function foo. CMUCL propagates the compile-time effect of the DEFCONSTANT form to what CLtS calls the evaluation environment, so that it becomes available when compiling the remainder of the file. Certain other implementations are stricter in not leaking information in this way, and require you to write the above code as

(eval-when (:compile-toplevel :load-toplevel)
  (defconstant +foo+ #\a))
(defun foo () #.(char-code +foo+))

This code will also work in CMUCL. See Section 3.2.3.1 Processing of Top Level Forms of CLtS for more details (the specification is somewhat vague about some of these issues, which explains why there is considerable variation in behaviour from one implementation to another).

A: This error message occurs sometimes when you try to trace functions on the x86 ports of CMUCL. A simple workaround is to use

USERL> (trace my-function :encapsulate t)

This causes a different mechanism (which is implemented on x86) to be used for the breakpoints that are used by tracing facility.

A: Hopefully the message is fairly clear. The problem is that due to implementation choices, CMUCL reserves a large address space when it starts up, instead of allocating memory on demand, as do most applications. In its default configuration, the linux kernel may refuse to reserve amounts of memory which are far greater than the amout of available RAM and swap (this is called overcommitting, since the kernel commits itself to satisfy more memory than is actually available). You can either increase the amount of swap available (see the mkswap command), or change the kernel's policy using (as root) the command quoted above.

The Debian-packaged CMUCL includes a -lazy commandline option which reserves memory incrementally, and which should also solve this problem. [2003-01-03: the -lazy option has been disabled in recent Debian-packaged CMUCL binaries, following problems.]