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
forever, even when it is uninterned and all other references to it
are lost.
-141: "pretty printing and backquote"
- a.
- * '``(FOO ,@',@S)
- ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
-
- c. (reported by Paul F. Dietz)
- * '`(lambda ,x)
- `(LAMBDA (SB-IMPL::BACKQ-COMMA X))
-
143:
(reported by Jesse Bouwman 2001-10-24 through the unfortunately
prominent SourceForge web/db bug tracking system, which is
(fixed in 0.8.2.51, but a test case would be good)
-276:
- (defmethod fee ((x fixnum))
- (setq x (/ x 2))
- x)
- (fee 1) => type error
-
- (taken from CLOCC)
-
278:
a.
(defun foo ()
(let ((tsos (make-string-output-stream))
(ssos (make-string-output-stream)))
(let ((*print-circle* t)
- (*trace-output* tsos)
- (*standard-output* ssos))
+ (*trace-output* tsos)
+ (*standard-output* ssos))
(prin1 *tangle* *standard-output*))
(let ((string (get-output-stream-string ssos)))
(unless (string= string "(#1=[FOO 4] #S(BAR) #1#)")
;; In sbcl-0.8.10.48 STRING was "(#1=[FOO 4] #2# #1#)".:-(
- (error "oops: ~S" string))))
+ (error "oops: ~S" string)))))
It might be straightforward to fix this by turning the
*CIRCULARITY-HASH-TABLE* and *CIRCULARITY-COUNTER* variables into
per-stream slots, but (1) it would probably be sort of messy faking
when called with arguments
(NIL).
-335: "ATANH completely broken"
- a. (reported by Peter Graves sbcl-devel 2004-06-01)
- (atanh #c(1 2)), and more generally atanh of any complex with real
- part 1, computes entirely the wrong answer.
- b. (discovered by CSR when investigating a.)
- (atanh most-positive-double-float), and more generally atanh of any
- number with magnitude larger than
- sqrt(most-positive-double-float), computes a number whose real
- part is the imaginary part of the correct answer, and whose
- imaginary part is the real part of the correct answer.
- (fixes for both of these were sent CSR sbcl-devel 2004-06-02, to be merged
- post-0.8.11)
-
336: "slot-definitions must retain the generic functions of accessors"
reported by Tony Martinez:
(defclass foo () ((bar :reader foo-bar)))
Fixing this should also fix a subset of #328 -- update the
description with a new test-case then.
+
+337: MAKE-METHOD and user-defined method classes
+ (reported by Bruno Haible sbcl-devel 2004-06-11)
+
+ In the presence of
+
+(defclass user-method (standard-method) (myslot))
+(defmacro def-user-method (name &rest rest)
+ (let* ((lambdalist-position (position-if #'listp rest))
+ (qualifiers (subseq rest 0 lambdalist-position))
+ (lambdalist (elt rest lambdalist-position))
+ (body (subseq rest (+ lambdalist-position 1)))
+ (required-part
+ (subseq lambdalist 0 (or
+ (position-if
+ (lambda (x) (member x lambda-list-keywords))
+ lambdalist)
+ (length lambdalist))))
+ (specializers (mapcar #'find-class
+ (mapcar (lambda (x) (if (consp x) (second x) t))
+ required-part)))
+ (unspecialized-required-part
+ (mapcar (lambda (x) (if (consp x) (first x) x)) required-part))
+ (unspecialized-lambdalist
+ (append unspecialized-required-part
+ (subseq lambdalist (length required-part)))))
+ `(PROGN
+ (ADD-METHOD #',name
+ (MAKE-INSTANCE 'USER-METHOD
+ :QUALIFIERS ',qualifiers
+ :LAMBDA-LIST ',unspecialized-lambdalist
+ :SPECIALIZERS ',specializers
+ :FUNCTION
+ (LAMBDA (ARGUMENTS NEXT-METHODS-LIST)
+ (FLET ((NEXT-METHOD-P () NEXT-METHODS-LIST)
+ (CALL-NEXT-METHOD (&REST NEW-ARGUMENTS)
+ (UNLESS NEW-ARGUMENTS (SETQ NEW-ARGUMENTS ARGUMENTS))
+ (IF (NULL NEXT-METHODS-LIST)
+ (ERROR "no next method for arguments ~:S" ARGUMENTS)
+ (FUNCALL (SB-PCL:METHOD-FUNCTION
+ (FIRST NEXT-METHODS-LIST))
+ NEW-ARGUMENTS (REST NEXT-METHODS-LIST)))))
+ (APPLY #'(LAMBDA ,unspecialized-lambdalist ,@body) ARGUMENTS)))))
+ ',name)))
+
+ (progn
+ (defgeneric test-um03 (x))
+ (defmethod test-um03 ((x integer))
+ (list* 'integer x (not (null (next-method-p))) (call-next-method)))
+ (def-user-method test-um03 ((x rational))
+ (list* 'rational x (not (null (next-method-p))) (call-next-method)))
+ (defmethod test-um03 ((x real))
+ (list 'real x (not (null (next-method-p)))))
+ (test-um03 17))
+ works, but
+
+ a.(progn
+ (defgeneric test-um10 (x))
+ (defmethod test-um10 ((x integer))
+ (list* 'integer x (not (null (next-method-p))) (call-next-method)))
+ (defmethod test-um10 ((x rational))
+ (list* 'rational x (not (null (next-method-p))) (call-next-method)))
+ (defmethod test-um10 ((x real))
+ (list 'real x (not (null (next-method-p)))))
+ (defmethod test-um10 :after ((x real)))
+ (def-user-method test-um10 :around ((x integer))
+ (list* 'around-integer x
+ (not (null (next-method-p))) (call-next-method)))
+ (defmethod test-um10 :around ((x rational))
+ (list* 'around-rational x
+ (not (null (next-method-p))) (call-next-method)))
+ (defmethod test-um10 :around ((x real))
+ (list* 'around-real x (not (null (next-method-p))) (call-next-method)))
+ (test-um10 17))
+ fails with a type error, and
+
+ b.(progn
+ (defgeneric test-um12 (x))
+ (defmethod test-um12 ((x integer))
+ (list* 'integer x (not (null (next-method-p))) (call-next-method)))
+ (defmethod test-um12 ((x rational))
+ (list* 'rational x (not (null (next-method-p))) (call-next-method)))
+ (defmethod test-um12 ((x real))
+ (list 'real x (not (null (next-method-p)))))
+ (defmethod test-um12 :after ((x real)))
+ (defmethod test-um12 :around ((x integer))
+ (list* 'around-integer x
+ (not (null (next-method-p))) (call-next-method)))
+ (defmethod test-um12 :around ((x rational))
+ (list* 'around-rational x
+ (not (null (next-method-p))) (call-next-method)))
+ (def-user-method test-um12 :around ((x real))
+ (list* 'around-real x (not (null (next-method-p))) (call-next-method)))
+ (test-um12 17))
+ fails with NO-APPLICABLE-METHOD.
+
+338: "MOP specializers as type specifiers"
+ (reported by Bruno Haible sbcl-devel 2004-06-11)
+
+ ANSI 7.6.2 says:
+ Because every valid parameter specializer is also a valid type
+ specifier, the function typep can be used during method selection
+ to determine whether an argument satisfies a parameter
+ specializer.
+
+ however, SBCL's EQL specializers are not type specifiers:
+ (defmethod foo ((x (eql 4.0))) 3.0)
+ (typep 1 (first (sb-pcl:method-specializers *)))
+ gives an error.
projects / sbcl.git / blobdiff