X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=3385eaa43eb628132250a2c35d513751be161ba2;hb=3a618201c9f2370bb8784217a866d000371769e5;hp=6ec74abd6c0f6e2e7be6f91a07b1e84a37e1a633;hpb=175c81b8044d7210e08ac66690c9392ec8d19b21;p=sbcl.git diff --git a/BUGS b/BUGS index 6ec74ab..3385eaa 100644 --- a/BUGS +++ b/BUGS @@ -89,15 +89,6 @@ WORKAROUND: Perhaps any number of such consecutive lines ought to turn into a single "compiling top-level forms:" line. -11: - It would be nice if the - caught ERROR: - (during macroexpansion) - said what macroexpansion was at fault, e.g. - caught ERROR: - (during macroexpansion of IN-PACKAGE, - during macroexpansion of DEFFOO) - 19: (I *think* this is a bug. It certainly seems like strange behavior. But the ANSI spec is scary, dark, and deep.. -- WHN) @@ -165,25 +156,6 @@ WORKAROUND: so they could be supported after all. Very likely SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too. -45: - a slew of floating-point-related errors reported by Peter Van Eynde - on July 25, 2000: - c: Many expressions generate floating infinity on x86/Linux: - (/ 1 0.0) - (/ 1 0.0d0) - (EXPT 10.0 1000) - (EXPT 10.0d0 1000) - PVE's regression tests want them to raise errors. sbcl-0.7.0.5 - on x86/Linux generates the infinities instead. That might or - might not be conforming behavior, but it's also inconsistent, - which is almost certainly wrong. (Inconsistency: (/ 1 0.0) - should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0) - generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0) - signals an error. - d: (in section12.erg) various forms a la - (FLOAT 1 DOUBLE-FLOAT-EPSILON) - don't give the right behavior. - 60: The debugger LIST-LOCATIONS command doesn't work properly. (How should it work properly?) @@ -368,34 +340,6 @@ WORKAROUND: (see also bug 279) -118: - as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14: - (= (FLOAT 1 DOUBLE-FLOAT-EPSILON) - (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T - when of course it should be NIL. (He says it only fails for X86, - not SPARC; dunno about Alpha.) - - Also, "the same problem exists for LONG-FLOAT-EPSILON, - DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though - for the -negative- the + is replaced by a - in the test)." - - Raymond Toy comments that this is tricky on the X86 since its FPU - uses 80-bit precision internally. - - Bruno Haible comments: - The values are those that are expected for an IEEE double-float - arithmetic. The problem appears to be that the rounding is not - IEEE on x86 compliant: namely, values are first rounded to 64 - bits mantissa precision, then only to 53 bits mantissa - precision. This gives different results than rounding to 53 bits - mantissa precision in a single step. - - The quick "fix", to permanently change the FPU control word from - 0x037f to 0x027f, will give problems with the fdlibm code that is - used for computing transcendental functions like sinh() etc. - so maybe we need to change the FPU control word to that for Lisp - code, and adjust it to the safe 0x037f for calls to C? - 124: As of version 0.pre7.14, SBCL's implementation of MACROLET makes the entire lexical environment at the point of MACROLET available @@ -861,18 +805,6 @@ WORKAROUND: ; compilation unit finished ; printed 1 note -241: "DEFCLASS mysteriously remembers uninterned accessor names." - (from tonyms on #lisp IRC 2003-02-25) - In sbcl-0.7.12.55, typing - (defclass foo () ((bar :accessor foo-bar))) - (profile foo-bar) - (unintern 'foo-bar) - (defclass foo () ((bar :accessor foo-bar))) - gives the error message - "#:FOO-BAR already names an ordinary function or a macro." - So it's somehow checking the uninterned old accessor name instead - of the new requested accessor name, which seems broken to me (WHN). - 242: "WRITE-SEQUENCE suboptimality" (observed from clx performance) In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type @@ -1314,23 +1246,6 @@ WORKAROUND: Expected: (2 6 15 38) Got: ERROR -315: "no bounds check for access to displaced array" - reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP - test suite. - (locally (declare (optimize (safety 3) (speed 0))) - (let* ((x (make-array 10 :fill-pointer 4 :element-type 'character - :initial-element #\space :adjustable t)) - (y (make-array 10 :fill-pointer 4 :element-type 'character - :displaced-to x))) - (adjust-array x '(5)) - (char y 5))) - - SBCL 0.8.10 elides the bounds check somewhere along the line, and - returns #\Nul (where an error would be much preferable, since a test - of that form but with (setf (char y 5) #\Space) potentially corrupts - the heap and certainly confuses the world if that string is used by - C code. - 317: "FORMAT of floating point numbers" reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP test suite. @@ -1433,18 +1348,122 @@ WORKAROUND: (2) it might be sort of a pain to test that no other bugs had been introduced. -327: "Lazy construction of CLOS classes from system classoids" - In a fresh SBCL, - (sb-mop:class-direct-subclasses (find-class 'pathname)) - returns NIL, despite the LOGICAL-PATHNAME class existing. However, - if we then do (find-class 'logical-pathname) and repeat the request - for direct subclasses, a list of the logical pathname class is - returned. (Though this particular example revealed the problem to - CSR, others have found that this gave consistent results for - PATHNAME, but not for SIMPLE-CONDITION.) - - Presumably the CLOS bootstrap process needs to iterate over - classoids (both structure- and condition-) to create CLOS classes - for them, so that this internal inconsistency does not arise? How - does this interact with the classoid hierarchy not perfectly - mirroring the class hierarchy? (e.g. INSTANCE?) +328: "Profiling generic functions", transplanted from #241 + (from tonyms on #lisp IRC 2003-02-25) + In sbcl-0.7.12.55, typing + (defclass foo () ((bar :accessor foo-bar))) + (profile foo-bar) + (unintern 'foo-bar) + (defclass foo () ((bar :accessor foo-bar))) + gives the error message + "#:FOO-BAR already names an ordinary function or a macro." + + Problem: when a generic function is profiled, it appears as an ordinary + function to PCL. (Remembering the uninterned accessor is OK, as the + redefinition must be able to remove old accessors from their generic + functions.) + +329: "Sequential class redefinition" + reported by Bruno Haible: + (defclass reactor () ((max-temp :initform 10000000))) + (defvar *r1* (make-instance 'reactor)) + (defvar *r2* (make-instance 'reactor)) + (slot-value *r1* 'max-temp) + (slot-value *r2* 'max-temp) + (defclass reactor () ((uptime :initform 0))) + (slot-value *r1* 'uptime) + (defclass reactor () ((uptime :initform 0) (max-temp :initform 10000))) + (slot-value *r1* 'max-temp) ; => 10000 + (slot-value *r2* 'max-temp) ; => 10000000 oops... + + Possible solution: + The method effective when the wrapper is obsoleted can be saved + in the wrapper, and then to update the instance just run through + all the old wrappers in order from oldest to newest. + +331: "lazy creation of CLOS classes for user-defined conditions" + (defstruct foo) + (defstruct (bar (:include foo))) + (sb-mop:class-direct-subclasses (find-class 'foo)) + returns NIL, rather than a singleton list containing the BAR class. + +332: "fasl stack inconsistency in structure redefinition" + (reported by Tim Daly Jr sbcl-devel 2004-05-06) + Even though structure redefinition is undefined by the standard, the + following behaviour is suboptimal: running + (defun stimulate-sbcl () + (let ((filename (format nil "/tmp/~A.lisp" (gensym)))) + ;;create a file which redefines a structure incompatibly + (with-open-file (f filename :direction :output :if-exists :supersede) + (print '(defstruct astruct foo) f) + (print '(defstruct astruct foo bar) f)) + ;;compile and load the file, then invoke the continue restart on + ;;the structure redefinition error + (handler-bind ((error (lambda (c) (continue c)))) + (load (compile-file filename))))) + (stimulate-sbcl) + and choosing the CONTINUE restart yields the message + debugger invoked on a SB-INT:BUG in thread 27726: + fasl stack not empty when it should be + +333: "CHECK-TYPE TYPE-ERROR-DATUM place" + (reported by Tony Martinez sbcl-devel 2004-05-23) + When CHECK-TYPE signals a TYPE-ERROR, the TYPE-ERROR-DATUM holds the + lisp symbolic place in question rather than the place's value. This + seems wrong. + +334: "COMPUTE-SLOTS used to add slots to classes" + (reported by Bruno Haible sbcl-devel 2004-06-01) + a. Adding a local slot does not work: + (use-package "SB-PCL") + (defclass b (a) ()) + (defmethod compute-slots ((class (eql (find-class 'b)))) + (append (call-next-method) + (list (make-instance 'standard-effective-slot-definition + :name 'y + :allocation :instance)))) + (defclass a () ((x :allocation :class))) + ;; A should now have a shared slot, X, and a local slot, Y. + (mapcar #'slot-definition-location (class-slots (find-class 'b))) + yields + There is no applicable method for the generic function + # + when called with arguments + (NIL). + + b. Adding a class slot does not work: + (use-package "SB-PCL") + (defclass b (a) ()) + (defmethod compute-slots ((class (eql (find-class 'b)))) + (append (call-next-method) + (list (make-instance 'standard-effective-slot-definition + :name 'y + :allocation :class)))) + (defclass a () ((x :allocation :class))) + ;; A should now have two shared slots, X and Y. + (mapcar #'slot-definition-location (class-slots (find-class 'b))) + yields + There is no applicable method for the generic function + # + when called with arguments + (NIL). + +336: "slot-definitions must retain the generic functions of accessors" + reported by Tony Martinez: + (defclass foo () ((bar :reader foo-bar))) + (defun foo-bar (x) x) + (defclass foo () ((bar :reader get-bar))) ; => error, should work + + Note: just punting the accessor removal if the fdefinition + is not a generic function is not enough: + + (defclass foo () ((bar :reader foo-bar))) + (defvar *reader* #'foo-bar) + (defun foo-bar (x) x) + (defclass foo () ((bar :initform 'ok :reader get-bar))) + (funcall *reader* (make-instance 'foo)) ; should be an error, since + ; the method must be removed + ; by the class redefinition + + Fixing this should also fix a subset of #328 -- update the + description with a new test-case then.