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)
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?)
(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
; 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
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 fails this because (array-dimension y 0) return 10 even after the
- adjustment, and hence the bounds-check passes. This is strictly
- speaking legal, since the dictionary entry for ADJUST-ARRAY
- says:
-
- "If A is displaced to B, the consequences are unspecified if B is
- adjusted in such a way that it no longer has enough elements to
- satisfy A."
-
- Should this be left as is, or should ARRAY-DIMENSION see if the
- displaced-to array has shrunk too much and signal an error? An error
- would probably be 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.
(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
+ #<STANDARD-GENERIC-FUNCTION CLASS-SLOTS (3)>
+ 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
+ #<STANDARD-GENERIC-FUNCTION SB-PCL::CLASS-SLOT-CELLS (1)>
+ 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.
projects / sbcl.git / blobdiff