From: ram+@cs.cmu.edu (Rob MacLachlan)
Newsgroups: comp.archives
Subject: [comp.lang.lisp] CMU Common Lisp 16e Available
Followup-To: comp.lang.lisp
Date: 1 Sep 1992 23:56:18 GMT
Organization: School of Computer Science, Carnegie Mellon
Distribution: world
NNTP-Posting-Host: soda.berkeley.edu
X-Original-Newsgroups: comp.lang.lisp
X-Original-Date: 31 Aug 92 16:46:18 GMT

Archive-name: auto/comp.lang.lisp/CMU-Common-Lisp-16e-Available


	    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 "username@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 slisp@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 cmucl-bugs@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''