-for late 0.7.x:
+planned incompatible changes in 0.8.x:
+ * (not done yet, but planned:) 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.)
+ * (not done yet, but planned:) Inlining can now be controlled the
+ ANSI way, without MAYBE-INLINE, since the idiom
+ (DECLAIM (INLINE FOO))
+ (DEFUN FOO (..) ..)
+ (DECLAIM (NOTINLINE FOO))
+ (DEFUN BAR (..) (FOO ..))
+ (DEFUN BLETCH (..) (DECLARE (INLINE FOO)) (FOO ..))
+ now does what ANSI says it should. The CMU-CL-style
+ SB-EXT:MAYBE-INLINE declaration is now deprecated and ignored.
+
+for early 0.8.x:
* test file reworking
- ** non-x86 ports now pass irrat.pure.lisp
** ports with less than 256Mb of heap (sparc, ppc and mips)
now don't fail bit-vector.impure-cload.lisp
* faster bootstrapping (both make.sh and slam.sh)
* fixups now feasible because of pre7 changes
** ANSIfied DECLAIM INLINE stuff (deprecating MAYBE-INLINE,
including e.g. on the man page)
+ ** (maybe) allow INLINE of a recursive function, so that the
+ body is inlined once
* miscellaneous simple refactoring
* belated renaming:
** renamed %PRIMITIVE to %VOP
** A few hundred things named FN and FCN should be
- named FUN (but maybe not while dan_b is
- working on a threads branch and drichards is
+ named FUN (but maybe not while drichards is
working on a Windows port).
* These days ANSI C has inline functions, so..
** redid many cpp macros as inline functions:
* Either get rid of or at least rework the fdefinition/encapsulation
system so that (SYMBOL-FUNCTION 'FOO) is identically equal to
(FDEFINITION 'FOO).
+* Make the system sources understandable to the system, so that
+ searching for sources doesn't error out quite so often
+ (e.g. in error handlers)
+ ** provided a suitable readtable for reading in the source
+ files when necessary, and a mechanism for activating
+ this readtable rather than the standard one.
+* Some work on conditions emitted by the system
+ ** eliminated COMPILER-WARN and COMPILER-STYLE-WARN, which
+ were simply limited versions of WARN and STYLE-WARN.
+ ** made STYLE-WARN parallel WARN more closely (by accepting
+ a condition type, which should be a subtype of
+ STYLE-WARNING, and initargs, as well as a format
+ string and format arguments for SIMPLE-STYLE-WARNING.
+ (WARN can also be used to signal STYLE-WARNINGs, but
+ STYLE-WARN helps to document the code)
+ ** eliminated use of INHIBIT-WARNINGS by code emitted by the
+ system from user code.
+ ** caused use of INHIBIT-WARNINGS to signal a STYLE-WARNING.
+ ** eliminated use of INHIBIT-WARNINGS within the system
+ ** deprecated INHIBIT-WARNINGS, causing its use to signal a
+ full WARNING.
+ ** began work on developing a class hierarchy of conditions
+ along semantic lines.
+ ** annotated conditions emitted by the system to have
+ references to documentation where applicable, so that
+ users can easily find an explanation for the
+ conditions they're seeing.
+
=======================================================================
for 0.9:
personal itch): I don't want socket-level stuff so much as I
want RPC-level or higher (CORBA?) interfaces and (possibly
through RPC or CORBA) GUI support
+* Especially when ldb is not compiled in, the default "assertion failed"
+ behaviour in many parts of the runtime is unfriendly. It may
+ be appropriate to look at some of these and see if they can be
+ handled in some less abrupt way than aborting
=======================================================================
important but out of scope (for WHN, anyway: Patches from other people
are still welcome!) until after 1.0: