NetNews Usenet Archive 1992 #19

home *** CD-ROM | disk | FTP | other *** search

/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / archives / 3178 < prev next >

Wrap

Internet Message Format | 1992-09-01 | 25.2 KB

Path: sparky!uunet!sun-barr!ames!agate!agate!usenet 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 Lines: 563 Approved: adam@soda.berkeley.edu Distribution: world Message-ID: <180vv2INNqan@agate.berkeley.edu> References: <Btux9A.I9F.1@cs.cmu.edu> 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''