/[cmucl]/src/general-info/net-announce.txt
ViewVC logotype

Contents of /src/general-info/net-announce.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.2 - (show annotations)
Fri Mar 11 14:57:43 1994 UTC (20 years, 1 month ago) by ram
Branch: MAIN
Changes since 1.1: +51 -17 lines
File MIME type: text/plain
Lock status: Locked ram
Merged HP and runtime mumbling from net-README
1 Release notes for CMU Common Lisp 17e, 11 March 94
2
3 17e is primarily a bug-fix release. This release is also available on
4 Hewlett-Packard 700-series workstations running HP/UX version 9.x. The main
5 missing features on HP/UX are LOAD-FOREIGN and the Motif interface.
6
7 Distribution:
8
9 CMU Common Lisp is only available via anonymous FTP. We don't have the
10 manpower to make tapes. These are our distribution machines:
11 lisp-sun1.slisp.cs.cmu.edu (128.2.250.58)
12 lisp-rt1.slisp.cs.cmu.edu (128.2.217.9)
13 lisp-rt2.slisp.cs.cmu.edu (128.2.217.10)
14
15 Log in with the user "anonymous" and "username@host" as password (i.e. your
16 EMAIL address.) When you log in, cd to /pub (a symbolic link to the CMU CL
17 release area.) If you have any trouble with FTP access, please send mail to
18 slisp@cs.cmu.edu.
19
20 The most recent version is: 17e
21 The old version is: 16f
22
23 The currently supported platforms are:
24 sunos:
25 Sun SPARC machines running the the pre-Solaris BSD SunOS system,
26 version 4.x.
27
28 hp700_ux90:
29 HP 700 series machines (based on the HPPA architecture) running HP/UX
30 9.x.
31
32 The release area holds compressed tar files with names of the form:
33 <version>-<platform>.tar.Z
34 <version>-extra-<platform>.tar.Z
35 <version>-runtime-<platform>.tar.Z
36
37 -- The first file holds binaries and documentation for the standard Common
38 Lisp portion of CMU CL. This includes our version of the PCL
39 implementation of the CLOS object system.
40 -- The `-extra' file contains the Hemlock editor, the Motif toolkit,
41 the graphical debugger and the CLX interface to X11.
42 -- The `-runtime' file contins one file: lib/runtime.core, which is a
43 smaller substitute for lib/lisp.core. See the "runtime distribution"
44 section.
45
46 The sizes of the configurations are approximately:
47 Basic: 15 megabytes
48 Basic+Extra: 24 megabytes
49 Runtime: 5.3 megabytes
50
51 For installation directions, see the section "site initialization".
52
53 FTP compressed tar archives in binary mode. To extract, "cd" to the
54 directory that is to be the root of the tree, then type:
55 uncompress <file.tar.Z | tar xf - .
56
57 If poor network connections make it difficult to transfer a 7 meg file, the
58 release is also available split into 2 megabyte chunks, suffixed `.0', `.1',
59 etc. To extract from multiple files, use:
60 cat file.tar.Z.* | uncompress | tar xf - .
61
62 The release area also contains source distributions and other binary
63 distributions. A listing of the current contents of the release area is in
64 FILES. Major release announcements will be made to comp.lang.lisp.
65 CMU Common Lisp is only available via anonymous FTP. We don't have the
66 manpower to make tapes. These are our distribution machines:
67 lisp-sun1.slisp.cs.cmu.edu (128.2.250.58)
68 lisp-rt1.slisp.cs.cmu.edu (128.2.217.9)
69 lisp-rt2.slisp.cs.cmu.edu (128.2.217.10)
70
71 Log in with the user "anonymous" and "username@host" as password (i.e. your
72 EMAIL address.) When you log in, cd to /pub (a symbolic link to the CMU CL
73 release area.) If you have any trouble with FTP access, please send mail to
74 slisp@cs.cmu.edu.
75
76 The release area holds compressed tar files with names of the form:
77 <version>-<machine>_<os>.tar.Z
78 <version>-extra-<machine>_<os>.tar.Z
79
80 FTP compressed tar archives in binary mode. To extract, "cd" to the
81 directory that is to be the root of the tree, then type:
82 uncompress <file.tar.Z | tar xf - .
83
84 Source availability:
85
86 Lisp and documentation sources are available via anonymous FTP ftp to any CMU
87 CS machine. [See the "Distribution" section for FTP instructions.] All CMU
88 written code is public domain, but CMU CL also makes use of two imported
89 packages: PCL and CLX. Although these packages are copyrighted, they may be
90 freely distributed without any licensing agreement or fee.
91
92 The release area contains a source distribution, which is an image of all the
93 source code files used to build the current version:
94 <version>-source.tar.Z (5 meg)
95
96 ________________________________________________________________
97
98 DETAILED RELEASE NOTES
99
100 [Notes are also in doc/release-notes.txt]
101
102 BASIC COMMON LISP SUPPORT CODE:
103
104 Enhancements:
105 -- The function EXT:PURIFY is now exported. This was formerly only
106 documented as usable via the :PURIFY argument to SAVE-LISP. Great
107 improvements in GC runtime and memory use can be obtained when PURIFY is
108 called after loading in large amounts of code or creating large
109 datastructures that are unlikely to become garbage.
110 -- EXT:PURIFY (and thus (EXT:SAVE-LISP ... :PURIFY T) now compact the
111 hashtables representing the global namespace. Formerly this feature was
112 undocumented and only used during the initial system build.
113 -- There is now a "runtime" version of the Lisp image which omits the
114 compiler and loads some other code byte compiled, giving a 60% size
115 reduction. See README file, "Runtime distribution" section.
116 -- Changed the byte-function and byte-closure funcallable-instances to use
117 &more args instead of a &rest arg (eliminating the main source of
118 grautitous consing in byte code.)
119 -- Allow pretty-printer to work without compiler loaded.
120 -- Improved (and thus changed) the SXHASH of lists and other composite
121 objects.
122 -- Added to *FEATURES* all of the ANSI CL features that seemed plausible.
123 Any non-ANSI compliance is now a bug, not a feature...
124 -- Picked up Miles' changes to apropos and apropos-list that allows one to
125 supply NIL for the package, meaning all packages.
126
127 Bug fixes:
128 -- In SIGNAL, bind *break-on-signals* to NIL even before doing the type test
129 so that we don't wedge the error system if the type is malformed or
130 undefined.
131 -- Fix arg ordering for GETF in new condition support. Default the name
132 slot in DEFMACRO-LAMBDA-LIST-BIND-ERRORS to NIL (instead of leaving it
133 unbound.)
134 -- In READ-N-BYTES, only signal EOF when we read and got 0 bytes, not
135 whenever read returns less than we wanted. Also, fix the case of small
136 reads with an empty buffer not to leave garbled buffer pointers if we have
137 to do more than one read. These bugs mostly affect the X interface and
138 its users (Garnet was having problems.)
139 -- Changed YES-OR-NO-P and Y-OR-N-P to force output.
140 -- Fixed COUNT :TEST-NOT to actually negate the test.
141 -- Fixed COERCE to call type-expand so that people can coerce to deftypes.
142 -- Rename STEP to DEBUG::SET-STEP-BREAKPOINT because step is supposed to be
143 the exported step macro, not some internal routine.
144 -- Fixed DEFPACKAGE to combine multiple use, export, and import options
145 correctly. Fixed the warning about no longer using some packages to
146 actually work.
147 -- Fixed GCD to correctly handle MOST-NEGATIVE-FIXNUM.
148 -- Flush Hemlock font change hack in default site-init.lisp, since it was
149 causing problems.
150
151 CLOS (PCL):
152 -- Add some hacks for coercing lisp:class objects to pcl:class.
153 -- Export MAKE-LOAD-FORM-SAVING-SLOTS, not MAKE-LOAD-FORM-DUMPING-SLOTS.
154 -- Fix some problems with the LISP:CLASS class-precedence-list suddenly
155 becoming empty when a class is redefined.
156 -- Fixed SIMPLE-STRING to list STRING in the inherits list.
157 -- Fix to update-instance-for-different-class.
158
159
160 COMPILER:
161
162 Enhancements:
163 -- Added a type inference method for LOG's result type.
164 -- Added support for "more args" which are like rest args, but don't cons.
165 This is used for calling into annd out of byte-compiled core and in the
166 PROFILE package.
167 -- Increase *inline-expansion-limit* from 50 to 200. Change "inline
168 expansion count exceeded" warning to be a note. Don't inline expand in
169 interpreted code.
170
171 Bug fixes:
172 -- Allow stream arg to compile-file.
173 -- Changed assert-definition-type to quietly ignore non function-types.
174 -- Allow stream arg to compile-file.
175 -- Deleted incorrect type declaration in process-1-ftype-proclamation.
176 Deleted test for function-type-p around call to assert-definition-type,
177 since this is now folded into the function. Previously several calls
178 weren't doing this necessary check.
179 -- Fix a problem where spurious argument types could be inferred for optional
180 arguments in byte-compiled code (caused yes-or-no-p to fail.)
181 -- Fixed an internal error related to tail local calls.
182 -- Fixed assertion failure about COMPONENT-NEW-FUNCTIONS with some inline
183 expansions.
184 -- Fixed (TYPEP X '(REAL ...)) to actually test against REAL, not NUMBER.
185 -- Fixed a problem where top-level MULTIPLE-VALUE-CALL forms could cause an
186 assertion falure.
187 -- Don't try to compile flow-graph components that are unreachable. This
188 avoids some internal errors when unreachable local functions are
189 deleted.
190 -- Fix problem with byte-compiling PROGV getting an internal compiler error.
191
192
193 EXTENSIONS:
194
195 Misc extensions:
196 -- Added an executable-only optional to EXT:UNIX-NAMESTRING so that we can
197 expand path:foo into the first executable in the path named foo, not just
198 the first file
199 -- Changed RUN-PROGRAM to only try to run executables, and to flame out if it
200 can't be found in path:.
201 -- Profile: use &more instead of &rest to avoid consing the &rest arg list.
202 Fixed PROFILE:REPORT-TIME to not choke if any of the function names are
203 not symbols (e.g. setf functions).
204
205 [NOTE: Motif server doesn't work on HP yet.]
206 Motif interface:
207 -- Added an optional STYLE arg to the graphical inspector to make the
208 function consistent with its doc string (as well as the old inspector).
209 -- Tried to make starting the Motif server more robust, or at least give some
210 intelligible error message.
211 -- Added some extra protection against recursive invocation of the windowing
212 debugger.
213 -- Don't try to invoke motif debugger if we didn't succeed in opening a
214 connection.
215 -- Print warning in status hook when server dies.
216 -- Made server fflush after all output so that we see output when it is run
217 on a pipe.
218
219 Hemlock:
220 -- Add window-buffer-hook for echo area buffer to make absolutely sure we
221 can't change the eacho area window to point to another buffer.
222 -- Give a sensible error message if we can't find the slave utility (e.g.
223 lisp) to run.
224 -- Restored the behavior of scribe-file to cd to the directory of the .mss
225 file before running scribe.
226 -- Change default fonts to be courier, flushing all mention of 8x13.
227 Remove font-setting in default site-init file, since it was causing
228 problems.
229 -- Add FILE-POSITION method for region streams so that the compiler's read
230 error recovery works for "Editor Compile Defun", etc.
231 -- When reading a file, set BUFFER-WRITABLE to T before doing anything so
232 that we don't get spurious read-only errors.
233
234
235 ________________________________________________________________
236
237 Sun Release 4.1 1
238
239 CMUCL(1) USER COMMANDS CMUCL(1)
240
241
242
243 NAME
244 CMU Common Lisp
245
246
247 DESCRIPTION
248 CMU Common Lisp is public domain "industrial strength" Com-
249 mon Lisp programming environment. Many of the X3j13 changes
250 have been incorporated into CMU CL. Wherever possible, this
251 has been done so as to transparently allow use of either
252 CLtL1 or proposed ANSI CL. Probably the new features most
253 interesting to users are SETF functions, LOOP and the WITH-
254 COMPILATION-UNIT macro.
255
256
257 HARDWARE REQUIREMENTS
258 CMU CL is currently available for Sparcstations and DECsta-
259 tions (pmaxes) running Mach (or OSF/1). We are beta-testing
260 a SunOS SPARC version and an IBM RT Mach version. At least
261 16 megabytes of memory and 25 megabytes of disk space are
262 recommended. As usual, more is better.
263
264
265 OVERVIEW
266 When compared other Common Lisp implementations, CMU CL has
267 two broad advantages:
268
269 -- The new CMU CL compiler (Python) is more sophisticated
270 than other Common Lisp compilers. It both produces
271 better code and is easier to use.
272
273 -- The programming environment based on the Hemlock editor
274 is better integrated than gnu-emacs based environments.
275 (Though you can still use GNU if you want.)
276
277 CMU CL also has significant non-technical advantages:
278
279 -- It has good local support for CMU users, and is well
280 integrated with the CMU CS environment.
281
282 -- It is public domain, and is freely available to non-CMU
283 sites that aren't able to afford a site-license for a
284 commercial Lisp.
285
286
287
288 COMPILER FEATURES
289 The `Advanced Compiler' chapter of the User's manual exten-
290 sively discusses Python's optimization capabilities (See
291 DOCUMENTATION below.) Here are a few high points:
292
293 -- Good efficiency and type-checking at the same time. Com-
294 piling code safe gives a 2x speed reduction at worst.
295
296 -- In safe code, type declarations are verified, allowing
297 declarations to be debugged in safe code. When you go to
298 compile unsafe, you know the declarations are right.
299
300 -- Full source level debugging of compiled code, including
301 display of the exact call that got an error.
302
303 -- Good efficiency notes that tell you why an operation
304 can't be open coded or where you are number-consing, and
305 that provide unprecedented source context
306
307 -- Block compilation, partial evaluation, lightweight func-
308 tions and proper tail-recursion allow low-cost use of
309 function call abstraction.
310
311 TYPE SUPPORT
312 Important note: Even debugged programs may contain type
313 errors that remain undetected by other compilers. When com-
314 piled with type checking suppressed using the CMU Common
315 Lisp compiler, these type errors may cause said debugged
316 programs to die strangely. If type checking is not
317 suppressed, these programs will die with an explicit type
318 error.
319
320 The most visible way in which Python differs from previous
321 Common Lisp compilers is that it has a greater knowledge
322 about types and a different approach to type checking. In
323 particular, Python implements type checking which is `eager'
324 and `precise':
325
326 -- Eager in the sense that type checking is done immediately
327 whenever there is a declaration, rather than being
328 delayed until the the value is actually used. For exam-
329 ple:
330 (let ((x ...))
331 (declare (fixnum x))
332 ...)
333 Here, the type of the initial value of X must be a FIXNUM
334 or an error will be signalled.
335
336 -- Precise in the sense that the exact type specified is
337 checked. For example, if a variable is declared to be of
338 type (integer 3 7), then the value must always be an
339 integer between 3 and 7.
340
341 Since Python does more type checking, programs that work
342 fine when compiled with other compilers may get type errors
343 when compiled with Python. It is important to initially
344 compile programs with the default (safe) policy, and then
345 test this version. If a program with an erroneous declara-
346 tion is compiled with type checking suppressed (due to the
347 SAFETY optimize quality being reduced), then the type error
348 may cause obscure errors or infinite looping. See the sec-
349 tion `Getting Existing Programs to Run' (6.6) in the com-
350 piler chapter of the user manual.
351
352 CMU CL adheres to the X3J13 function type cleanup, which
353 means that quoted lambda-lists are not of type FUNCTION, and
354 are no longer directly callable. Use COERCE with the FUNC-
355 TION result type.
356
357
358 OPTIMIZATION
359 Python does many optimizations that are absent or less gen-
360 eral in other Common Lisp compilers: Proper tail recursion,
361 lightweight function call, block compilation, inter-
362 procedural type inference, global flow analysis, dynamic
363 type inference, global register allocation, stack number
364 allocation, control optimization, integer range analysis,
365 enhanced inline expansion, multiple value optimization and
366 source-to-source transforms.
367
368 Optimization and type-checking are controlled by the OPTIM-
369 IZE declaration. The default compilation policy is type-
370 safe.
371
372
373 NUMERIC SUPPORT
374 Python is particular good at number crunching:
375
376 -- Good inline coding of float and 32 bit integer opera-
377 tions, with no number consing. This includes all the
378 hardware primitives ROUND, TRUNCATE, COERCE, as well as
379 important library routines such as SCALE-FLOAT and
380 DECODE-FLOAT. Results that don't fit in registers go on
381 a special number stack.
382
383 -- Full support for IEEE single and double (denorms, +-0,
384 etc.)
385
386 -- In block compiled code, numbers are passed as function
387 arguments and return values in registers (and without
388 number consing.)
389
390 -- Calls to library functions (SIN, ...) are optimized to a
391 direct call to the C library routine (with no number
392 consing.) On hardware with direct support for such func-
393 tions, these operations can easily be open-coded.
394
395 -- Substantially better bignum performance than commercial
396 implementations (2x-4x). Bignums implemented in lisp
397 using word integers, so you can roll your own.
398
399 Python's compiler warnings and efficiency notes are espe-
400 cially valuable in numeric code. 50+ pages in the user
401 manual describe Python's capabilities in more detail.
402
403
404
405 THE DEBUGGER
406 In addition to a basic command-line interface, the debugger
407 also has several powerful new features:
408
409 -- The "source" and "vsource" commands print the *precise*
410 original source form responsible for the error or pending
411 function call. It is no longer necessary to guess which
412 call to CAR caused some "not a list" error.
413
414 -- Variables in compiled code can be accessed by name, so
415 the debugger always evaluates forms in the lexical
416 environment of the current frame. This variable access
417 is robust in the presence of compiler optimization ---
418 although higher levels of optimization may make variable
419 values unavailable at some locations in the variable's
420 scope, the debugger always errs on the side of discre-
421 tion, refusing to display possibly incorrect values.
422
423 -- Integration with the Hemlock editor. In a slave, the
424 "edit" command causes the editor edit the source for the
425 current code location. The editor can also send non-
426 line-mode input to the debugger using C-M-H bindings.
427 Try apropos "debug" in Hemlock.
428
429 See the debugger chapter in the user manual for more
430 details. We are working on integrating the debugger with
431 Hemlock and X windows.
432
433
434 THE INTERPRETER
435 As far as Common Lisp semantics are concerned, there is no
436 interpreter; this is effectively a compile-only implementa-
437 tion. Forms typed to the read-eval-print loop or passed to
438 EVAL are in effect compiled before being run. In implemen-
439 tation, there is an interpreter, but it operates on the
440 internal representation produced by the compiler's font-end.
441
442 It is not recommended that programs be debugged by running
443 the whole program interpreted, since Python and the debugger
444 eliminate the main reasons for debugging using the inter-
445 preter:
446
447 -- Compiled code does much more error checking than inter-
448 preted code.
449
450 -- It is as easy to debug compiled code as interpreted code.
451
452 Note that the debugger does not currently support single-
453 stepping. Also, the interpreter's pre-processing freezes in
454 the macro definitions in effect at the time an interpreted
455 function is defined. Until we implement automatic repro-
456 cessing when macros are redefined, it is necessary to re-
457 evaluate the definition of an interpreted function to cause
458 new macro definitions to be noticed.
459
460
461 DOCUMENTATION
462 The CMU CL documentation is printed as tech reports, and is
463 available (at CMU) in the document room:
464
465
466 CMU Common Lisp User's Manual
467 Hemlock User's Manual
468 Hemlock Command Implementor's Manual
469
470 Non-CMU users may get documentation from the doc/ directory
471 in the binary distribution:
472
473 cmu-user.info
474 CMU CL User's Manual in Gnu Info format. The
475 ``cmu-user.info-<N>'' files are subfiles. You can
476 either have your EMACS maintainer install this in
477 the info root, or you can use the info
478 ``g(...whatever.../doc/cmu-user.info)'' command.
479
480 cmu-user.ps
481 The CMU CL User's Manual (148 pages) in postscript
482 format. LaTeX source and DVI versions are also
483 available.
484
485 release-notes.txt
486 Information on the changes between releases.
487
488 hemlock-user.ps
489 Postscript version of the Hemlock User's Manual
490 (124 pages.)
491
492 hemlock-cim.ps
493 Postscript version of the Hemlock Command
494 Implementor's Manual (96 pages).
495
496 SUPPORT
497 Bug reports should be sent to cmucl-bugs@cs.cmu.edu. Please
498 consult your local CMU CL maintainer or Common Lisp expert
499 to verify that the problem really is a bug before sending to
500 this list.
501
502 We have insufficient staffing to provide extensive support
503 to people outside of CMU. We are looking for university and
504 industrial affiliates to help us with porting and mainte-
505 nance for hardware and software that is not widely used at
506 CMU.
507
508
509 DISTRIBUTION
510 CMU Common Lisp is a public domain implementation of Common
511 Lisp. Both sources and executables are freely available via
512 anonymous FTP; this software is "as is", and has no warranty
513 of any kind. CMU and the authors assume no responsibility
514 for the consequences of any use of this software. See the
515 README file in the distribution for FTP instructions.
516
517
518 ABOUT THE CMU COMMON LISP PROJECT
519 Organizationally, CMU Common Lisp is a small, mostly auto-
520 nomous part within the Mach operating system project. CMU
521 CL is more of a tool development effort than a research pro-
522 ject. The project started out as Spice Lisp, which provided
523 a modern Lisp implementation for use in the CMU community.
524 CMU CL has been under continuous development since the early
525 1980's (concurrent with the Common Lisp standardization
526 effort.)
527
528 CMU CL is funded by DARPA under CMU's "Research on Parallel
529 Computing" contract. Rather than doing pure research on
530 programming languages and environments, our emphasis has
531 been on developing practical programming tools. Sometimes
532 this has required new technology, but much of the work has
533 been in creating a Common Lisp environment that incorporates
534 state-of-the-art features from existing systems (both Lisp
535 and non-Lisp.)
536
537 Because sources are freely available, CMU Common Lisp has
538 been ported to experimental hardware, and used as a basis
539 for research in programming language and environment con-
540 struction.
541
542
543 SEE ALSO
544 lisp(1), README
545 The ``CMU Common Lisp User's Manual'',
546 the ``Hemlock User's Manual'', and
547 the ``Hemlock Command Implementor's Manual''

  ViewVC Help
Powered by ViewVC 1.1.5