Version 11 (modified by gb, 14 months ago) (diff)


Release notes for Clozure CL 1.9

Supported Platforms

Clozure CL 1.9 runs on the following platforms:

  • Mac OS X 10.5 and later (x86, x86-64)
  • Linux (x86, x86-64, ppc32, ppc64, armv7l/armv6)
  • FreeBSD 6.x and later (x86, x86-64)
  • Solaris (x86, x86-64)
  • Microsoft Windows XP and later (x86, x86-64)

The preferred way to get Clozure CL is via Subversion. For example to get CCL for Mac OS X running on x86, one would run the following command from a shell prompt:

$ svn co

For other platforms, change the darwinx86 to one of linuxx86, freebsdx86, solarisx86, windows, linuxppc, or linuxarm.

Both 32 bit and 64 bit binaries are included with all versions (except for ARM, which is 32 bit only. For now ...)

CCL's use of subversion depends on features introduced in subversion 1.5. Subversion clients for many platforms are available at

For more details, please see SystemRequirements.

Reporting Bugs

Please use the Trac instance at to review existing bug reports and to submit new ones.

Platform Notes

Mac OS X

The Cocoa-based IDE requires Mac OS X 10.6 or later. The command-line lisp still runs on Mac OS X 10.5.

On Mac OS X 10.7 and later, the AltConsole application may not automatically activate when the standalone Clozure crashes. Clicking on the AltConsole icon in the dock will activate it and it should then behave normally.

CCL 1.9 is distributed with interfaces based on the OSX 10.8 (Mountain Lion) headers.

Apple's version of the GDB debugger can't be used to debug CCL 1.9 or later. In the event that you ever actually need to debug CCL at this level, slightly modified versions of Apple's GDB are available at (for OSX 10.5) and (for OSX 10-6-10.8). Again, this is only relevant to users who need to debug CCL or CCL-based applications with GDB.


The binaries are built on a FreeBSD 6.3 system. If you are running a later version of FreeBSD, you should be able recompile the lisp kernel on your own system and run the lisp without any further trouble:

$ cd ccl/lisp-kernel/freebsdx8632   # or freebsdx8664, as appropriate
$ make

Linux x86

The Linux/x86 binaries are built on a Debian 5.0 system. This is old enough that most people should not encounter any difficulty with running the lisp kernel binary. If, however, the provided binary fails to run, complaining that it is linked against an unavailable version of glibc, then you should be able to compile the lisp kernel on your own system and run the lisp without any further trouble:

$ cd ccl/lisp-kernel/linux8632  # or linux8664
$ make

Note that the m4 program needs to be installed in order to build the lisp kernel.

Linux ARM

An ARMv6 or ARMv7 processor is required. The nomenclature used to identify various ARM processors is extremely confusing. may be of some help.

The ARM Linux world has been transitioning between different sets of C function calling conventions; these changes have to do with how floating-point arguments and results are processed. Newer distributions (generally) tend to use the new "hard float" ABI; older distributions use the traditional "soft float" ABI, and some distributions can support both sets of conventions simultaneously.

The conventions that CCL uses depend on the options used to build the lisp kernel; the kernel build process will use the option specified in the file "ccl/lisp-kernel/linuxarm/". As distributed, this file defines FLOAT_ABI as "softfp" (and a definition of FLOAT_ABI as "hard" is commented out.) To build a lisp kernel that uses the "hard-float" ABI:

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

Fixed tickets

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 and others

Many math function bugs fixed, thanks to David Findlay.


The FASL version changed: FASL file produced with earlier versions of CCL won't work with this version and vice versa.

Limiting the extent of load-time OPTIMIZE proclamations

A lot of publicly available Common Lisp code (and likely a lot of proprietary CL code as well) uses the idiom:

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

which is defined to be something like:

(eval-when (:compile-toplevel :load-toplevel :execute)
  (proclaim '(optimize {some set of OPTIMIZE settings}))) ; may manipulate the compilation environment in the :COMPILE-TOPLEVEL case.

e.g., to have load-time as well as compile-time effects when the DECLAIM form is processed by COMPILE-FILE. Load-time effects of OPTIMIZE proclamations are well-defined but rarely intended, and many implementations limit the extent of those effects so that they don't persist after LOAD returns. (At least one implementation that does so notes in its documentation that that behavior is not compliant with ANSI CL.)

CCL may be the only implementation that tries to be ANSI CL-compliant here; it's not clear that that's been doing users a lot of good, and people seem to be as casual about (mis-)use of the (DECLAIM (OPTIMIZE ...)) idiom as they've ever been. In CCL 1.9, if the variable CCL:*LOAD-PRESERVES-OPTIMIZATION-SETTINGS* is true when LOAD is called, then any load-time changes to optimization settings will not persist after the call to LOAD returns.

The default value of CCL:*LOAD-PRESERVES-OPTIMIZATION-SETTINGS* is NIL. People who regularly compile a lot of third-party code and who don't like the act of loading that code to affect global optimization settings may want to set this variable to T in their init files. The default value of this variable may change in future releases.

Detecting character encoding/decoding problems

When decoding octets into characters from (e.g.) and input stream, CCL has traditionally generated a #\Replacement_Character if a sequence of octets doesn't represent a valid character in the stream's character-encoding. Similarly, when trying to encode a character that can't be represented in a given encoding, a #\Replacement_character or a #\^Z (#\SUB) is generated instead. It'd also be reasonable (maybe a bit less so) to signal an error in the case where a problem like this occurs, since there's going to be some loss of information involved. (Whether that loss or that information is significant or not is a decision that's above the pay grade of things like READ-CHAR.

In CCL 1.9, a condition of type CCL:DECODING-PROBLEM (or CCL:ENCODING-PROBLEM) is signaled in cases where this sort of character replacement is about to occur, making it easier for interested higher-level code to detect these situations. In addition, the macros (CCL:WITH-DECODING-PROBLEMS-AS-ERRORS &body body) and (CCL:WITH-ENCODING-PROBLEMS-AS-ERRORS &body body) execute a body of code and signal any DECODING-PROBLEMs (ENCODING-PROBLEMs) encountered during its execution via ERROR.

Condition type signaled by NO-APPLICABLE-METHOD

The default method on NO-APPLICABLE-METHOD now signals an error of type CCL:NO-APPLICABLE-METHOD-EXISTS; in previous versions, it signaled a SIMPLE-ERROR.


These variables now default to :UTF-8; in previous versions of CCL, they defaulted to NIL/:ISO-8859-1.

Access to high-resolution clock

CCL:CURRENT-TIME-IN-NANOSECONDS returns the number of elapsed nanoseconds since some arbitrary point in time (likely system boot.)

Accessing and manipulating character-encoding names and aliases

New functions:

  • (CCL:LIST-CHARACTER-ENCODINGS) returns a list of the "proper" names (keywords) of all defined character encodings.
  • (CCL:LIST-CHARACTER-ENCODINGS :INCLUDE-ALIASES T) returns a list of all proper names and aliases of all defined character encodings.
  • (CCL:DEFINE-CHARACTER-ENCODING-ALIAS alias existing) Tries to ensure that alias (a keyword) is recognized as an alias for the existing character encoding existing (which can be a CHARACTER-ENCODING object or a keyword that names one)
  • (CCL:REMOVE-CHARACTER-ENCODING-ALIAS alias) Tries to ensure that alias (a keyword) is no longer recognized as an alias for any character encoding

SIGNAL-EXTERNAL-PROCESS and external-process exit

The function CCL:SIGNAL-EXTERNAL-PROCESS now takes an :ERROR-IF-EXITED keyword argument. If the value of this argument is NIL and attempts to send the process fail because the process has already exited, CCL:SIGNAL-EXTERNAL-PROCESS quietly returns NIL. The default value of the argument is T.

File options line can determine file's EXTERNAL-FORMAT

If the first line of a text file contains an Emacs-style file-options line (";;; -*- .... -*-") and the file is opened for input with an :EXTERNAL-FORMAT of :INFERRED, then the value of the "coding" option (if present) is used to determine the file's CHARACTER-ENCODING. (:EXTERNAL-FORMAT :INFERRED also tries to determine the file's line-termination as it has previously.) When called with :EXTERNAL-FORMAT :DEFAULT, LOAD and COMPILE-FILE both arrange to call OPEN with an :EXTERNAL-FORMAT argument of :INFERRED.

(Hopefully) clearer error message when ARRAY-TOTAL-SIZE-LIMIT exceeded

ARRAY-TOTAL-SIZE-LIMIT is (ASH 1 24) in 32-bit versions of CCL and (ASH 1 56) in 64-bit versions. This limit affects both the total number of elements in a CL array and the total size of other kinds of "vector-like" objects (BIGNUMs, FUNCTIONs on some platforms, etc.) When the very low-level code that allocates vector-like objects finds that it's being asked to allocate something whose number of elements would meet or exceed this limit, it's historically signaled a TYPE-ERROR, complaining that one of its arguments is not of type (UNSIGNED-BYTE [24|56]). While technically correct, users have found this error confusing (especially since they may not have explicitly requested the allocation.) This situation now signals (via ERROR) a particular kind of STORAGE-CONDITION, and the report function for that condition tries to describe the kind of object being allocated and to explain why the allocation failed.

Argument string encoding in RUN-PROGRAM

On Unix systems, an OS-level process receives an argument count and a vector of #\NUL-terminated C strings as arguments; the C runtime system arranges to pass these arguments to the application's main() function (where they're conventionally named 'argc' and 'argv'). RUN-PROGRAM now arranges to encode the strings (in 'argv') in the encoding specified by its :EXTERNAL-FORMAT argument.

New exported symbols

The following new symbols are now exported from the CCL package:

  • *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