0.6.11.1:

[sbcl.git] / NEWS

diff --git a/NEWS b/NEWS
index 8c22dbd..3b5fbdf 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -642,6 +642,30 @@ changes in sbcl-0.6.10 relative to sbcl-0.6.9:
   some time ago.
 
 changes in sbcl-0.6.11 relative to sbcl-0.6.10:
   some time ago.
 
 changes in sbcl-0.6.11 relative to sbcl-0.6.10:

+* Martin Atzmueller pointed out that bugs #9 and #25 are gone in
+  current SBCL.
+* bug 34 fixed by Martin Atzmueller: dumping/loading instances works
+  better
+* fixed bug 40: TYPEP, SUBTYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, 
+  and UPGRADED-COMPLEX-PART-TYPE now work better with of compound
+  types built from undefined types, e.g. '(VECTOR SOME-UNDEF-TYPE).
+* DESCRIBE now works on structure objects again.
+* Most function call argument type mismatches are now handled as
+  STYLE-WARNINGs instead of full WARNINGs, since the compiler doesn't
+  know whether the function will be redefined before the call is
+  executed. (The compiler could flag local calls with full WARNINGs,
+  as per the ANSI spec "3.2.2.3 Semantic Constraints", but right now
+  it doesn't keep track of enough information to know whether calls
+  are local in this sense.)
+* Compiler output is now more verbose, with messages truncated
+  later than before. (There should be some supported way for users
+  to override the default verbosity, but I haven't decided how to 
+  provide it yet, so this behavior is still controlled by the internal
+  SB-C::*COMPILER-ERROR-PRINT-FOO* variables in
+  src/compiler/ir1util.lisp.)
+* Fasl file format version numbers have increased again, because
+  support for the Gray streams extension changes the layout of the
+  system's STREAM objects.

 * The Gray subclassable streams extension now works, thanks to a 
   patch from Martin Atzmueller.
 * The full LOAD-FOREIGN extension (not just the primitive
 * The Gray subclassable streams extension now works, thanks to a 
   patch from Martin Atzmueller.
 * The full LOAD-FOREIGN extension (not just the primitive

@@ -650,19 +674,12 @@ changes in sbcl-0.6.11 relative to sbcl-0.6.10:
   but like most other programs, it defaults to copying the Unix
   environment from the original process instead of starting the
   new process in an empty environment.
   but like most other programs, it defaults to copying the Unix
   environment from the original process instead of starting the
   new process in an empty environment.

-* fixed bug 40: TYPEP, SUBTYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, 
-  and UPGRADED-COMPLEX-PART-TYPE now work better with of compound
-  types built from undefined types, e.g. '(VECTOR SOME-UNDEF-TYPE).

 * Extensions which manipulate the Unix environment now support
   an :ENVIRONMENT keyword option which doesn't smash case or 
   do other bad things. The CMU-CL-style :ENV option is retained
   for porting convenience.
 * LOAD-FOREIGN (and LOAD-1-FOREIGN) now support logical pathnames,
   as per Daniel Barlow's suggestion and Martin Atzmueller's patch
 * Extensions which manipulate the Unix environment now support
   an :ENVIRONMENT keyword option which doesn't smash case or 
   do other bad things. The CMU-CL-style :ENV option is retained
   for porting convenience.
 * LOAD-FOREIGN (and LOAD-1-FOREIGN) now support logical pathnames,
   as per Daniel Barlow's suggestion and Martin Atzmueller's patch

-* DESCRIBE now works on structure objects again.
-* Fasl file format version numbers have increased again, because
-  support for the Gray streams extension changes the format of the
-  system's stream objects.

 
 planned incompatible changes in 0.7.x:
 * The debugger prompt sequence now goes "5]", "5[2]", "5[3]", etc.
 
 planned incompatible changes in 0.7.x:
 * The debugger prompt sequence now goes "5]", "5[2]", "5[3]", etc.

@@ -673,4 +690,5 @@ planned incompatible changes in 0.7.x:
 * 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
 * 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.)
+  matter, though, unless you are using profiling. If you never 
+  profile anything, TRACE should continue to behave as before.)