X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=NEWS;h=3b5fbdf694208f5b1b8804d0f123e18d5a9910e9;hb=21223eedf790450dc484907c2bedf2b9bdaa80bf;hp=41306349b1eab4f6edc8b83ebd074a7d90d30d5b;hpb=99ad0a384664dc98af26245a33f11619ec0854ad;p=sbcl.git

diff --git a/NEWS b/NEWS
index 4130634..3b5fbdf 100644
--- a/NEWS
+++ b/NEWS
@@ -626,21 +626,69 @@ changes in sbcl-0.6.10 relative to sbcl-0.6.9:
 * Fasl file format version numbers have increased again, because
   a rearrangement of internal implementation packages made some 
   dumped symbols in old fasl files unreadable in new cores.
-?? (DECLAIM (OPTIMIZE ..)) now works.
 * DECLARE/DECLAIM/PROCLAIM logic is more nearly ANSI in general, with
   many fewer weird special cases.
 * Bug #17 (differing COMPILE-FILE behavior between logical and 
   physical pathnames) has been fixed, and some related misbehavior too,
   thanks to a patch from Martin Atzmueller.
-?? #'(SETF DOCUMENTATION) is now defined.
+* Bug #30 (reader problems) is gone, thanks to a CMU CL patch
+  by Tim Moore, ported to SBCL by Martin Atzmueller.
+* Martin Atzmueller fixed several filesystem-related problems,
+  including bug #36, in part by porting CMU CL patches, which were
+  written in part by Paul Werkowski.
 * More compiler warnings in src/runtime/ are gone, thanks to 
-  patches from Martin Atzmueller.
+  more patches from Martin Atzmueller.
 * Martin Atzmueller pointed out that bug 37 was fixed by his patches
   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
+  LOAD-FOREIGN-1) now works, thanks to a patch from Martin Atzmueller.
+* The default behavior of RUN-PROGRAM has changed. Now, unlike CMU CL
+  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.
+* 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
+
 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.)