#(1 2 ((SB-IMPL::|,|) + 2 2) 4)
which probably isn't intentional.
-321: "DEFINE-METHOD-COMBINATION lambda list parsing"
- reported by Bruno Haible sbcl-devel "various SBCL bugs" from CLISP
- test suite.
- (define-method-combination w-args ()
- ((method-list *))
- (:arguments arg1 arg2 &aux (extra :extra))
- `(progn ,@(mapcar (lambda (method) `(call-method ,method)) method-list)))
- gives a (caught) compile-time error, which can be exposed by
- (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)))
-
323: "REPLACE, BIT-BASH and large strings"
The transform for REPLACE on simple-base-strings uses BIT-BASH, which
at present has an upper limit in size. Consequently, in sbcl-0.8.10
is closed." -- implying that even though undesirable, early deletion
is legal. Restoring the original would none the less be the polite
thing to do.
+
+326: "*PRINT-CIRCLE* crosstalk between streams"
+ In sbcl-0.8.10.48 it's possible for *PRINT-CIRCLE* references to be
+ mixed between streams when output operations are intermingled closely
+ enough (as by doing output on S2 from within (PRINT-OBJECT X S1) in the
+ test case below), so that e.g. the references #2# appears on a stream
+ with no preceding #2= on that stream to define it (because the #2= was
+ sent to another stream).
+ (cl:in-package :cl-user)
+ (defstruct foo index)
+ (defparameter *foo* (make-foo :index 4))
+ (defstruct bar)
+ (defparameter *bar* (make-bar))
+ (defparameter *tangle* (list *foo* *bar* *foo*))
+ (defmethod print-object ((foo foo) stream)
+ (let ((index (foo-index foo)))
+ (format *trace-output*
+ "~&-$- emitting FOO ~D, ambient *BAR*=~S~%"
+ index *bar*)
+ (format stream "[FOO ~D]" index))
+ foo)
+ (let ((tsos (make-string-output-stream))
+ (ssos (make-string-output-stream)))
+ (let ((*print-circle* t)
+ (*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))))
+ 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
+ up the special variable binding semantics using UNWIND-PROTECT and
+ (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?)
projects / sbcl.git / blobdiff