X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=a2c61e520f7575b0e59d74bbdf9bd69be6f706a1;hb=334af30b26555f0bf706f7157b399bdbd4fad548;hp=8a88aebe895477ab4d3761972c02a390a7759e5c;hpb=475c832b081651e66ad9446d4852c62086f5e740;p=sbcl.git diff --git a/BUGS b/BUGS index 8a88aeb..a2c61e5 100644 --- a/BUGS +++ b/BUGS @@ -104,7 +104,10 @@ WORKAROUND: The situation is complicated by the presence of Common Lisp types like UNSIGNED-BYTE (which can either be used in list form or alone) so I'm not 100% sure that the behavior above is actually illegal. - But I'm 90+% sure, and someday perhaps I'll be motivated to look it up.. + But I'm 90+% sure, and the following related behavior, + (TYPEP 11 'AND) => T + treating the bare symbol AND as equivalent to '(AND), is specifically + forbidden (by the ANSI specification of the AND type). 11: It would be nice if the @@ -115,25 +118,6 @@ WORKAROUND: (during macroexpansion of IN-PACKAGE, during macroexpansion of DEFFOO) -12: - The type system doesn't understand the KEYWORD type very well: - (SUBTYPEP 'KEYWORD 'SYMBOL) => NIL, NIL - It might be possible to fix this by changing the definition of - KEYWORD to (AND SYMBOL (SATISFIES KEYWORDP)), but the type system - would need to be a bit smarter about AND types, too: - (SUBTYPEP '(AND SYMBOL KEYWORD) 'SYMBOL) => NIL, NIL - (The type system does know something about AND types already, - (SUBTYPEP '(AND INTEGER FLOAT) 'NUMBER) => T, T - (SUBTYPEP '(AND INTEGER FIXNUM) 'NUMBER) =>T, T - so likely this is a small patch.) - -13: - Floating point infinities are screwed up. [When I was converting CMU CL - to SBCL, I was looking for complexity to delete, and I thought it was safe - to just delete support for floating point infinities. It wasn't: they're - generated by the floating point hardware even when we remove support - for them in software. -- WHN] Support for them should be restored. - 14: The ANSI syntax for non-STANDARD method combination types in CLOS is (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN)) @@ -372,9 +356,7 @@ returning an array as first value always. 45: a slew of floating-point-related errors reported by Peter Van Eynde on July 25, 2000: - a: (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined. - Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others - aren't found. + a: (fixed in sbcl-0.6.11.25) b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and should probably be 1.4012985e-45. In SBCL, (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller @@ -388,10 +370,7 @@ returning an array as first value always. (EXPT 10.0d0 1000) PVE's regression tests want them to raise errors. SBCL generates the infinities instead, which may or may not be - conforming behavior, but then blow it by being unable to - output the infinities, since support for infinities is generally - broken, and in particular SB-IMPL::OUTPUT-FLOAT-INFINITY is - undefined. + conforming behavior. d: (in section12.erg) various forms a la (FLOAT 1 DOUBLE-FLOAT-EPSILON) don't give the right behavior. @@ -532,8 +511,18 @@ Error in function C::GET-LAMBDA-TO-COMPILE: # was defined in a non-null environment. 58: - (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) - => NIL, NIL + (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL + Note: I looked into fixing this in 0.6.11.15, but gave up. The + problem seems to be that there are two relevant type methods for + the subtypep operation, HAIRY :COMPLEX-SUBTYPEP-ARG2 and + INTERSECTION :COMPLEX-SUBTYPEP-ARG1, and only the first is + called. This could be fixed, but type dispatch is messy and + confusing enough already, I don't want to complicate it further. + Perhaps someday we can make CLOS cross-compiled (instead of compiled + after bootstrapping) so that we don't need to have the type system + available before CLOS, and then we can rewrite the type methods to + CLOS methods, and then expressing the solutions to stuff like this + should become much more straightforward. -- WHN 2001-03-14 59: CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting @@ -787,6 +776,93 @@ Error in function C::GET-LAMBDA-TO-COMPILE: invokes the debugger: "B is not of type list". SBCL does the same thing. +82: + Functions are assigned names based on the context in which they're + defined. This is less than ideal for the functions which are + used to implement CLOS methods. E.g. the output of + (DESCRIBE 'PRINT-OBJECT) lists functions like + # + and + # + It would be better if these functions' names always identified + them as methods, and identified their generic functions and + specializers. + +83: + RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM + RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though + the mean of the distribution can be systematically O(0.1%) wrong. + Just increasing R-I-E-B is probably not a good solution, since + it would decrease efficiency more than is probably necessary. Perhaps + using some sort of accept/reject method would be better. + +84: + (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL) + +85: + Internally the compiler sometimes evaluates + (sb-kernel:type/= (specifier-type '*) (specifier-type t)) + (I stumbled across this when I added an + (assert (not (eq type1 *wild-type*))) + in the NAMED :SIMPLE-= type method.) '* isn't really a type, and + in a type context should probably be translated to T, and so it's + probably to ask whether it's equal to the T type and then (using the + EQ type comparison in the NAMED :SIMPLE-= type method) return NIL. + (I haven't tried to investigate this bug enough to guess whether + there might be any user-level symptoms.) + +87: + Despite what the manual says, (DECLAIM (SPEED 0)) doesn't cause + things to be byte compiled. This seems to be true in cmucl-2.4.19, + too: (COMPILE-FILE .. :BYTE-COMPILE T) causes byte-compilation, + but ordinary COMPILE-FILE of a file containing (DECLAIM (SPEED 0)) + does not. + +90: + a latent cross-compilation/bootstrapping bug: The cross-compilation + host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp + and possibly elsewhere. Instead, we should use the target system's + CHAR-CODE-LIMIT. This will probably cause problems if we try to + bootstrap on a system which uses a different value of CHAR-CODE-LIMIT + than SBCL does. + +91: + (subtypep '(or (integer -1 1) + unsigned-byte) + '(or (rational -1 7) + unsigned-byte + (integer -1 1))) => NIL,T + An analogous problem with SINGLE-FLOAT and REAL types was fixed in + sbcl-0.6.11.22, but some peculiarites of the RATIO type make it + awkward to generalize the fix to INTEGER and RATIONAL. It's not + clear what's the best fix. (See the "bug in type handling" discussion + on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.) + +92: + (< SB-EXT:SINGLE-FLOAT-POSITIVE-INFINITY 100) signals an error: + error in function SB-KERNEL:INTEGER-DECODE-SINGLE-FLOAT: + can't decode NaN or infinity: #.EXT:SINGLE-FLOAT-POSITIVE-INFINITY + This is a bug in the original CMU CL code. I reported it to cmucl-imp + 2001-03-22 in hopes that they'll fix it for us. + +93: + In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in + src/cold/shared.lisp doesn't correctly translate the + interpreted function + (defun in-host-compilation-mode (fn) + (let ((*features* (cons :sb-xc-host *features*)) + ;; the CROSS-FLOAT-INFINITY-KLUDGE, as documented in + ;; base-target-features.lisp-expr: + (*shebang-features* (set-difference *shebang-features* + '(:sb-propagate-float-type + :sb-propagate-fun-type)))) + (with-additional-nickname ("SB-XC" "SB!XC") + (funcall fn)))) + No error is reported by the compiler, but when the function is executed, + it causes an error + TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: + (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST + :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL. KNOWN BUGS RELATED TO THE IR1 INTERPRETER