From: Rob MacLachlan
Subject: CMU Common Lisp 16e Available
Date:
Message-ID: <Btux9A.I9F.1@cs.cmu.edu>
Release notes for CMU Common Lisp 16e, 5 August 92
16e is primarily a bug-fix release. The main changes from 16d are:
-- CLOS support is from March 92 PCL (2a). This is a new version of PCL
developed by Richard Harris which incorporates many bug-fixes and ANSI
compliance cleanups. He has also back-merged the CMU changes into his
sources so that we can release future PCLs without time-consuming merging.
On the downside, there are a couple of new bugs. Harris has announced
patches to a couple of problems.
-- TRACE has been reimplemented, has a new syntax and new features.
-- The hardcopy and info documentation has been updated. Note that it
describes some debugger capabilities (breakpoints) which won't appear
until version 17.
The fasl file format is the same as for 16d, but some code may need to be
recompiled. In particular, the expansion of PPRINT-LOGICAL-BLOCK has changed.
Distribution:
CMU Common Lisp is only available via anonymous FTP. We don't have the
manpower to make tapes. These are our distribution machines:
lisp-rt1.slisp.cs.cmu.edu (128.2.217.9)
lisp-rt2.slisp.cs.cmu.edu (128.2.217.10)
Log in with the user "anonymous" and ·········@host" as password (i.e. your
EMAIL address.) When you log in, the current directory should be set to the
CMU CL release area. If you have any trouble with FTP access, please send mail
to ·····@cs.cmu.edu.
The release area holds compressed tar files with names of the form:
<version>-<machine>_<os>.tar.Z
<version>-extra-<machine>_<os>.tar.Z
FTP compressed tar archives in binary mode. To extract, "cd" to the
directory that is to be the root of the tree, then type:
uncompress <file.tar.Z | tar xf - .
As of 8/6/92, the latest SunOS Sparc release is:
16e-sun4c_41.tar.Z (6.5 meg)
16e-extra-sun4c_41.tar.Z (3.5 meg)
The first file holds binaries and documentation for the basic Lisp system,
while the second `-extra' file contains the Hemlock editor, the graphical
inspector and the CLX interface to X11. The basic configuration takes 16
megabytes of disk space; adding the extras takes another 8 megabytes. For
installation directions, see the section "site initialization" in README file
at the root of the tree.
If poor network connections make it difficult to transfer a 10 meg file, the
release is also available split into 2 megabyte chunks, suffixed `.0', `.1',
etc. To extract from multiple files, use:
cat file.tar.Z.* | uncompress | tar xf - .
The release area also contains source distributions and other binary
distributions. A listing of the current contents of the release area is in
FILES. Major release announcements will be made to comp.lang.lisp until there
is enough volume to warrant a comp.lang.lisp.cmu.
Source availability:
Lisp and documentation sources are available via anonymous FTP ftp to any CMU
CS machine. [See the "Distribution" section for FTP instructions.] All CMU
written code is public domain, but CMU CL also makes use of two imported
packages: PCL and CLX. Although these packages are copyrighted, they may be
freely distributed without any licensing agreement or fee.
The release area contains a source distribution, which is an image of all the
".lisp" source files used to build version 16e:
16e-source.tar.Z (3.6 meg)
________________________________________________________________
DETAILED RELEASE NOTES
[Notes are also in doc/release-notes.txt]
March 92 PCL highlights: (see notes.text in the sources for details)
-- This version of PCL is much closer than previous versions of PCL to the
metaobject protocol specified in "The Art of the Metaobject Protocol",
chapters 5 and 6, by Gregor Kiczales, Jim des Riveres, and Daniel G.
Bobrow.
-- You can use structure-class as a metaclass to create new classes.
Classes created this way create and evaluate defstruct forms which
have generated symbols for the structure accessors and constructor.
-- Various optimization of instance variable access, both inside and outside
of methods.
-- More work (lookups and precompilation) is done at compile and load time,
rather than run-time.
New TRACE:
Trace has been substantially rewritten, and has a new syntax as well as new
functionality:
-- Tracing of compiled functions is now implemented using breakpoints.
Breakpoints destructively modify the code object, causing all calls to the
function to be trapped, instead of only those calls that indirect through
the symbol. This makes TRACE more useful for debugging programs that use
data structures containing function values, since you can now trace
anonymous functions and macros. Also, the breakpoint stops the function
after the arguments have been parsed, so arguments can accessed by name in
the debugger or in TRACE options.
-- Depending on the ENCAPSULATE option and DEBUG:*TRACE-ENCAPSULATE-DEFAULT*,
encapsulation may be used instead. This is the default for closures,
generic functions and interpreted functions.
-- TRACE options are no longer set off by extra parens, and you can specify
global trace options which affect all functions traced by a particular
call to TRACE.
-- Conditional breakpoints now work much better than before.
-- *DEBUG-PRINT-LEVEL*, -LENGTH* are used instead of a separate
*TRACE-PRINT-LEVEL*, etc.
Here is the documentation string (see also the hardcopy/info documentation):
TRACE {Option Global-Value}* {Name {Option Value}*}*
TRACE is a debugging tool that prints information when specified functions
are called. In its simplest form:
(trace Name-1 Name-2 ...)
TRACE causes a printout on *TRACE-OUTPUT* each time that one of the named
functions is entered or returns (the Names are not evaluated.) The output
is indented according to the number of pending traced calls, and this trace
depth is printed at the beginning of each line of output.
Options allow modification of the default behavior. Each option is a pair
of an option keyword and a value form. Options may be interspersed with
function names. Options only affect tracing of the function whose name they
appear immediately after. Global options are specified before the first
name, and affect all functions traced by a given use of TRACE.
The following options are defined:
:CONDITION Form
:CONDITION-AFTER Form
:CONDITION-ALL Form
If :CONDITION is specified, then TRACE does nothing unless Form
evaluates to true at the time of the call. :CONDITION-AFTER is
similar, but suppresses the initial printout, and is tested when the
function returns. :CONDITION-ALL tries both before and after.
:WHEREIN Names
If specified, Names is a function name or list of names. TRACE does
nothing unless a call to one of those functions encloses the call to
this function (i.e. it would appear in a backtrace.) Anonymous
functions have string names like "DEFUN FOO".
:BREAK Form
:BREAK-AFTER Form
:BREAK-ALL Form
If specified, and Form evaluates to true, then the debugger is invoked
at the start of the function, at the end of the function, or both,
according to the respective option.
:PRINT Form
:PRINT-AFTER Form
:PRINT-ALL Form
In addition to the usual prinout, he result of evaluating Form is
printed at the start of the function, at the end of the function, or
both, according to the respective option. Multiple print options cause
multiple values to be printed.
:FUNCTION Function-Form
This is a not really an option, but rather another way of specifying
what function to trace. The Function-Form is evaluated immediately,
and the resulting function is traced.
:ENCAPSULATE {:DEFAULT | T | NIL}
If T, the tracing is done via encapsulation (redefining the function
name) rather than by modifying the function. :DEFAULT is the default,
and means to use encapsulation for interpreted functions and funcallable
instances, breakpoints otherwise. When encapsulation is used, forms are
*not* evaluated in the function's lexical environment, but DEBUG:ARG can
still be used.
:CONDITION, :BREAK and :PRINT forms are evaluated in the lexical environment
of the called function; DEBUG:VAR and DEBUG:ARG can be used. The -AFTER and
-ALL forms are evaluated in the null environment.
Assorted bug fixes and enhancements:
System code:
-- Changed default base file name for LOAD-FOREIGN to be argv[0] rather than
being hard-wired to "lisp".
-- Fixed a bad declaration which caused garbage collection to fail if more
than MOST-POSITIVE-FIXNUM bytes had been consed since process creation.
-- Changed GET-INTERNAL-RUN-TIME to use UNIX-FAST-GETRUSAGE to avoid
number-consing and generic arithmetic. Also, rearranged the computation
so that the time is correctly computed for up to 457 days, instead of only
71 minutes.
-- Merged Miles' fix to MAKE-PATHNAME so that it knows the difference between
an arg being NIL and being unsupplied.
-- Some partial fixes to circular printing (the #1=#1# bug).
PPRINT-LOGICAL-BLOCK no longer checks the list argument for CAR
circularity, now that OUTPUT-OBJECT does it for us.
-- Fixed reader dispatch macro characters to be case-insensitive, and to
disallow digits as sub-characters.
-- Changed #A reader to allow arbitrary sequences instead of just lists.
-- RUN-PROGRAM now gives a proper error message when "fork" fails (i.e. too
-- Fixed a bug in initialization of saved cores which caused the old
environment to be left on the end of EXT:*ENVIRONMENT-LIST*. One symptom
was that RUN-PROGRAM would run programs with strange environment values
based on those in effect at the time the core was saved. In particular,
Lisp subprocesses (i.e. Hemlock slaves) might get the wrong value of
CMUCLLIB, which caused the slave to die before connecting.
-- SYSTEM:SERVE-EVENT (and XLIB:EVENT-CASE, etc.) now correctly handle
non-integer timeouts. Added declarations to improve the efficiency of
event handling.
-- Fixed some bugs in UNIX-SELECT which could cause Lisp to hang when more
than 32 files were open. Also, improved efficiency in this case.
-- Merged Olssons fix to WITH-ENABLED-INTERRUPTS to not try to change
interrupt characters anymore.
-- A number of bug-fixes for breakpoint support in compiled code (but there
are still problems with arbitrary breakpoints.)
-- Fixed DI:FRAME-CATCHES
CLX:
-- Fixed the implementation-dependent pixarray copying routines (for
GET-IMAGE, etc.) so that they don't occasionally trash memory, and are
actually faster.
-- Fixed the definition of the ANGLE type (used by DRAW-ARC, etc.) to work
regardless of the kind of real number (single or double float, rational,
etc.)
-- Fixed several places in image operations where values that could really
be negative were declared to be non-negative.
Compiler:
-- Fixed a bug which caused an internal error whenever a call to random
was compiled and the argument type wasn't known to be either a float or
an integer.
-- Fixed a bug which caused an internal compiler error when a value that
wasn't used had an unproven type assertion.
-- Fixed some more dead-code deletion bugs.
-- Fixed a problem with the new "assignment" optimization of local function
call where the compiler could get assertion failures such as tail-sets not
being equal.
-- Fixed a few places where reoptimization wasn't being triggered when it
should have been.
-- You can now have a TAGBODY with more than one tag that is non-locally
exited to. Evidently this never worked...
-- Some changes in debug-info format related to breakpoint support.
Misc:
-- Fixed some Hemlock Dired commands to know that PATHNAME-DIRECTORY is
now a list, not a vector.
-- Fixed the bin/sample-wrapper script to use ··@" instead of $* so that
arguments are properly passed through.
________________________________________________________________
Sun Release 4.1 1
CMUCL(1) USER COMMANDS CMUCL(1)
NAME
CMU Common Lisp
DESCRIPTION
CMU Common Lisp is public domain "industrial strength" Com-
mon Lisp programming environment. Many of the X3j13 changes
have been incorporated into CMU CL. Wherever possible, this
has been done so as to transparently allow use of either
CLtL1 or proposed ANSI CL. Probably the new features most
interesting to users are SETF functions, LOOP and the WITH-
COMPILATION-UNIT macro.
HARDWARE REQUIREMENTS
CMU CL is currently available for Sparcstations and DECsta-
tions (pmaxes) running Mach (or OSF/1). We are beta-testing
a SunOS SPARC version and an IBM RT Mach version. At least
16 megabytes of memory and 25 megabytes of disk space are
recommended. As usual, more is better.
OVERVIEW
When compared other Common Lisp implementations, CMU CL has
two broad advantages:
-- The new CMU CL compiler (Python) is more sophisticated
than other Common Lisp compilers. It both produces
better code and is easier to use.
-- The programming environment based on the Hemlock editor
is better integrated than gnu-emacs based environments.
(Though you can still use GNU if you want.)
CMU CL also has significant non-technical advantages:
-- It has good local support for CMU users, and is well
integrated with the CMU CS environment.
-- It is public domain, and is freely available to non-CMU
sites that aren't able to afford a site-license for a
commercial Lisp.
COMPILER FEATURES
The `Advanced Compiler' chapter of the User's manual exten-
sively discusses Python's optimization capabilities (See
DOCUMENTATION below.) Here are a few high points:
-- Good efficiency and type-checking at the same time. Com-
piling code safe gives a 2x speed reduction at worst.
-- In safe code, type declarations are verified, allowing
declarations to be debugged in safe code. When you go to
compile unsafe, you know the declarations are right.
-- Full source level debugging of compiled code, including
display of the exact call that got an error.
-- Good efficiency notes that tell you why an operation
can't be open coded or where you are number-consing, and
that provide unprecedented source context
-- Block compilation, partial evaluation, lightweight func-
tions and proper tail-recursion allow low-cost use of
function call abstraction.
TYPE SUPPORT
Important note: Even debugged programs may contain type
errors that remain undetected by other compilers. When com-
piled with type checking suppressed using the CMU Common
Lisp compiler, these type errors may cause said debugged
programs to die strangely. If type checking is not
suppressed, these programs will die with an explicit type
error.
The most visible way in which Python differs from previous
Common Lisp compilers is that it has a greater knowledge
about types and a different approach to type checking. In
particular, Python implements type checking which is `eager'
and `precise':
-- Eager in the sense that type checking is done immediately
whenever there is a declaration, rather than being
delayed until the the value is actually used. For exam-
ple:
(let ((x ...))
(declare (fixnum x))
...)
Here, the type of the initial value of X must be a FIXNUM
or an error will be signalled.
-- Precise in the sense that the exact type specified is
checked. For example, if a variable is declared to be of
type (integer 3 7), then the value must always be an
integer between 3 and 7.
Since Python does more type checking, programs that work
fine when compiled with other compilers may get type errors
when compiled with Python. It is important to initially
compile programs with the default (safe) policy, and then
test this version. If a program with an erroneous declara-
tion is compiled with type checking suppressed (due to the
SAFETY optimize quality being reduced), then the type error
may cause obscure errors or infinite looping. See the sec-
tion `Getting Existing Programs to Run' (6.6) in the com-
piler chapter of the user manual.
CMU CL adheres to the X3J13 function type cleanup, which
means that quoted lambda-lists are not of type FUNCTION, and
are no longer directly callable. Use COERCE with the FUNC-
TION result type.
OPTIMIZATION
Python does many optimizations that are absent or less gen-
eral in other Common Lisp compilers: Proper tail recursion,
lightweight function call, block compilation, inter-
procedural type inference, global flow analysis, dynamic
type inference, global register allocation, stack number
allocation, control optimization, integer range analysis,
enhanced inline expansion, multiple value optimization and
source-to-source transforms.
Optimization and type-checking are controlled by the OPTIM-
IZE declaration. The default compilation policy is type-
safe.
NUMERIC SUPPORT
Python is particular good at number crunching:
-- Good inline coding of float and 32 bit integer opera-
tions, with no number consing. This includes all the
hardware primitives ROUND, TRUNCATE, COERCE, as well as
important library routines such as SCALE-FLOAT and
DECODE-FLOAT. Results that don't fit in registers go on
a special number stack.
-- Full support for IEEE single and double (denorms, +-0,
etc.)
-- In block compiled code, numbers are passed as function
arguments and return values in registers (and without
number consing.)
-- Calls to library functions (SIN, ...) are optimized to a
direct call to the C library routine (with no number
consing.) On hardware with direct support for such func-
tions, these operations can easily be open-coded.
-- Substantially better bignum performance than commercial
implementations (2x-4x). Bignums implemented in lisp
using word integers, so you can roll your own.
Python's compiler warnings and efficiency notes are espe-
cially valuable in numeric code. 50+ pages in the user
manual describe Python's capabilities in more detail.
THE DEBUGGER
In addition to a basic command-line interface, the debugger
also has several powerful new features:
-- The "source" and "vsource" commands print the *precise*
original source form responsible for the error or pending
function call. It is no longer necessary to guess which
call to CAR caused some "not a list" error.
-- Variables in compiled code can be accessed by name, so
the debugger always evaluates forms in the lexical
environment of the current frame. This variable access
is robust in the presence of compiler optimization ---
although higher levels of optimization may make variable
values unavailable at some locations in the variable's
scope, the debugger always errs on the side of discre-
tion, refusing to display possibly incorrect values.
-- Integration with the Hemlock editor. In a slave, the
"edit" command causes the editor edit the source for the
current code location. The editor can also send non-
line-mode input to the debugger using C-M-H bindings.
Try apropos "debug" in Hemlock.
See the debugger chapter in the user manual for more
details. We are working on integrating the debugger with
Hemlock and X windows.
THE INTERPRETER
As far as Common Lisp semantics are concerned, there is no
interpreter; this is effectively a compile-only implementa-
tion. Forms typed to the read-eval-print loop or passed to
EVAL are in effect compiled before being run. In implemen-
tation, there is an interpreter, but it operates on the
internal representation produced by the compiler's font-end.
It is not recommended that programs be debugged by running
the whole program interpreted, since Python and the debugger
eliminate the main reasons for debugging using the inter-
preter:
-- Compiled code does much more error checking than inter-
preted code.
-- It is as easy to debug compiled code as interpreted code.
Note that the debugger does not currently support single-
stepping. Also, the interpreter's pre-processing freezes in
the macro definitions in effect at the time an interpreted
function is defined. Until we implement automatic repro-
cessing when macros are redefined, it is necessary to re-
evaluate the definition of an interpreted function to cause
new macro definitions to be noticed.
DOCUMENTATION
The CMU CL documentation is printed as tech reports, and is
available (at CMU) in the document room:
CMU Common Lisp User's Manual
Hemlock User's Manual
Hemlock Command Implementor's Manual
Non-CMU users may get documentation from the doc/ directory
in the binary distribution:
cmu-user.info
CMU CL User's Manual in Gnu Info format. The
``cmu-user.info-<N>'' files are subfiles. You can
either have your EMACS maintainer install this in
the info root, or you can use the info
``g(...whatever.../doc/cmu-user.info)'' command.
cmu-user.ps
The CMU CL User's Manual (148 pages) in postscript
format. LaTeX source and DVI versions are also
available.
release-notes.txt
Information on the changes between releases.
hemlock-user.ps
Postscript version of the Hemlock User's Manual
(124 pages.)
hemlock-cim.ps
Postscript version of the Hemlock Command
Implementor's Manual (96 pages).
SUPPORT
Bug reports should be sent to ··········@cs.cmu.edu. Please
consult your local CMU CL maintainer or Common Lisp expert
to verify that the problem really is a bug before sending to
this list.
We have insufficient staffing to provide extensive support
to people outside of CMU. We are looking for university and
industrial affiliates to help us with porting and mainte-
nance for hardware and software that is not widely used at
CMU.
DISTRIBUTION
CMU Common Lisp is a public domain implementation of Common
Lisp. Both sources and executables are freely available via
anonymous FTP; this software is "as is", and has no warranty
of any kind. CMU and the authors assume no responsibility
for the consequences of any use of this software. See the
README file in the distribution for FTP instructions.
ABOUT THE CMU COMMON LISP PROJECT
Organizationally, CMU Common Lisp is a small, mostly auto-
nomous part within the Mach operating system project. CMU
CL is more of a tool development effort than a research pro-
ject. The project started out as Spice Lisp, which provided
a modern Lisp implementation for use in the CMU community.
CMU CL has been under continuous development since the early
1980's (concurrent with the Common Lisp standardization
effort.)
CMU CL is funded by DARPA under CMU's "Research on Parallel
Computing" contract. Rather than doing pure research on
programming languages and environments, our emphasis has
been on developing practical programming tools. Sometimes
this has required new technology, but much of the work has
been in creating a Common Lisp environment that incorporates
state-of-the-art features from existing systems (both Lisp
and non-Lisp.)
Because sources are freely available, CMU Common Lisp has
been ported to experimental hardware, and used as a basis
for research in programming language and environment con-
struction.
SEE ALSO
lisp(1), README
The ``CMU Common Lisp User's Manual'',
the ``Hemlock User's Manual'', and
the ``Hemlock Command Implementor's Manual''
From: Christian Beilken
Subject: Re: CMU Common Lisp 16e Available
Date:
Message-ID: <cici.715344343@gmd.de>
Thank you for your great job of CMU Common Lisp!
The new PCL version makes 16e very useful because
the annoying run-time-compiling is extremly reduced.
Soon the application framework GINA with its
interface builder will be available for CMU.
By the way: Can you tell me and the community when
CMU 17x with light weight processes will be available!?
Here is one hint for users of CMU CL 16e with its new PCL:
A misleading error message is produced, when a subclass
(with at least one slot) of a class is defined before its superclass.
(This was allowed in 16d and other implementions of PCL!)
(I already sent a bug report about this to the CMU team.)
This is the error message:
Error in function "DEFMETHOD SLOT-UNBOUND (T T T)":
The slot PCL::CLASS-PRECEDENCE-LIST is unbound in the object #<Standard-Clas
s <<name of subclass>> {701057D}>.
Christian Beilken ··········@gmd.de
GMD (German National Research Center for Computer Science)
P.O.Box 1316 Dept: FIT/MMK (Project GINA)
W-5205 Sankt Augustin 1, Germany Phone:(+49 2241) 14-2642