0.6.12.11:
[sbcl.git] / NEWS
diff --git a/NEWS b/NEWS
index 196ae66..5032fb2 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -682,43 +682,104 @@ changes in sbcl-0.6.11 relative to sbcl-0.6.10:
   as per Daniel Barlow's suggestion and Martin Atzmueller's patch
 
 changes in sbcl-0.6.12 relative to sbcl-0.6.11:
+* incompatible change: The old SB-EXT:OPTIMIZE-INTERFACE declaration
+  is no longer recognized. I apologize for this, because it was
+  listed in SB-EXT as a supported extension, but I found that
+  its existing behavior was poorly specified, as well as incorrectly
+  specified, and it looked like too much of a mess to straighten it
+  out. I have enough on my hands trying to get ANSI stuff to work..
 * many patches ported from CMU CL by Martin Atzmueller, with 
   half a dozen bug fixes in pretty-printing and the debugger, and
   half a dozen others elsewhere
-?? improved support for intersection types, fixing bug 12 (E.g., now
-  (SUBTYPEP 'KEYWORD 'SYMBOL)=>T,T.)
-?? The :PROPAGATE-FLOAT-TYPE and :PROPAGATE-FUN-TYPE features
+* fixed bug 13: Floating point infinities are now supported again.
+  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
+  same circumstances that the man page talks about.)
+* The :SB-PROPAGATE-FLOAT-TYPE and :SB-PROPAGATE-FUN-TYPE features
   are now supported, and enabled by default. Thus, the compiler can
   handle many floating point and complex operations much less
   inefficiently. (Thus e.g. you can implement a complex FFT
   without consing!)
-?? unscrewed floating point infinities (bug 13) in order to support
-  :PROPAGATE-FLOAT-TYPE and :PROPAGATE-FUN-TYPE features
-?? some minor ANSIfication of type specifications: bare 'AND and 'OR
-  are no longer valid type specifiers, so e.g. (TYPEP 11 'AND) now
-  signals an error; and SATISFIES requires its predicate to be a 
-  symbol, not a function object
+* 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
-* 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.")