From: Nathan F. <fr...@ro...> - 2001-10-13 04:23:24
|
[this is 0.pre7.60; I'm sure it's already been seen and so forth, but if it hasn't, it's good to get it on the radar] Transcript of a recent SBCL session: * (quit) ; in: LAMBDA NIL ; (QUIT) ; ; caught STYLE-WARNING: ; undefined function: QUIT ; ; caught STYLE-WARNING: ; This function is undefined: QUIT ; ; compilation unit finished ; caught 2 STYLE-WARNING conditions debugger invoked on condition of type UNDEFINED-FUNCTION: The function QUIT is undefined. [debugger help] debugger invoked on conditinon of type TYPE-ERROR: The value #S(SB-C::COMPILED-DEBUG-FUN :NAME SB-KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLDER [blah blah] ...) is not of type SB-DI:DEBUG-FUN. And we repeat this, with except we're in an infinite loop of SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER. Does this also stem from the recent IR1/EVAL-WHEN changes? Would somebody mind explaining the deep, underlying reason for this? :) -Nathan |
From: Alexey D. <ade...@co...> - 2001-10-13 10:45:46
|
Hello, > debugger invoked on conditinon of type TYPE-ERROR: > The value > #S(SB-C::COMPILED-DEBUG-FUN > :NAME SB-KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLDER > [blah blah] > ...) > is not of type > SB-DI:DEBUG-FUN. The attached patch fixes this bug. > Does this also stem from the recent IR1/EVAL-WHEN changes? Would > somebody mind explaining the deep, underlying reason for this? :) I have not found the origin. This code existed before autumn rewritings. Regards, Alexey Dejneka |
From: Alexey D. <ade...@co...> - 2001-10-13 10:51:46
Attachments:
debug-int.lisp.patch
|
Sorry, I forget to attach the patch. |
From: William H. N. <wil...@ai...> - 2001-10-14 00:40:55
|
On Sat, Oct 13, 2001 at 02:46:26PM +0400, Alexey Dejneka wrote: > > debugger invoked on conditinon of type TYPE-ERROR: > > The value > > #S(SB-C::COMPILED-DEBUG-FUN > > :NAME SB-KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLDER > > [blah blah] > > ...) > > is not of type > > SB-DI:DEBUG-FUN. > > The attached patch fixes this bug. Thank you. I've rewritten the code along the lines of your patch in sbcl-0.pre7.62, just checked in. Hopefully I didn't introduce any more problems.. > > Does this also stem from the recent IR1/EVAL-WHEN changes? Would > > somebody mind explaining the deep, underlying reason for this? :) > > I have not found the origin. This code existed before autumn rewritings. The origin seems to be that I renamed everything s/debug-function/debug-fun/, and although I glanced at each line to see whether it looked logical, I didn't check carefully enough to notice that in PARSE-COMPILED-DEBUG-BLOCKS, the names DEBUG-FUNCTION and DEBUG-FUN were used to refer to distinct things. My substitution turned them into the same name, so the distinction got lost and things fell apart. It's renaming that got me into this trouble, but this kind of thing is part of the reason that I've been doing so much renaming. It's quite difficult for me to work with code where such similar names are used for distinct things, and the difference between the names gives no hint as to the nature of the distinctions between the named things. 0.6.13 0.pre7.62 ------ --------- SB-BIGNUM:BIGNUM-TYPE SB-BIGNUM:BIGNUM-TYPE SB-VM:BIGNUM-TYPE SB-VM:BIGNUM-WIDETAG (DEFINE-PRIMITIVE-OBJECT (DEFINE-PRIMITIVE-OBJECT (BIGNUM (BIGNUM :LOWTAG OTHER-POINTER-TYPE :LOWTAG OTHER-POINTER-LOWTAG :HEADER BIGNUM-TYPE :WIDETAG BIGNUM-WIDETAG ..) ..) ..) ..) SB-KERNEL:FUNCTION-TYPE SB-KERNEL:FUN-TYPE (DEFPARAMETER (DEFPARAMETER FUNCTION-HEADER-TYPES *FUN-HEADER-WIDETAGS* (LIST (LIST FUNCALLABLE-INSTANCE-HEADER-TYPE FUNCALLABLE-INSTANCE-WIDETAG FUNCTION-HEADER-TYPE SIMPLE-FUN-HEADER-WIDETAG CLOSURE-FUNCTION-HEADER-TYPE CLOSURE-FUN-HEADER-WIDETAG CLOSURE-HEADER-TYPE)) CLOSURE-HEADER-WIDETAG)) (ad nauseam) But it's probably time to stop renaming so many things and start concentrating on fixing the damage instead.:-| -- William Harold Newman <wil...@ai...> "Those who study history are doomed to watch others repeat it." - Susan E. Cohen PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |