0.6.12.13:

[sbcl.git] / NEWS

diff --git a/NEWS b/NEWS
index b49d315..5032fb2 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -735,25 +735,51 @@ changes in sbcl-0.6.12 relative to sbcl-0.6.11:
   internal representation of (OR ..) types to accommodate the new
   support for (AND ..) types, among other things)
 
   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
 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.
 * 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.
 * 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.

-* FASL file extensions change to ".fasl", instead of the various
-  CPU-dependent values (".x86f" etc.) inherited from CMU CL.
+* 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.")