From: Bruno H. <br...@cl...> - 2004-04-19 20:15:58
|
The print-read consistency for floating-point numbers is violated: With double-float: * (multiple-value-bind (i x) (FLOOR -4.8298889769606521412d19 3.2897859420995047714d19) (let ((y (read-from-string (write-to-string x :readably t)))) (eql x y))) Expected: T Got: NIL * (let ((x (/ -9.349640046247849d-21 -9.381494249123696d-11))) (let ((y (read-from-string (write-to-string x :readably t)))) (eql x y))) Expected: T Got: NIL With single-float: * (let ((x (/ -7.945299e-4 -5.496527e-11))) (let ((y (read-from-string (write-to-string x :readably t)))) (eql x y))) Expected: T Got: NIL [Taken from clisp's number.tst] [Bug also present in CMUCL 18e] Platform: Linux/x86. SBCL version: 0.8.9 compiled by CMUCL 18e. |
From: Christophe R. <cs...@ca...> - 2004-04-19 21:05:27
|
Bruno Haible <br...@cl...> writes: > The print-read consistency for floating-point numbers is violated: Yep. This shows up also in Paul Dietz' PRINT.SHORT-FLOAT.RANDOM [and single-, double- and long- variants ]. I'm afraid I don't even know if the bug is in the printer or the reader (or both) :-/ Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: David S. <da...@da...> - 2004-04-19 21:32:14
|
Christophe Rhodes <cs...@ca...> writes: > Bruno Haible <br...@cl...> writes: > > > The print-read consistency for floating-point numbers is violated: > > Yep. This shows up also in Paul Dietz' PRINT.SHORT-FLOAT.RANDOM [and > single-, double- and long- variants ]. I'm afraid I don't even know > if the bug is in the printer or the reader (or both) :-/ Might that simply be an artifact of either Intel's FPU or IEEE-754? Those numbers didn't look like they had an exact binary representation. Surely once the reader stuffs the number into a double, the string representation will be lost information. I seem to recall that the Intel hardware supports BCD, but I doubt you want to go down that road. IIRC, that's an 80bit representation (the size of the FPU registers) rather than 32bit float or 64bit double. Just a thought. -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. |
From: Michael H. <mw...@py...> - 2004-04-20 11:15:23
|
David Steuber <da...@da...> writes: > Christophe Rhodes <cs...@ca...> writes: > >> Bruno Haible <br...@cl...> writes: >> >> > The print-read consistency for floating-point numbers is violated: >> >> Yep. This shows up also in Paul Dietz' PRINT.SHORT-FLOAT.RANDOM [and >> single-, double- and long- variants ]. I'm afraid I don't even know >> if the bug is in the printer or the reader (or both) :-/ > > Might that simply be an artifact of either Intel's FPU or IEEE-754? > Those numbers didn't look like they had an exact binary > representation. Surely once the reader stuffs the number into a > double, the string representation will be lost information. That's not the point: you woudn't expect string->double->string to be the identity transform, but you would hope that double->string->double was. Cheers, mwh -- Its unmanageable complexity has spawned more fear-preventing tools than any other language, but the solution _should_ have been to create and use a language that does not overload the whole goddamn human brain with irrelevant details. -- Erik Naggum, comp.lang.lisp |
From: David S. <da...@da...> - 2004-04-20 20:50:45
|
Michael Hudson <mw...@py...> writes: > David Steuber <da...@da...> writes: > > > Christophe Rhodes <cs...@ca...> writes: > > > >> Bruno Haible <br...@cl...> writes: > >> > >> > The print-read consistency for floating-point numbers is violated: > >> > >> Yep. This shows up also in Paul Dietz' PRINT.SHORT-FLOAT.RANDOM [and > >> single-, double- and long- variants ]. I'm afraid I don't even know > >> if the bug is in the printer or the reader (or both) :-/ > > > > Might that simply be an artifact of either Intel's FPU or IEEE-754? > > Those numbers didn't look like they had an exact binary > > representation. Surely once the reader stuffs the number into a > > double, the string representation will be lost information. > > That's not the point: you woudn't expect string->double->string to be > the identity transform, but you would hope that double->string->double > was. I guess I missed something. You are absolutely right about what I would expect and hope for. -- I wouldn't mind the rat race so much if it wasn't for all the damn cats. |
From: Bruno H. <br...@cl...> - 2004-04-20 11:48:16
|
Christophe Rhodes wrote: > I'm afraid I don't even know > if the bug is in the printer or the reader (or both) :-/ It's at least in the printer. Look: (setq x1 (float -5496527/100000000000000000)) (setq x2 (float -54965272/1000000000000000000)) (integer-decode-float x1) => 15842660 -58 -1 (integer-decode-float x2) => 15842661 -58 -1 (prin1-to-string x1) => "-5.496527e-11" But: (prin1-to-string x2) => "-5.496527e-11" This is the bug. Since (/= x2 x1), its printed representation should be "-5.4965272e-11" Bruno |
From: David L. <da...@li...> - 2004-04-20 12:55:31
|
Quoting Bruno Haible (br...@cl...): > Christophe Rhodes wrote: > > I'm afraid I don't even know > > if the bug is in the printer or the reader (or both) :-/ >=20 > It's at least in the printer. Look: Right, and as I understand the comments, it is even a `known' problem. SCALE-EXPONENT in print.lisp is broken by design in an effort to make it faster: -------- ;;; NOTE: When a number is to be printed in exponential format, it is ;;; scaled in floating point. Since precision may be lost in this ;;; process, the guaranteed accuracy properties of FLONUM-TO-STRING ;;; are lost. -------- And indeed for the numbers from your first example: * (integer-decode-float (sb-impl::scale-exponent (long-to-double 4894948969= 267487952))) 6303897031244154 -55 1 * (integer-decode-float (sb-impl::scale-exponent (long-to-double 4894948969= 267487953))) 6303897031244154 -55 1 --=20 Common Lisp is the Borg of programming languages -- Bill Clementson |
From: Christophe R. <cs...@ca...> - 2004-05-05 10:10:10
|
Hi, Bruno sent me this list of bugs a few days ago. Since our private discussion seems to have died down, I thought I'd forward them to the list with a summary of our discussion (Bruno, feel free to leap back in if I mischaracterise your position -- and thank you for the complete and detailed reports and the useful discussions :-). Bruno Haible <br...@cl...> writes: > Platform: Linux/x86. SBCL version: 0.8.9 compiled by CMUCL 18e. > ============================================================================= > Subject: LOOP :INITIALLY clauses > > ;; reported by "Thomas F. Burdick" <tfb@OCF.Berkeley.EDU> > ;; <http://www.lisp.org/HyperSpec/Body/sec_6-1-7-2.html> > ;; According to the HyperSpec 6.1.2.1.4, in for-as-equals-then, var is > ;; initialized to the result of evaluating form1. 6.1.7.2 says that > ;; initially clauses are evaluated in the loop prologue, which precedes all > ;; loop code except for the initial settings provided by with, for, or as. > (loop :for x = 0 :then (1+ x) :for y = (1+ x) :then (ash y 1) > :for z :across #(1 3 9 27 81 243) :for w = (+ x y z) > :initially (assert (zerop x)) :initially (assert (= 2 w)) > :until (>= w 100) :collect w) > Expected: (2 6 15 38) > Got: ERROR > > [Taken from clisp's loop.tst] [Bug also present in CMUCL 18e] No discussion. I presume this is a bug, but my loop-fu is weak. > ============================================================================= > Subject: keyword argument determination > > CLHS 3.4.1.4 says that "If more than one such argument pair matches, the > leftmost argument pair is used". > > (defparameter x 1) > x > > (defun test-key () (find 1 #(0 1 2 3) :test #'= :test (incf x))) > test-key > > (list (test-key) x) > Expected: (1 2) > Got: ERROR > > [Taken from clisp's macro8.tst] I don't think this is a bug: I think callers are allowed to add assertions to arguments of built-in operators even if the argument is then subsequently not used. Bruno disagrees. > ============================================================================= > Subject: no bounds check for access to displaced array > > (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))) > Expected: ERROR > Got: #\Nul > > [Taken from clisp's strings.tst] [Bug also present in CMUCL 18e] Oh, this one's definitely a bug. > ============================================================================= > Subject: the (COMPLEX type) type > > The type specifier (COMPLEX type) should, according to ANSI CL's description > (HyperSpec/Body/syscla_complex.html), only depend on > (upgraded-complex-element-type type). > > * (upgraded-complex-part-type '(eql 0)) > > RATIONAL > * (upgraded-complex-part-type 'rational) > > RATIONAL > > Therefore the types (COMPLEX (EQL 0)) and (COMPLEX RATIONAL) should be the > same. But TYPEP doesn't work this way: > > * (typep #c(0 1) '(complex rational)) > > T > * (typep #c(0 1) '(complex (eql 0))) > > NIL > > And SUBTYPEP doesn't work this way either: > > * (subtypep '(complex rational) '(complex (eql 0))) > > NIL > T > > [Taken from clisp's type.tst] Fixed in sbcl-0.8.10.9 > ============================================================================= > Subject: SHIFTF and multiple values > > SHIFTF does not support forms that produce multiple values. But parts of the > explanation of SHIFTF in ANSI CL talk about multiple store variables, and > the X3J13 vote SETF-MULTIPLE-STORE-VARIABLES:ALLOW also says that SHIFTF > should support multiple value places. > > * (shiftf (values x y) (values y x)) > > debugger invoked on a SIMPLE-ERROR in thread 2522: > GET-SETF-METHOD used for a form with multiple store variables: > (VALUES X Y) > > [Taken from clisp's setf.tst] Dunno. Probably an arguable bug. > ============================================================================= > Subject: FORMAT of floating-point numbers > > * (FORMAT NIL "~1f" 10) > > "0." > * (FORMAT NIL "~0f" 10) > > "0." > > Expected "10." for both, according to ANSI CL 22.3.3.1. > > Similarly > * (FORMAT NIL "~2f" 1234567.1) > > "1000000." > > Expected "1234567." here. > > [Taken from clisp's format.tst] [Bug also present in CMUCL 18e] Well, sbcl's results here certainly need some explaining. Presumably a bug. > ============================================================================= > Subject: set-pprint-dispatch bug > > (progn > (defun my-pprint-reverse (out list) > (write-char #\( out) > (when (setq list (reverse list)) > (loop (write (pop list) :stream out) > (when (endp list) (return)) > (write-char #\Space out))) > (write-char #\) out)) > (let ((*print-pprint-dispatch* (copy-pprint-dispatch))) > (set-pprint-dispatch '(cons (member foo)) 'my-pprint-reverse 0) > (write-to-string '(foo bar :boo 1) :pretty t :escape t))) > Expected: "(1 :BOO BAR FOO)" > Got: "(FOO BAR :BOO 1)" > > [Taken from clisp's iofkts.tst] > ============================================================================= > Subject: set-pprint-dispatch bug > > (progn > (defun my-pprint-logical (out list) > (pprint-logical-block (out list :prefix "(" :suffix ")") > (when list > (loop (write-char #\? out) > (write (pprint-pop) :stream out) > (write-char #\? out) > (pprint-exit-if-list-exhausted) > (write-char #\Space out))))) > (let ((*print-pprint-dispatch* (copy-pprint-dispatch))) > (set-pprint-dispatch '(cons (member bar)) 'my-pprint-logical 0) > (write-to-string '(bar foo :boo 1) :pretty t :escape t))) > Expected: "(?BAR? ?FOO? ?:BOO? ?1?)" > Got: "(BAR FOO :BOO 1)" > > [Taken from clisp's iofkts.tst] These two were fixed in sbcl-0.8.10.8 by making WRITE-TO-STRING not FOLDABLE. > ============================================================================= > Subject: double-float-epsilon and rounding > > The values of {double,long}-float-{,negative-}epsilon look wrong: > > * (+ 1.0d0 double-float-epsilon) > > 1.0d0 > * (- 1.0d0 double-float-negative-epsilon) > > 1.0d0 > > 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. > > [Taken from clisp's floeps.tst] [Bug also present in CMUCL 18e] > [Looks like the same as bug #118 in sbcl/BUGS] This is indeed the same as bug #118 and also (possibly) #45d. Presumably what we have to do is to alter the control word while executing lisp code, and then restore it in call_into_c? > ============================================================================= > Subject: backquote-comma expression is printed differently > > * (write-to-string '``,,`,3) > > Expected: "``,,`,3" > Got: "3" > > [Taken from clisp's backquot.tst] [Bug also present in CMUCL 18e] I claim this is not a bug: implementations are allowed to optimize backquoted expressions at read-time. I haven't heard to the contrary from Bruno on this one, so I assume he agrees. > ============================================================================= > Subject: deadly stack overflow in compiler warning > > (setq *print-pretty* nil) > (defstruct foo a) > (setf (find-class 'foo) nil) > (defstruct foo slot-1) > > Here SBCL gives a warning/error message from which I can only see the tail: > #<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTURE-CLASSOID > #<SB-KERNEL:STRUCTURE-CLASSOID #<SB-KERNEL:STRUCTUREControl stack guard page temporarily disabled: proceed with caution > > There are several problems here: > 1) When SBCL decides to show me one of its internal data structures, and > it is a circular structure, it should turn on *print-circle* by itself, > instead of expecting that I have done it. > 2) After this error, the Lisp session is vowed for death: > If I type 0 and then (quit) to exit SBCL, I get > > 0] 0 > > * (quit) > > debugger invoked on a SIMPLE-ERROR in thread 2175: segmentation violation at #X8 > > You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > (no restarts: If you didn't do this on purpose, please report it as a bug.) > > debugger invoked on a TYPE-ERROR in thread 2175: > The value NIL is not of type SB-DI:FRAME. > > You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > (no restarts: If you didn't do this on purpose, please report it as a bug.) > > debugger invoked on a TYPE-ERROR in thread 2175: > The value NIL is not of type SB-DI:FRAME. > > You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > (no restarts: If you didn't do this on purpose, please report it as a bug.) > > debugger invoked on a TYPE-ERROR in thread 2175: > The value NIL is not of type SB-DI:FRAME. > > You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > (no restarts: If you didn't do this on purpose, please report it as a bug.) > > debugger invoked on a TYPE-ERROR in thread 2175: > The value NIL is not of type SB-DI:FRAME. > > You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. > > (no restarts: If you didn't do this on purpose, please report it as a bug.) > Help! 11 nested errors. SB-KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded. > > ... and SBCL busy-loops eating CPU time, and doesn't react on Ctrl-C, > Ctrl-Z and Ctrl-\. I can only kill it. > > Similarly if I type Ctrl-D instead of (quit), of if I do (quit) immediately > from within the debugger. > > [Taken from clisp's clos.tst] Er, yeah. :-/ > ============================================================================= > Subject: backquote - comma inside array > > * (READ-FROM-STRING "`#1A(1 2 ,(+ 2 2) 4)") > > #(1 2 ((SB-IMPL::|,|) + 2 2) 4) > 20 > > One would expect either an error, or (as an extension of ANSI CL) > #(1 2 4 4) > > [Taken from clisp's backquot.tst] [Bug also present in CMUCL 18e] Looks like a bug. > ============================================================================= > Subject: handling of shared -> local slot conversion in subclass of redefined class > > ;; Shared slot becomes local. > ;; 4.3.6.1.: "The value of a slot that is specified as shared in the old class > ;; and as local in the new class is retained." > (multiple-value-bind (value condition) > (ignore-errors > (defclass foo85a () ((size :initarg :size :initform 1 :allocation :class))) > (defclass foo85b (foo85a) ()) > (setq i (make-instance 'foo85b)) > (defclass foo85a () ((size :initarg :size :initform 2) (other))) > (slot-value i 'size)) > (list value (type-of condition))) > Expected: (1 NULL) > Got: (2 NULL) > > [Taken from clisp's clos.tst] [Bug also present in CMUCL 18e] A bug. What's happening here is that the class slot is vanishing in shared-initialize standard-class, while the machinery for copying over slot values runs later. Probably we need to keep the old class slot values around for a while. > ============================================================================= > Subject: handling of method qualifiers with user-defined method-combination > > (progn > (defun positive-integer-qualifier-p (method-qualifiers) > (and (= (length method-qualifiers) 1) > (typep (first method-qualifiers) '(integer 0 *)))) > (define-method-combination example-method-combination () > ((method-list positive-integer-qualifier-p)) > `(progn ,@(mapcar #'(lambda (method) `(call-method ,method)) > (stable-sort method-list #'< > :key #'(lambda (method) > (first (method-qualifiers > method))))))) > (defgeneric mc-test-piq (p1 p2 s) > (:method-combination example-method-combination) > (:method 1 ((p1 t) (p2 t) s) (vector-push-extend (list 1 p1 p2) s)) > (:method 2 ((p1 t) (p2 t) s) (vector-push-extend (list 2 p1 p2) s)) > (:method 3 ((p1 t) (p2 t) s) (vector-push-extend (list 3 p1 p2) s))) > (let ((s (make-array 10 :adjustable t :fill-pointer 0))) > (mc-test-piq 1 2 s) > s)) > Expected: #((1 1 2) (2 1 2) (3 1 2)) > Got: ERROR: More than one method of type METHOD-LIST with the same specializers. > > [Taken from clisp's clos.tst] [Bug also present in CMUCL 18e] This was in fact a bug in clisp; the DEFINE-METHOD-COMBINATION page prohibits methods with the same specializers in the same method group, even if they have different qualifiers. > ============================================================================= > Subject: define-method-combination arguments lambda lists parsing > > ;; 3.4.10 Define-method-combination Arguments Lambda Lists > (progn > (define-method-combination w-args () > ((method-list *)) > (:arguments arg1 arg2 &aux (extra :extra)) > `(progn ,@(mapcar #'(lambda (method) `(call-method ,method)) method-list))) > (defgeneric mc-test-w-args (p1 p2 s) > (:method-combination w-args) > (:method ((p1 number) (p2 t) s) > (vector-push-extend (list 'number p1 p2) s)) > (:method ((p1 string) (p2 t) s) > (vector-push-extend (list 'string p1 p2) s)) > (:method ((p1 t) (p2 t) s) (vector-push-extend (list t p1 p2) s))) > (let ((s (make-array 10 :adjustable t :fill-pointer 0))) > (mc-test-w-args 1 2 s) > s)) > Expected: #((NUMBER 1 2) (T 1 2)) > Got: ERROR: The lambda variable (EXTRA :EXTRA) is not a symbol. > > [Taken from clisp's clos.tst] [Bug also present in CMUCL 18e] Yep, this looks like a bug in sbcl. > ============================================================================= > Subject: binary I/O with element type (SIGNED-BYTE 33) > > I/O with element type (SIGNED-BYTE n) where n > 32 doesn't work. > > (defun bin-stream-test (&key (size (integer-length most-positive-fixnum)) > (type 'unsigned-byte) (file-name "./foocl") > (num-bytes 10) > (bytes (if (eq type 'signed-byte) > (loop :repeat num-bytes :collect > (- (random (ash 1 size)) > (ash 1 (1- size)))) > (loop :repeat num-bytes :collect > (random (ash 1 size)))))) > (with-open-file (foo file-name :direction :output #+SBCL :if-exists #+SBCL :supersede > :element-type (list type size)) > (dolist (byte bytes) > (write-byte byte foo))) > (unwind-protect > (with-open-file (foo file-name :direction :input > :element-type (list type size)) > (list (stream-element-type foo) (file-length foo) bytes > (loop :for byte :in bytes :for nb = (read-byte foo) :collect nb > :unless (= nb byte) :do > (flet ((by-out (sz by) > (format nil "~v,'0,' ,4:b" > (+ sz (floor sz 4)) by))) > (error "~& * [(~s ~s)] ~a != ~a~%" type size > (by-out size byte) (by-out size nb)))))) > (delete-file file-name))) > (loop for size from 2 to 40 do (bin-stream-test :size size :type 'signed-byte)) > Expected: NIL > Got: ERROR > > [Taken from clisp's streamslong.tst] Fixed in sbcl-0.8.9.36, I believe. > ============================================================================= > Subject: the COMPLEX type > > * (subtypep 'complex '(complex real)) > > NIL > T > > So there can be instances of COMPLEX whose real and imaginary part are not > REAL? Strange... > > [Taken from clisp's type.tst] [Bug also present in CMUCL 18e] > ============================================================================= > Subject: the empty COMPLEX type > > * (subtypep '(complex nil) 'nil) > > Expected: T T > Got: ERROR: (known bug #145): The type NIL is too hairy to be > used for a COMPLEX component. > > What's too hairy about it? (COMPLEX NIL) is the empty type. > > [Taken from clisp's type.tst] These two were fixed in sbcl-0.8.10.9 > ============================================================================= > Subject: DEFSTRUCT type test predicate > > (defstruct (foo73 (:type list) (:initial-offset 5) :named)) > (defstruct (foo74 (:type list) (:initial-offset 2) :named (:include foo73))) > (foo74-p (list* nil nil nil nil nil 'foo73 nil 'tail)) > Expected: NIL > Got: ERROR: The value TAIL is not of type LIST. > > [Taken from clisp's type.tst] [Bug also present in CMUCL 18e] Strange... I thought we had fixed that ages ago. Oh well. > ============================================================================= > Subject: HANDLER-BIND without effect > > HANDLER-BIND appears to have no effect here: > > * (handler-bind ((type-error (lambda (c) (princ c) (terpri) (use-value '#\1)))) > (eql (char-code #\1) (char-code 12))) > ... > The value 12 is not of type BASE-CHAR. > > debugger invoked on a TYPE-ERROR in thread 2986: > The value 12 is not of type BASE-CHAR. > > [Taken from clisp's conditions.tst] [Bug also present in CMUCL 18e] Not a bug. > ============================================================================= > Subject: attributes of a BROADCAST-STREAM > > http://www.lisp.org/HyperSpec/Body/syscla_broadcast-stream.html > > (stream-external-format (make-broadcast-stream)) > Expected: :DEFAULT > Got: ERROR > > (file-length (make-broadcast-stream)) > Expected: 0 > Got: ERROR > > (file-position (make-broadcast-stream)) > Expected: 0 > Got: NIL > > (file-string-length (make-broadcast-stream) "foo") > Expected: 1 > Got: ERROR > > [Taken from clisp's streams.tst] Disputed: STREAM-EXTERNAL-FORMAT, FILE-LENGTH and FILE-STRING-LENGTH are specified to accept FILE-STREAMs, while MAKE-BROADCAST-STREAM gives results on broadcast streams. Should probably be logged as a bug either way, but fixing it is low priority until we understand why the apparent contradiction. > ============================================================================= > Subject: error when redefining a class with new superclass > > * (defclass foo95b () ((s :initarg :s :accessor foo95b-s))) > > #<STANDARD-CLASS FOO95B> > * (defclass foo95b (foo95a) ((s :accessor foo95b-s))) > > debugger invoked on a SIMPLE-ERROR in thread 2902: > While computing the class precedence list of the class named FOO95B. > The class named FOO95A is a forward referenced class. > The class named FOO95A is a direct superclass of the class named FOO95B. > > Why this error? http://www.lisp.org/HyperSpec/Body/mac_defclass.html says > "It is not required that the superclasses of a class be defined before > the defclass form for that class is evaluated." > And the explanations in CLHS section 4.3.6. which talk about instances > don't apply since there are no instances of the class FOO95B. > > [Taken from clisp's clos.tst] I claim this is not a bug, because the implementation creates an instance when the class is finalized, and therefore the redefinition to an incomplete class is illegal. Bruno I think disagrees, but I think his argument is from programmer convenience rather than specificational authority. -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Bruno H. <br...@cl...> - 2004-05-05 11:01:07
|
> > * (write-to-string '``,,`,3) > > > > Expected: "``,,`,3" > > Got: "3" > > > > [Taken from clisp's backquot.tst] [Bug also present in CMUCL 18e] > > I claim this is not a bug: implementations are allowed to optimize > backquoted expressions at read-time. I haven't heard to the contrary > from Bruno on this one, so I assume he agrees. I agree it's not a bug relative to the spec, only a feature wish of mine. Bruno |
From: Bruno H. <br...@cl...> - 2004-05-05 11:04:18
|
> > ;; Shared slot becomes local. > > ;; 4.3.6.1.: "The value of a slot that is specified as shared in the old class > > ;; and as local in the new class is retained." > > A bug. What's happening here is that the class slot is vanishing in > shared-initialize standard-class, while the machinery for copying over > slot values runs later. Probably we need to keep the old class slot > values around for a while. Yes, I think you need it as long as the old class wrapper is around. A way to achieve this is to store the shared slot values in the class wrapper, not in the class. (I don't know if SBCL already does this.) Bruno |
From: Bruno H. <br...@cl...> - 2004-05-05 11:14:05
|
> > * (defclass foo95b () ((s :initarg :s :accessor foo95b-s))) > > > > #<STANDARD-CLASS FOO95B> > > * (defclass foo95b (foo95a) ((s :accessor foo95b-s))) > > > > debugger invoked on a SIMPLE-ERROR in thread 2902: > > While computing the class precedence list of the class named FOO95B. > > The class named FOO95A is a forward referenced class. > > The class named FOO95A is a direct superclass of the class named FOO95B. > > I claim this is not a bug, because the implementation creates an > instance when the class is finalized, and therefore the redefinition > to an incomplete class is illegal. Bruno I think disagrees, but I > think his argument is from programmer convenience rather than > specificational authority. I don't disagree on an ANSI CL lawyer point of view: with the class prototype that is created behind the programmer's back you've found a trick to work around the CLHS sentence "It is not required that the superclasses of a class be defined before the defclass form for that class is evaluated." However, this provision is meant as a programmer convenience. There is also the problem what to do when there are instances around. What I might do in clisp, is 1. to see if the class has been instantiated (other than for the class-prototype, which is thrown away anyway upon class redefinition), 2. if so, run a GC to clean up unused instances, 3. run a heap scan to count the remaining instances, similar to (room t), 4. if some instances actually remain, give a continuable error with two restarts: a. invalidate all existing instances, b. abort and return to the old class definition. Bruno |
From: Nikodemus S. <tsi...@cc...> - 2004-05-10 23:43:52
Attachments:
shiftf.patch
|
> > SHIFTF does not support forms that produce multiple values. But parts of the > > explanation of SHIFTF in ANSI CL talk about multiple store variables, and > > the X3J13 vote SETF-MULTIPLE-STORE-VARIABLES:ALLOW also says that SHIFTF > > should support multiple value places. > > > > * (shiftf (values x y) (values y x)) > > > > debugger invoked on a SIMPLE-ERROR in thread 2522: > > GET-SETF-METHOD used for a form with multiple store variables: > > (VALUES X Y) > > > > [Taken from clisp's setf.tst] > > Dunno. Probably an arguable bug. The attached patch stol^W borr^W adapted from the CMUCL fixes this, and adds a regression test. Cheers, -- Nikodemus |
From: Christophe R. <cs...@ca...> - 2004-05-24 14:36:40
|
Christophe Rhodes <cs...@ca...> writes: >> ============================================================================= >> Subject: define-method-combination arguments lambda lists parsing >> >> ;; 3.4.10 Define-method-combination Arguments Lambda Lists >> (progn >> (define-method-combination w-args () >> ((method-list *)) >> (:arguments arg1 arg2 &aux (extra :extra)) >> `(progn ,@(mapcar #'(lambda (method) `(call-method ,method)) method-list))) >> (defgeneric mc-test-w-args (p1 p2 s) >> (:method-combination w-args) >> (:method ((p1 number) (p2 t) s) >> (vector-push-extend (list 'number p1 p2) s)) >> (:method ((p1 string) (p2 t) s) >> (vector-push-extend (list 'string p1 p2) s)) >> (:method ((p1 t) (p2 t) s) (vector-push-extend (list t p1 p2) s))) >> (let ((s (make-array 10 :adjustable t :fill-pointer 0))) >> (mc-test-w-args 1 2 s) >> s)) >> Expected: #((NUMBER 1 2) (T 1 2)) >> Got: ERROR: The lambda variable (EXTRA :EXTRA) is not a symbol. >> >> [Taken from clisp's clos.tst] [Bug also present in CMUCL 18e] > > Yep, this looks like a bug in sbcl. This has, I believe, been fixed in sbcl-0.8.10.52. Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge) |
From: Christophe R. <cs...@ca...> - 2005-01-28 16:54:09
|
Christophe Rhodes <cs...@ca...> writes: > [ Bruno Haible "various SBCL bugs" ] > >> Subject: FORMAT of floating-point numbers >> >> * (FORMAT NIL "~1f" 10) >> >> "0." >> * (FORMAT NIL "~0f" 10) >> >> "0." >> >> Expected "10." for both, according to ANSI CL 22.3.3.1. >> >> Similarly >> * (FORMAT NIL "~2f" 1234567.1) >> >> "1000000." >> >> Expected "1234567." here. >> >> [Taken from clisp's format.tst] [Bug also present in CMUCL 18e] > > Well, sbcl's results here certainly need some explaining. Presumably > a bug. [ ... time passes ... ] I've committed fixes for these to sbcl-0.8.19.3. In the process, I think I found that a clisp which announces itself as GNU CLISP 2.33.2 (2004-06-02) (built 3304881526) (memory 3307692381) gets (format nil "~G" 1d23) wrong -- it gives me a string beginning "09". I don't know if this has been fixed in any later version. Cheers, Christophe |
From: Bruno H. <br...@cl...> - 2005-01-28 22:27:50
|
Christophe Rhodes wrote: > >> * (FORMAT NIL "~1f" 10) > >> * (FORMAT NIL "~2f" 1234567.1) > > I've committed fixes for these to sbcl-0.8.19.3. Thanks. > (format nil "~G" 1d23) > gives me a string beginning "09". I don't know if this > has been fixed in any later version. Ouch. It is not fixed yet. Thanks for the report, Christophe. Bruno |
From: Bruno H. <br...@cl...> - 2004-05-11 12:12:52
|
> The attached patch stol^W borr^W adapted from the CMUCL fixes this, > and adds a regression test. Thanks. It also gets rid of a similarity with clisp code that makes me think that the previous code was stolen from clisp. (For sure I can't really tell, because maybe Sam gave you the permission to use the SHIFTF code that I wrote in 1993. But there's no comment saying "taken from clisp with permission".) Stealing from a GPL'ed project to a BSD-licensed project is not OK. I'm sure it's me who wrote that code because there can be no other idiot on earth who uses variable names 'sm1', 'sm2', 'sm3', 'sm4', sm5' :-) Bruno =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D SBCL'= s early-setf.lisp rev 1.1 (2000) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D http://cvs.sourceforge.net/viewcvs.py/*checkout*/sbcl/sbcl/src/code/early-s= etf.lisp?rev=3D1.1 (defmacro-mundanely shiftf (&whole form &rest args &environment env) #!+sb-doc "One or more SETF-style place expressions, followed by a single value expression. Evaluates all of the expressions in turn, then assigns the value of each expression to the place on its left, returning the value of the leftmost." (when (< (length args) 2) (error "~S called with too few arguments: ~S" 'shiftf form)) (let ((resultvar (gensym))) (do ((arglist args (cdr arglist)) (bindlist nil) (storelist nil) (lastvar resultvar)) ((atom (cdr arglist)) (push `(,lastvar ,(first arglist)) bindlist) `(let* ,(nreverse bindlist) ,@(nreverse storelist) ,resultvar)) (multiple-value-bind (sm1 sm2 sm3 sm4 sm5) (get-setf-method (first arglist) env) (mapc #'(lambda (var val) (push `(,var ,val) bindlist)) sm1 sm2) (push `(,lastvar ,sm5) bindlist) (push sm4 storelist) (setq lastvar (first sm3)))))) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CLISP= 's places.lsp rev. 1.1 (1998) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D (defmacro shiftf (&whole form &rest args &environment env) (when (< (length args) 2) (error-of-type 'source-program-error (DEUTSCH "SHIFTF mit zu wenig Argumenten aufgerufen: ~S" ENGLISH "SHIFTF called with too few arguments: ~S" FRANCAIS "SHIFTF fut appel=E9 avec trop peu d'arguments : ~S") form ) ) (do* ((resultvar (gensym)) (arglist args (cdr arglist)) (bindlist nil) (storelist nil) (lastvar resultvar)) ((atom (cdr arglist)) (push `(,lastvar ,(first arglist)) bindlist) `(LET* ,(nreverse bindlist) ,@(nreverse storelist) ,resultvar) ) (multiple-value-bind (SM1 SM2 SM3 SM4 SM5) (get-setf-method (first argl= ist) env) (do* ((SM1r SM1 (cdr SM1r)) (SM2r SM2 (cdr SM2r))) ((null Sm1r)) (push `(,(first SM1r) ,(first SM2r)) bindlist) ) (push `(,lastvar ,SM5) bindlist) (push SM4 storelist) (setq lastvar (first SM3)) ) ) ) |
From: William H. N. <wil...@ai...> - 2004-05-11 14:22:15
|
On Tue, May 11, 2004 at 02:04:46PM +0200, Bruno Haible wrote: > > The attached patch stol^W borr^W adapted from the CMUCL fixes this, > > and adds a regression test. > > Thanks. It also gets rid of a similarity with clisp code that makes me > think that the previous code was stolen from clisp. (For sure I can't really > tell, because maybe Sam gave you the permission to use the SHIFTF code that > I wrote in 1993. But there's no comment saying "taken from clisp with > permission".) Stealing from a GPL'ed project to a BSD-licensed project > is not OK. > > I'm sure it's me who wrote that code because there can be no other idiot > on earth who uses variable names 'sm1', 'sm2', 'sm3', 'sm4', sm5' :-) Ouch. It should be straightforward to unscrew this from a technical point of view. From a social point of view, I'm not sure what to do. Would you like an apology in the next release? some other sort of action on our part? Energetic and not-so-energetic s/w students have, indirectly through their efforts and lack thereof, driven antiplagiarism s/w to a disturbingly developed state; maybe we should run some as part of our test suite.:-( -- William Harold Newman <wil...@ai...> "It takes two to lie, Marge -- one to lie and one to listen." -- Homer Simpson PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Bruno H. <br...@cl...> - 2004-05-11 15:04:12
|
William Harold Newman wrote: > It should be straightforward to unscrew this from a technical point of > view. Yes, just apply Nikodemus' patch. > From a social point of view, I'm not sure what to do. For this one, it's ok. No problems because of 10 lines of code. But there's also the license point of view: You need to be careful when taking code from a GPL'ed project, so that it doesn't affect the BSD license of SBCL. It's worth asking the authors: sometimes I do give GPLed or LGPLed code of mine away under BSD licenses; it depends on the circumstances. > Energetic and not-so-energetic s/w students have, indirectly through > their efforts and lack thereof, driven antiplagiarism s/w to a > disturbingly developed state; maybe we should run some as part of our > test suite.:-( It would be more interesting to run such antiplagiarism tests on some closed-source CL implementations :-) But I assume these tests need the source code, not just the binaries? Bruno |
From: Raymond T. <to...@rt...> - 2004-05-11 16:24:21
|
>>>>> "Bruno" == Bruno Haible <br...@cl...> writes: >> The attached patch stol^W borr^W adapted from the CMUCL fixes this, >> and adds a regression test. Bruno> Thanks. It also gets rid of a similarity with clisp code that makes me Bruno> think that the previous code was stolen from clisp. (For sure I can't really Bruno> tell, because maybe Sam gave you the permission to use the SHIFTF code that Bruno> I wrote in 1993. But there's no comment saying "taken from clisp with Bruno> permission".) Stealing from a GPL'ed project to a BSD-licensed project Bruno> is not OK. Bruno> I'm sure it's me who wrote that code because there can be no other idiot Bruno> on earth who uses variable names 'sm1', 'sm2', 'sm3', 'sm4', sm5' :-) FWIW, the CMUCL contained this code. There is also a log message saying "New shiftf from Bruno Haible...", but I don't know if permission was obtained or not. CMUCL no longer has this version; it was replaced in mid-2002. Ray |
From: Bruno H. <br...@cl...> - 2004-05-11 16:54:34
|
> FWIW, the CMUCL contained this code. There is also a log message > saying "New shiftf from Bruno Haible...", but I don't know if > permission was obtained or not. In this case, all my apologies. I don't remember this donation: brain failure :-( Apologies. Bruno |