* A patch from Martin Atzmueller seems to have solved the SIGINT
problem, and as far as we know, signal-handling now works cleanly.
(If you find any new bugs, please report them!)
+* The system no longer defaults Lisp source file names to types
+ ".l", ".cl", or ".lsp", but only to ".lisp".
+* The compiler no longer uses special default file extensions for
+ byte-compiled code. (The ANSI definition of COMPILE-FILE-PATHNAME
+ seems to expect a single default extension for all compiled code,
+ and there's no compelling reason to try to stretch the standard
+ to allow two different extensions.) Instead, byte-compiled files
+ default to the same extension as native-compiled files.
+* 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.
+* 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.
+* 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.
planned incompatible changes in 0.7.x:
* The debugger prompt sequence now goes "5]", "5[2]", "5[3]", etc.
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.)