X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=TODO;h=0dde9c9e48ae4dc6a753a99eda91e9b407f81c74;hb=17532463fa19f2fc2aba53b65c32e200a27ccd6a;hp=05eb79d59486877b261c218539e41154d6877769;hpb=b1abaa98c141c3f9baceb1185086fde7b5256e98;p=sbcl.git diff --git a/TODO b/TODO index 05eb79d..0dde9c9 100644 --- a/TODO +++ b/TODO @@ -1,20 +1,25 @@ -for early 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. -* patches postponed until after 0.7.0: - ** CSR "rough patch to fix bug 106" 2001-10-28 - ** Alexey Dejneka "bug 111" 2001-12-30 -* building with CLISP (or explaining why not). This will likely involve - a rearrangement of the build system so that it never renames - the output from COMPILE-FILE, because CLISP's COMPILE-FILE - outputs two (!) files and as far as I can tell LOAD uses both - of them. Since I have other motivations for this rearrangement - besides CLISPiosyncrasies, I'm reasonably motivated to do it. -* urgent EVAL/EVAL-WHEN/%COMPILE/DEFUN/DEFSTRUCT cleanup: - ** made inlining DEFUN inside MACROLET work again - ** (also, while working on INLINE anyway, it should be easy - to flush the old MAYBE-INLINE cruft entirely, - including e.g. on the man page) - ** fixed bug 137 (more) +for early 0.8.x: + +* test file reworking + ** 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) ** added mechanisms for automatically finding dead code, and used them to remove dead code @@ -22,6 +27,7 @@ for early 0.7.x: (so that slam.sh will run faster and also just because ideally everything would be in cold init) ** profiled and tweaked +* fixed (TRACE :REPORT PROFILE ...) interface to profiling * more EVAL/EVAL-WHEN/%COMPILE/DEFUN/DEFSTRUCT cleanup: ** made %COMPILE understand magicality of DEFUN FOO w.r.t. e.g. preexisting inlineness of FOO @@ -35,32 +41,24 @@ for early 0.7.x: are now implemented as closures (because they're structure slot accessors) won't be so nasty in the debugger - ** %SLOT-ACCESSOR/%SLOT-ACCESSOR stuff can probably go away, - since we inline expand all slot accessors into - %INSTANCE-REF and the optimizer knows all it needs - to know about that. -* rewrote long-standing confusing error restarts for redefining - DEFSTRUCTs * outstanding embarrassments - ** cut-and-pasted DEF-BOOLEAN-ATTRIBUTE (maybe easier to fix - now that EVAL-WHEN does what it should..) - ** incomplete manual ** :IGNORE-ERRORS-P cruft in stems-and-flags.lisp-expr. (It's reasonable to support this as a crutch when initially bootstrapping from balky xc hosts with their own idiosyncratic ideas of what merits FAILURE-P, but it's embarrassing to have to use it when bootstrapping under SBCL!), - ** weird double-loading (first in GENESIS, then in warm init) - of src/assembly/target/*.lisp stuff, and the associated - weirdness of the half-baked state (compiler almost but - not quite ready for prime time..) of the system after - cold init * fixups now feasible because of pre7 changes - ** ANSIfied DECLAIM INLINE stuff (deprecating MAYBE-INLINE) + ** 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 drichards is + working on a Windows port). * These days ANSI C has inline functions, so.. ** redid many cpp macros as inline functions: HeaderValue, Pointerp, CEILING, ALIGNED_SIZE, @@ -69,25 +67,54 @@ for early 0.7.x: os_trunc_foo(), os_round_up_foo() ** removed various avoid-evaluating-C-macro-arg-twice cruft -* added mechanisms for automatically finding dead symbols is - package-data.lisp-expr (i.e. those symbols not bound, - fbound, defined as types, or whatever), and used them - to remove dead symbols -* made system handle stack overflow safely unless SAFETY is dominated - by SPEED or SPACE * 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: +[ note: much of the below refers to preparation for merging SB-PCL:FOO + and CL:FOO. However, it turned out to be surprisingly + straightforward to do this notional end goal without doing many of + the preparatory operations. That doesn't mean that plenty of the + goals below aren't worthwhile, but the motivation is somewhat + different. ] + * refactored in preparation for moving CLOS into cold init and merging SB-PCL:FOO with CL:FOO (for FOO=CLASS, FOO=CLASS-OF, etc.) - ** systematized support for MOP (new regression tests, maybe - new SB-MOP package..) to try to make sure things don't - get mislaid in the upcoming CLOS restructuring - ** extracted type system from SB-KERNEL into new SB-TYPE - package + ** systematized support for MOP (more regression tests, maybe) + to try to make sure things don't get mislaid in the + upcoming CLOS restructuring + ** extracted type system (and maybe CLASSOIDs) from SB-KERNEL + into new SB-TYPE package ** reimplemented GENERIC-FUNCTION as a primitive object (or maybe made SB-MOP:FUNCALLABLE-STANDARD-OBJECT the primitive object, and then let GENERIC-FUNCTIONs @@ -118,7 +145,6 @@ for 0.9: * (maybe) more refactoring in preparation for merging SB-PCL:FOO into CL:FOO: reimplemented type system OO dispatch (!DEFINE-TYPE-METHOD, etc.) in terms of CLOS OO dispatch -* merged SB-PCL:FOO into CL:FOO (and similarly CLASS-OF, etc.) * added some automatic tests for basic binary compatibility, in hopes that it might be practical to maintain binary compatibility between minor maintenance releases on the stable branch (but no @@ -138,6 +164,10 @@ other priorities, no particular time: 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: @@ -154,7 +184,7 @@ are still welcome!) until after 1.0: out of scope. (However, it still might be possible to determine that some or all of them are hopelessly stale and delete them.) -=============================================================================== +======================================================================= other known issues with no particular target date: bugs listed on the man page