|Version 8 (modified by gb, 19 months ago) (diff)|
Release notes for Clozure CL 1.9
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 http://svn.clozure.com/publicsvn/openmcl/release/1.9/darwinx86/ccl
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 http://subversion.apache.org/packages.html.
For more details, please see SystemRequirements.
Please use the Trac instance at http://trac.clozure.com/ccl to review existing bug reports and to submit new ones.
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 CL.app 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 http://ccl.clozure.com/FTP/gdb-768-limited-mach-exceptions.tar.gz (for OSX 10.5) and http://ccl.clozure.com/FTP/gdb-1820-limited-mach-exceptions.tar.gz (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
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.
An ARMv6 or ARMv7 processor is required. The nomenclature used to identify various ARM processors is extremely confusing. http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores 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/float_abi.mk". 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 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 and others
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.
New default values for CCL:*DEFAULT-FILE-CHARACTER-ENCODING* and CCL:*TERMINAL-CHARACTER-ENCODING-NAME*
These variables now default to :UTF-8; in previous versions of CCL, they defaulted to NIL/:ISO-8859-1.
File options line can determine file's EXTERNAL-FORMAT
New exported symbols
The following new symbols are now exported from the CCL package: