half a dozen bug fixes in pretty-printing and the debugger, and
half a dozen others elsewhere
* fixed bug 13: Floating point infinities are now supported again.
-* fixed bug 45a: Various internal functions required to support
- complex special functions have been merged from CMU CL sources.
- (When I was first setting up SBCL, I misunderstood a compile-time
- conditional #-OLD-SPECFUN, and so accidentally deleted them.)
+ They might still be a little bit flaky, but thanks to bug reports
+ from Nathan Froyd and CMU CL patches from Raymond Toy they're not
+ as flaky as they were.
* The --noprogrammer command line option is now supported. (Its
behavior is slightly different in detail from what the old man
page claimed it would do, but it's still appropriate under the
handle many floating point and complex operations much less
inefficiently. (Thus e.g. you can implement a complex FFT
without consing!)
-* improved support for type intersection and union, fixing bug 12
- (e.g., now (SUBTYPEP 'KEYWORD 'SYMBOL)=>T,T) and some other
- more obscure bugs as well
+* The compiler now detects type mismatches between DECLAIM FTYPE
+ and DEFUN better, and implements CHECK-TYPE more correctly, and
+ SBCL builds under CMU CL again despite its non-ANSI EVAL-WHEN,
+ thanks to patches from Martin Atzmueller.
* various fixes to make the cross-compiler more portable to
ANSI-conforming-but-different cross-compilation hosts (notably
Lispworks for Windows, following bug reports from Arthur Lemmens)
-* a new workaround to make the cross-compiler portable to CMU CL
- again despite its non-ANSI EVAL-WHEN, thanks to Martin Atzmueller
-* The compiler now detects type mismatches between DECLAIM FTYPE
- and DEFUN better, thanks to patches from Martin Atzmueller.
-* A bug in READ-SEQUENCE for CONCATENATED-STREAM has been fixed
- thanks to Pierre Mai's CMU CL patch.
-* new fasl file format version number (because of changes in byte
- code opcodes and in internal representation of (OR ..) types)
+* A bug in READ-SEQUENCE for CONCATENATED-STREAM, and a gross
+ ANSI noncompliance in DEFMACRO &KEY argument parsing, have been
+ fixed thanks to Pierre Mai's CMU CL patches.
+* fixes to keep the system from overflowing internal counters when
+ it tries to use i/o buffers larger than 16M bytes
+* fixed bug 45a: Various internal functions required to support
+ complex special functions have been merged from CMU CL sources.
+ (When I was first setting up SBCL, I misunderstood a compile-time
+ conditional #-OLD-SPECFUN, and so accidentally deleted them.)
+* improved support for type intersection and union, fixing bug 12
+ (e.g., now (SUBTYPEP 'KEYWORD 'SYMBOL)=>T,T) and some other
+ more obscure bugs as well
+* some steps toward byte-compiling non-performance-critical
+ parts of the system, courtesy of patches from Martin Atzmueller
+* Christophe Rhodes has made some debian packages of sbcl at
+ <http://www-jcsu.jesus.cam.ac.uk/ftp/pub/debian/lisp>.
+ From his sbcl-devel e-mail of 2001-04-08 they're not completely
+ stable, but are nonetheless usable. When he's ready, I'd be happy
+ to add them to the SourceForge "File Releases" section. (And if
+ anyone wants to do RPMs or *BSD packages, they'd be welcome too.)
+* new fasl file format version number (because of changes in
+ internal representation of (OR ..) types to accommodate the new
+ support for (AND ..) types, among other things)
+
+changes in sbcl-0.6.13 relative to sbcl-0.6.12:
+* a port to the Alpha CPU, thanks to Dan Barlow
+* Martin Atzmueller ported Tim Moore's marvellous CMU CL DISASSEMBLE
+ patch, so that DISASSEMBLE output is much nicer.
+* better error handling in CLOS method combination, thanks to
+ Martin Atzmueller and Pierre Mai
+* Hash tables can be printed readably, as inspired by CMU CL code
+ of Eric Marsden and SBCL code of Martin Atzmueller.
+* a new slam.sh hack to shorten the edit/compile/debug cycle for
+ low-level changes to SBCL itself, and a new :SB-AFTER-XC-CORE
+ target feature to control the generation of the after-xc.core
+ file needed by slam.sh.
+* Compiler trace output (the :TRACE-FILE option to COMPILE-FILE)
+ is now a supported extension again, since the consensus is that
+ it can be useful for ordinary development work, not just for
+ debugging SBCL itself.
+?? more overflow fixes for >16Mbyte i/o buffers
+* minor incompatible change: The ENTRY-POINTS &KEY argument to
+ COMPILE-FILE is no longer supported, so that now every function
+ gets an entry point, so that block compilation looks a little
+ more like the plain vanilla ANSI section 3.2.2.3 scheme.
planned incompatible changes in 0.7.x:
* The debugger prompt sequence now goes "5]", "5[2]", "5[3]", etc.
as you get deeper into recursive calls to the debugger command loop,
instead of the old "5]", "5]]", "5]]]" sequence. (I was motivated
- to do this when ILISP and SBCL got into arguments which left me
- deeply nested in the debugger.)
-* When the profiling interface settles down, it might impact TRACE.
- They both encapsulate functions, and it's not clear yet how
- e.g. UNPROFILE will interact with TRACE and UNTRACE. (This shouldn't
- matter, though, unless you are using profiling. If you never
- profile anything, TRACE should continue to behave as before.)
+ to do this when squabbles between ILISP and SBCL left me
+ very deeply nested in the debugger.)
* The fasl file extension may change, perhaps to ".fasl".
* The default output representation for unprintable ASCII characters
which, unlike e.g. #\Newline, don't have names defined in the
ANSI Common Lisp standard, may change to their ASCII symbolic
names: #\Nul, #\Soh, #\Stx, etc.
* INTERNAL-TIME-UNITS-PER-SECOND might increase, e.g. to 1000.
+* FASL file extensions change to ".fasl", instead of the various
+ CPU-dependent values (".x86f", ".axpf", etc.) inherited from CMU CL.
* MAYBE-INLINE will probably go away at some point, maybe 0.7.x,
maybe later, in favor of the ANSI-recommended idiom for making
a function optionally inline.
+* When the profiling interface settles down, maybe in 0.7.x, maybe
+ later, it might impact TRACE. They both encapsulate functions, and
+ it's not clear yet how e.g. UNPROFILE will interact with TRACE
+ and UNTRACE. (This shouldn't matter, though, unless you are
+ using profiling. If you never profile anything, TRACE should
+ continue to behave as before.)
+* The BYTE-COMPILE &KEY argument for COMPILE-FILE is deprecated,
+ since this behavior can be controlled by (DECLAIM (OPTIMIZE (SPEED 0))).
+ ("An ounce of orthogonality is worth a pound of features.")