From: Martin A. <ma...@at...> - 2001-03-22 12:53:51
|
Hi, when I compile a file containing the following (using either sbcl-0.6.11 or the newest CVS-snapshot): (in-package :cl-user) #p"" I get: * ;;;Compile pathname-dump-bug.lisp ; compiling file "pathname-dump-bug.lisp" (written 22 MAR 2001 11:03:49 AM): ; byte compiling top-level form: ; compilation unit aborted ; caught 1 fatal ERROR condition ; compilation aborted after 0:00:00 "ILISP: error in function SB-C::COMPILER-ERROR: (while making load form for #<SB-IMPL::UNIX-HOST {501A1C5}>) error in function \"DEFMETHOD NO-APPLICABLE-METHOD (T)\": There is no matching method for the generic function #<STANDARD-GENERIC-FUNCTION MAKE-LOAD-FORM (6)> when called with arguments (#<SB-IMPL::UNIX-HOST {501A1C5}> #S(SB-KERNEL:LEXENV [ - snip - ] ) * As far as I was able to track it down, this happens, because make-load-form is not specialized on COMMON-LISP:STRUCTURE-OBJECT, but on SB-SYS:STRUCTURE!OBJECT. And SB-IMPL::UNIX-HOST is a subtype of COMMON-LISP:STRUCTURE-OBJECT, but not of SB-SYS:STRUCTURE!OBJECT. Comments? Cheers, Martin -- Martin Atzmueller <ma...@at...> |
From: Martin A. <ma...@at...> - 2001-03-23 14:07:59
|
Martin Atzmueller wrote: > > Hi, > > when I compile a file containing the following > (using either sbcl-0.6.11 or the newest CVS-snapshot): > > (in-package :cl-user) > #p"" > > I get: > > * ;;;Compile pathname-dump-bug.lisp > ; compiling file "pathname-dump-bug.lisp" (written 22 MAR 2001 11:03:49 > AM): > ; byte compiling top-level form: > ; compilation unit aborted > ; caught 1 fatal ERROR condition > ; compilation aborted after 0:00:00 > "ILISP: > error in function SB-C::COMPILER-ERROR: > (while making load form for #<SB-IMPL::UNIX-HOST {501A1C5}>) > > error in function \"DEFMETHOD NO-APPLICABLE-METHOD (T)\": > There is no matching method for the generic function > #<STANDARD-GENERIC-FUNCTION > MAKE-LOAD-FORM > (6)> > when called with arguments (#<SB-IMPL::UNIX-HOST {501A1C5}> > #S(SB-KERNEL:LEXENV > [ - snip - ] > ) > * > > As far as I was able to track it down, this happens, because > make-load-form is > not specialized on COMMON-LISP:STRUCTURE-OBJECT, but on > SB-SYS:STRUCTURE!OBJECT. > And SB-IMPL::UNIX-HOST is a subtype of COMMON-LISP:STRUCTURE-OBJECT, but > not of > SB-SYS:STRUCTURE!OBJECT. Trying a little further: The comments in the source-code say, STRUCTURE!OBJECT is only used internally, but is otherwise equal to STRUCTURE-OBJECT, but only includes an extra make-load-form-fun slot, that is, what we need. So, UNIX-HOST is made a subtype of HOST, but the type HOST is not defined anywhere, as far as I could find out. All that seems to be a bootstrapping problem, because of make-load-form only working with STRUCTURE!OBJECT but not with STRUCTURE-OBJECT. (SPECIFIER-TYPE 'HOST) returns a STRUCTURE-CLASS, and this one is - as expected - a subclass of STRUCTURE-CLASS. Maybe it would suffice to add a definition for HOST somewhere ...? But how does HOST as a type come into existence, in the first place. Grepping through the sources did not reveal anything, and I stepped down till VALUES-SPECIFIER-TYPE which gives me some instance, that somehow exists ... ( magic ? :) -- Martin Atzmueller <ma...@at...> |
From: William H. N. <wil...@ai...> - 2001-03-24 16:10:51
|
On Fri, Mar 23, 2001 at 03:07:05PM +0100, Martin Atzmueller wrote: > Martin Atzmueller wrote: > > > > Hi, > > > > when I compile a file containing the following > > (using either sbcl-0.6.11 or the newest CVS-snapshot): > > > > (in-package :cl-user) > > #p"" > > > > I get: > > > > * ;;;Compile pathname-dump-bug.lisp > > ; compiling file "pathname-dump-bug.lisp" (written 22 MAR 2001 11:03:49 > > AM): > > ; byte compiling top-level form: > > ; compilation unit aborted > > ; caught 1 fatal ERROR condition > > ; compilation aborted after 0:00:00 > > "ILISP: > > error in function SB-C::COMPILER-ERROR: > > (while making load form for #<SB-IMPL::UNIX-HOST {501A1C5}>) > > > > error in function \"DEFMETHOD NO-APPLICABLE-METHOD (T)\": > > There is no matching method for the generic function > > #<STANDARD-GENERIC-FUNCTION > > MAKE-LOAD-FORM > > (6)> > > when called with arguments (#<SB-IMPL::UNIX-HOST {501A1C5}> > > #S(SB-KERNEL:LEXENV > > [ - snip - ] > > ) > > * I can replicate this problem here, but I haven't looked for a fix yet. Right now, I'm wrapped up in trying to make the PROPAGATE-FLOAT-TYPE and PROPAGATE-FUN-TYPE stuff work, but I should be able to look for a fix for your problem within a few days. > > As far as I was able to track it down, this happens, because > > make-load-form is > > not specialized on COMMON-LISP:STRUCTURE-OBJECT, but on > > SB-SYS:STRUCTURE!OBJECT. > > And SB-IMPL::UNIX-HOST is a subtype of COMMON-LISP:STRUCTURE-OBJECT, but > > not of > > SB-SYS:STRUCTURE!OBJECT. > Trying a little further: > > The comments in the source-code say, STRUCTURE!OBJECT is only used > internally, > but is otherwise equal to STRUCTURE-OBJECT, but only includes an extra > make-load-form-fun slot, that is, what we need. > > So, UNIX-HOST is made a subtype of HOST, but the type HOST is not > defined > anywhere, as far as I could find out. > All that seems to be a bootstrapping problem, because of make-load-form > only > working with STRUCTURE!OBJECT but not with STRUCTURE-OBJECT. > (SPECIFIER-TYPE 'HOST) returns a STRUCTURE-CLASS, and this one is - as > expected - a subclass of STRUCTURE-CLASS. > Maybe it would suffice to add a definition for HOST somewhere ...? > > But how does HOST as a type come into existence, in the first place. > Grepping through the sources did not reveal anything, and I stepped > down till VALUES-SPECIFIER-TYPE which gives me some instance, > that somehow exists ... ( magic ? :) HOST is defined in pathname.lisp. The menagerie of cold-init/bootstrap variants of the DEFFOO forms is admittedly an obstacle to finding things, but it can be found: $ find -name '*.lisp' | xargs egrep -i 'def.*struct.*host' ./src/code/class.lisp:140: ;; KLUDGE: DEF!STRUCT at #+SB-XC-HOST ./src/code/debug-info.lisp:263:(def!struct (debug-source #-sb-xc-host (:pure t)) ./src/code/defbangstruct.lisp:171:;;; a helper function for DEF!STRUCT in the #+SB-XC-HOST case: Return ./src/code/filesys.lisp:472:(def!struct (unix-host ./src/code/late-type.lisp:133:(defstruct (key-info #-sb-xc-host (:pure t) ./src/code/pathname.lisp:19:(sb!xc:defstruct (host (:constructor nil)) ./src/code/pathname.lisp:28:(sb!xc:defstruct (logical-host ./src/compiler/knownfun.lisp:67:(defstruct (function-info #-sb-xc-host (:pure t)) Or with some patience you can pry a hint out of a running SBCL: * (describe 'sb-impl::host-p) SB-IMPL::HOST-P is an internal symbol in #<PACKAGE "SB-IMPL">. Function: #<FUNCTION SB-IMPL::HOST-P> Function arguments: (#:g14) Its defined argument types are: (T) Its result type is: (MEMBER NIL T) It is currently declared inline; expansion is available. On Thu, Mar 22, 2001 05:14:50 PM CST it was compiled from: /usr/stuff/sbcl/src/code/pathname.lisp Created: Tuesday, December 19, 2000 08:13:04 AM CST (I'd like to have DESCRIBE give useful information about types directly, but that's unlikely to happen soon.) -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Martin A. <ma...@at...> - 2001-03-25 23:33:44
Attachments:
pathname-dump-bug.tgz
|
William Harold Newman wrote: > > On Fri, Mar 23, 2001 at 03:07:05PM +0100, Martin Atzmueller wrote: > > Martin Atzmueller wrote: > > > when I compile a file containing the following > > > (using either sbcl-0.6.11 or the newest CVS-snapshot): > > > > > > (in-package :cl-user) > > > #p"" > > > > > > I get: > > > > > > * ;;;Compile pathname-dump-bug.lisp > > > ; compiling file "pathname-dump-bug.lisp" (written 22 MAR 2001 11:03:49 > > > AM): > > > ; byte compiling top-level form: > > > ; compilation unit aborted > > > ; caught 1 fatal ERROR condition > > > ; compilation aborted after 0:00:00 > > > "ILISP: > > > error in function SB-C::COMPILER-ERROR: > > > (while making load form for #<SB-IMPL::UNIX-HOST {501A1C5}>) [ - snip ] > > All that seems to be a bootstrapping problem, because of make-load-form > > only > > working with STRUCTURE!OBJECT but not with STRUCTURE-OBJECT. > > (SPECIFIER-TYPE 'HOST) returns a STRUCTURE-CLASS, and this one is - as > > expected - a subclass of STRUCTURE-CLASS. > > Maybe it would suffice to add a definition for HOST somewhere ...? > HOST is defined in pathname.lisp. The menagerie of cold-init/bootstrap > variants of the DEFFOO forms is admittedly an obstacle to finding > things, but it can be found: Thanks. The attached patch should fix the problem (a simple test case is included, too). (The patch also includes a fix for a trivial FIXME note.) The problem was, that a structure defined by DEF!STRUCT (UNIX-HOST), that includes a structure defined by DEFSTRUCT (SB!XC:DEFSTRUCT), somehow loses its ability to have a "make-load-form-fun", because it has no STRUCTURE!OBJECT superclass, but only a STRUCTURE-OBJECT, and for that the right make-load-form-fun is not found. I have two question: What exactly does the comment in code/defstruct.lisp, line 214 ";; FIXME: MAKE-LOAD-FORM is supposed to be handled here, too.", mean? The separation of DEF!STRUCT and DEFSTRUCT structures seems to be problem sometimes, so, is a structure defined by DEFSTRUCT supposed to have a special make-load-form-fun, or not? -- Martin Atzmueller <ma...@at...> |
From: William H. N. <wil...@ai...> - 2001-03-26 01:45:21
|
On Mon, Mar 26, 2001 at 01:32:45AM +0200, Martin Atzmueller wrote: > The attached patch should fix the problem (a simple test case is > included, too). > (The patch also includes a fix for a trivial FIXME note.) OK, thank you. > The problem was, that a structure defined by DEF!STRUCT (UNIX-HOST), > that includes a structure defined by DEFSTRUCT (SB!XC:DEFSTRUCT), > somehow loses its ability to have a "make-load-form-fun", > because it has no STRUCTURE!OBJECT superclass, but only > a STRUCTURE-OBJECT, and for that the right make-load-form-fun > is not found. > > I have two question: > What exactly does the comment in code/defstruct.lisp, line 214 > ";; FIXME: MAKE-LOAD-FORM is supposed to be handled here, too.", > mean? I think it refers to the discrepancy between the comments at the head of the function, which date back to original CMU CL, and what the current version actually does. Something should change to make the comments consistent with the code, and at the time I wrote the FIXME it wasn't obvious which should change. It still isn't instantly obvious. I'll probably look at it a little more after I get sbcl-0.6.11.26 to a state where I can check it in. > The separation of DEF!STRUCT and DEFSTRUCT structures seems to be > problem sometimes, so, is a structure defined by DEFSTRUCT supposed > to have a special make-load-form-fun, or not? My tentative answer, which might turn out to be at least somewhat wrong, is that SBCL, unlike CMU CL, tries diligently to use CLOS as ANSI specifies for things like PRINT-OBJECT, DESCRIBE-OBJECT, and MAKE-LOAD-FORM. However, some DEFSTRUCTs need to be compiled before CLOS is running, so we need a special hack to deal with MAKE-LOAD-FORM in that case. Those which need that hack, and perhaps some others as well, are built with DEF!STRUCT. By limiting the hack to only some classes internal to the system, rather than user-defined classes, the hack can be fairly crude and still not cause problems. (DEF!STRUCT handles other stuff as well, notably the magic required to dump a cross-compilation host Lisp object as a compiled target Lisp object.) I should probably document the design motivations in the DEF!STRUCT system more properly somewhere. It's part of the weird complicated system intended to make cross-compilation host Lisp objects correspond to target Lisp objects, and even though I wrote it, I was unable to make it simple, so it usually takes me a while to stuff it back into my head when I need to understand it again. Better documentation would both give me something to point to to answer questions like yours, and help me in the stuff-it-into-my-head process.:-| -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2001-03-26 20:49:25
|
On Mon, Mar 26, 2001 at 01:32:45AM +0200, Martin Atzmueller wrote: > The problem was, that a structure defined by DEF!STRUCT (UNIX-HOST), > that includes a structure defined by DEFSTRUCT (SB!XC:DEFSTRUCT), > somehow loses its ability to have a "make-load-form-fun", > because it has no STRUCTURE!OBJECT superclass, but only > a STRUCTURE-OBJECT, and for that the right make-load-form-fun > is not found. > > I have two question: > What exactly does the comment in code/defstruct.lisp, line 214 > ";; FIXME: MAKE-LOAD-FORM is supposed to be handled here, too.", > mean? > The separation of DEF!STRUCT and DEFSTRUCT structures seems to be > problem sometimes, so, is a structure defined by DEFSTRUCT supposed > to have a special make-load-form-fun, or not? OK, now maybe I understand better what you were saying. The requirement that any class :INCLUDEd by a DEF!STRUCT be defined by DEF!STRUCT, not just DEFSTRUCT, can be a problem sometimes, since it's easy to inadvertently get it wrong, and the system doesn't catch the problem at compile or build time, but only when someone tries to dump an instance of the class. I'll try to add such a check to the DEF!STRUCT macro to catch problems like this in the future; I can probably do this while I'm merging your patches, In the longer run, the more I've worked on the type system in 0.6.11.x (especially while adding INTERSECTION-TYPE, redoing the type methods, debugging a NUMERIC-TYPE problem) the more I wished that CLOS was set up in cold init, so that we could define fundamental things like type classes completely in terms of CLOS, without having to use pre-CLOS hacks like doing crude method dispatch without inheritance in !INVOKE-TYPE-METHOD, and faking up inheritance with (CASE (NUMERIC-TYPE-CLASS X) ..). I can't really tell how hard it would be to rearrange the PCL code so that it could be cross-compiled and cold-initialized; it might even be reasonably straightforward. (It might also be impossibly difficult, of course.:-) Maybe I'll give it a try one of these days, and see. If that could be done, then it would become possible to replace other CLOS-isn't-ready-yet hacks (like the DEF!STRUCT-TYPE-MAKE-LOAD-FORM-FUN stuff that's the problem here) with ordinary CLOS definitions, which would be a nice solution to problems like this. (It's a nice dream, anyway..:-) -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Nathan F. <fr...@ro...> - 2001-03-27 20:57:40
|
On Mon, Mar 26, 2001 at 02:49:01PM -0600, William Harold Newman wrote: > In the longer run, the more I've worked on the type system in 0.6.11.x > (especially while adding INTERSECTION-TYPE, redoing the type methods, > debugging a NUMERIC-TYPE problem) the more I wished that CLOS was set > up in cold init, so that we could define fundamental things like type Why can this not be done? It doesn't seem like it should be *that* difficult to me. Then again, I may just be dreaming, as you are. :) And while we're at it (you might explain it anyway), what's the difference between cold and warm init? > classes completely in terms of CLOS, without having to use pre-CLOS > hacks like doing crude method dispatch without inheritance in > !INVOKE-TYPE-METHOD, and faking up inheritance with (CASE > (NUMERIC-TYPE-CLASS X) ..). I can't really tell how hard it would be > to rearrange the PCL code so that it could be cross-compiled and > cold-initialized; it might even be reasonably straightforward. (It > might also be impossibly difficult, of course.:-) Maybe I'll give it a > try one of these days, and see. If that could be done, then it would > become possible to replace other CLOS-isn't-ready-yet hacks (like the > DEF!STRUCT-TYPE-MAKE-LOAD-FORM-FUN stuff that's the problem here) with > ordinary CLOS definitions, which would be a nice solution to problems > like this. (It's a nice dream, anyway..:-) In similar spirit, why is it necessary to work around the non-prescence of CLOS? I was under the impression that PCL (and therefore SBCL's version of CLOS) was more of a bolt-on to the already existing type system that just happened to work with classes rather than a fundamental underpinning of the system. Is this correct or not? -- </nathan> fr...@ro... | http://www.rose-hulman.edu/~froydnj/ Yes, God had a deadline. So He wrote it all in Lisp. |
From: William H. N. <wil...@ai...> - 2001-03-28 13:20:37
|
On Tue, Mar 27, 2001 at 03:52:33PM -0500, Nathan Froyd wrote: > On Mon, Mar 26, 2001 at 02:49:01PM -0600, William Harold Newman wrote: > > In the longer run, the more I've worked on the type system in 0.6.11.x > > (especially while adding INTERSECTION-TYPE, redoing the type methods, > > debugging a NUMERIC-TYPE problem) the more I wished that CLOS was set > > up in cold init, so that we could define fundamental things like type > > Why can this not be done? It doesn't seem like it should be *that* > difficult to me. Then again, I may just be dreaming, as you are. :) I haven't looked at it enough to say, but just the way that so many things change their behavior depending on SB-PCL::*BOOT-STATE* leaves room for a lot of weirdness, if e.g. macro expansions depend on generic functions calls which get dispatched differently depending on the phase of the moon^H^H^H^H boot sequence applies. And in two failed attempts to get my mind around _The Art of the Meta-Object Protocol_, I haven't yet found any bounds on the bootstrap weirdness in PCL.. > And while we're at it (you might explain it anyway), what's the > difference between cold and warm init? Cold init is basically stuff that happens before you can get a command prompt, or what happens in !COLD-INIT before the tail call to TOPLEVEL-INIT. SBCL's warm init is the stuff that happens after it's sane enough to display a command prompt and compile files and stuff, but it still hasn't compiled and loaded various required things like CLOS and DESCRIBE. It's basically the stuff that happens in src/cold/warm.lisp. > > classes completely in terms of CLOS, without having to use pre-CLOS > > hacks like doing crude method dispatch without inheritance in > > !INVOKE-TYPE-METHOD, and faking up inheritance with (CASE > > (NUMERIC-TYPE-CLASS X) ..). I can't really tell how hard it would be > > to rearrange the PCL code so that it could be cross-compiled and > > cold-initialized; it might even be reasonably straightforward. (It > > might also be impossibly difficult, of course.:-) Maybe I'll give it a > > try one of these days, and see. If that could be done, then it would > > become possible to replace other CLOS-isn't-ready-yet hacks (like the > > DEF!STRUCT-TYPE-MAKE-LOAD-FORM-FUN stuff that's the problem here) with > > ordinary CLOS definitions, which would be a nice solution to problems > > like this. (It's a nice dream, anyway..:-) > > In similar spirit, why is it necessary to work around the non-prescence > of CLOS? I was under the impression that PCL (and therefore SBCL's > version of CLOS) was more of a bolt-on to the already existing type > system that just happened to work with classes rather than a fundamental > underpinning of the system. Is this correct or not? Certainly right now it's not a fundamental underpinning of the system. Basically, I'm fantasizing about letting it become a fundamental underpinning of the system. Right now nothing which is needed at the beginning of warm init, in particular nothing needed by the compiler, can be implemented in terms of CLOS, which is a drag. If CLOS could be set up in cold init, that would change. There are two issues here, I think: (1) The type system doesn't understand CLOS very well, and hasn't been completely updated to work with CLOS. There are mismatches between SB-PCL:X and CL:X for important values of X, like CLASS, FIND-CLASS, and STANDARD-CLASS. (2) The type system is implemented in terms of a cobbled-together system of class definition (!DEFINE-TYPE-CLASS) and method dispatch (!DEFINE-TYPE-METHOD, !INVOKE-TYPE-METHOD). This really doesn't work all that nicely, since this system lacks things like inheritance, leading to kludges like the CLASS slot of NUMERIC-TYPE (which expresses variants which would be better represented as true subclasses). It would be nice to have CLOS available in warm init, so that it would become possible to reimplement this stuff using CLOS. (It mightn't be much fun to try to rewrite it all at once, but it would be nice to be have the opportunity to rewrite any part which happens to be causing problems at the moment.) There are also some other cobbled-together things which could benefit from CLOSification (like MAKE-LOAD-FORM for DEF!STRUCT, and various ETYPECASEs in the implementation of the compiler), and it's not an option right now because they're needed in warm init; but if CLOS could be set up in cold init, it would become an option, and that'd be nice in the same way. I wasn't talking about issue (1), though it's seems as though you might (understandably) have thought I was. Issue (1) has come up repeatedly on the CMU CL mailing list (and maybe on the SBCL list too, I don't remember), and every knowledgeable person seems horrorstruck at the idea of straightening it out. I might contemplate straightening it out some day, but I have no hope that it will be surprisingly easy -- "predictably excruciating" is my guess. Issue (2) is what I was discussing in the quoted passage, and I don't remember seeing it discussed much before, probably mostly because it's not an end-user problem, and perhaps partly because it's not the kind of maintenance that the CMU CL maintainers are motivated to do. Now that I've started thinking about it, I have some hope that it might be surprisingly easy to do. But, because of *BOOT-STATE* and whatnot, it might turn out to be pretty nasty too. It's hard to say with any confidence without, basically, just trying to do it. Very likely someday I'll try it, but I have no idea when. -- William Harold Newman <wil...@ai...> software consultant PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |