Re: missing methods
Christopher Stacy <[email protected]> Fri, 3 Apr 2026 05:35:54 -0400
| Newsgroups | gmane.lisp.steel-bank.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============2639936368080263225==
Content-Type: multipart/alternative;
boundary="------------hG3XVTAh70iwWFgH1q7vQeeH"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------hG3XVTAh70iwWFgH1q7vQeeH
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Here are the results of my latest attempt at testing this.
I tarted up the system, made an entirely new directory elsewhere, dumped
the system in there, and changed its name in the ASD and made the new
ASDF CONF file. All my tests are in fresh instances of SBCL. (And I went
so far as to manually delete the .cache files to make sure ASDF is
compiling the right files!)
Here's my test incantation:
(progn
(asdf:clear-configuration)
(asdf:compile-system :bork :force t)
(asdf:load-system :bork)
(in-package :o))
Same incantation (other system name) when doing the A/B system testing.
The rest of the test consists of calling the GF on the atom and cons
inputs. I modified the methods with some PRINT statements so I'm sure
what I'm seeing.
ORIGINAL FAILURE MODE:
Two defemthods one after the other.
The second one gets defined, the first one does not.
No compile-time errors or warnings,
just NO-APPLICABLE-METHOD when I try one of them.
Manually doing slime-compile-defun on the missing one makes it properly
defined. and everything works.
NOW:
Hold on to your hats, kids, it's going to get weird.
The methods are defined, one right after the other, in source file One.
If I move them to a subsequent source file Two, they both get compiled
and work!
Well, sorta.
In file One, before I diked them out, they were immediately followed by
a regular defun FOOBAR. Now when I compile, I get an undefined function
warning for FOOBAR. And guess what? There's nothing wrong with that
function, either, and just like the missing defmethod, I can
slime-compile-defun it to fix everything!
So whatever is in that position in the source file seems to get skipped
over by the compiler! First it was a missing defmethod. Now it's a
missing defun. The obvious question is: What is right before that in
the source?
Well, it's another defmethod. It happens to be an entirely different
method, on the same class as the one that was skipped.
But wait, there's more!
If I put (warn "WTF")
And the defun does not get skipped.
Soooo, I put the defmethods back there, put the WTF in front of them,
and then EVERYTHING COMPILES AND WORKS properly.
It doesn't seem to be the defmethods or CLOS. It's just that*whatever
form is in that location in the source file does not get compiled*. And
the warn does not go off, either. I can replace it with a NIL and get
the same behavior: the form there gets eaten, is not compiled, and
everything works.
So what evil thing in this file, that must be right above the skipped
form, is causing this? I commented out whatever it was. Nothing changes
-- the form still gets eaten. Something before that, then? Nope. And I
tediously went through commenting out one form after another and
recompiling in a fresh sbcl and retesting.
And then I ran out of things to comment out.
At this point, there is the in-package at the top of the file, then the
NIL/WARN, then the form that used to get skipped, and the rest of the
original source file that has always been compiled without problem. If I
take the NIL/WARN out, the next form gets skipped. Doesn't matter what
the next form is.
(in-package :foo)
(warn "skip") ;; remove and the next form will be skipped
(defwhatever sometimes-skipped ()...)
(more stuff that never had a problem...)
There can be any forms (or as in the above illustration, no) forms
between the in-pacakage and the warn. Anything above the warn gets
compiled, anything after the warn gets compiled. Take the warn away, and
one form (any defun or defmethod, anyway) will be skipped instead of the
warn.
I know this sounds impossible, like I must be doing something else
without realizing it, that messes up the test. I think I was perfectly
methodical. It does not make any sense. If someone came to me with this
story I would not believe them.
I am going to assume that some previous file is somehow corrrupting
things. I cannot even imagine what this could mean or how it could
happen. It is too weird.
(Before I stumbled on this business of inserting the warn, I was
removing whole files and then portions of the files, trying to narrow it
down. This is really hard to get to compile. Another experiment I am
going to do is to just try compiling the system in another Lisp
implementation. CCL or Lispworks.)
I've now spent about 40 hours on this problem, and if I don't get it
figured out soon, I will just leave that WARN in there, since it solves
the problem, and hope for the best.
Suggestions?
--------------hG3XVTAh70iwWFgH1q7vQeeH
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font size="4"> Here are the results of my latest attempt at
testing this.<br>
<br>
I tarted up the system, made an entirely new directory elsewhere,
dumped the system in there, and changed its name in the ASD and
made the new ASDF CONF file. All my tests are in fresh instances
of SBCL. (And I went so far as to manually delete the .cache files
to make sure ASDF is compiling the right files!)<br>
Here's my test incantation:</font>
<p><font size="4">(progn<br>
(asdf:clear-configuration)<br>
(asdf:compile-system :bork :force t)<br>
(asdf:load-system :bork)<br>
(in-package :o))<br>
<br>
Same incantation (other system name) when doing the A/B system
testing. The rest of the test consists of calling the GF on the
atom and cons inputs. I modified the methods with some PRINT
statements so I'm sure what I'm seeing.<br>
<br>
ORIGINAL FAILURE MODE:<br>
Two defemthods one after the other.<br>
The second one gets defined, the first one does not.<br>
No compile-time errors or warnings,<br>
just NO-APPLICABLE-METHOD when I try one of them.<br>
Manually doing slime-compile-defun on the missing one makes it
properly defined. and everything works.<br>
<br>
</font><font size="4">NOW:<br>
Hold on to your hats, kids, it's going to get weird.<br>
<br>
The methods are defined, one right after the other, in source
file One. If I move them to a subsequent source file Two, they
both get compiled and work!<br>
<br>
Well, sorta.<br>
In file One, before I diked them out, they were immediately
followed by a regular defun FOOBAR. Now when I compile, I get an
undefined function warning for FOOBAR. And guess what? There's
nothing wrong with that function, either, and just like the
missing defmethod, I can slime-compile-defun it to fix
everything!<br>
<br>
<br>
So whatever is in that position in the source file seems to get
skipped over by the compiler! First it was a missing defmethod.
Now it's a missing defun. The obvious question is: What is
right before that in the source?<br>
<br>
<br>
</font></p>
<p><font size="4">Well, it's another defmethod. It happens to be an
entirely different method, on the same class as the one that was
skipped.<br>
<br>
But wait, there's more!<br>
If I put <font face="monospace">(warn "WTF")</font><br>
And the defun does not get skipped.<br>
<br>
Soooo, I put the defmethods back there, put the WTF in front of
them, and then EVERYTHING COMPILES AND WORKS properly.<br>
<br>
It doesn't seem to be the defmethods or CLOS. It's just that<b>
whatever form is in that location in the source file does not
get compiled</b>. And the <font face="monospace">warn</font>
does not go off, either. I can replace it with a <font
face="monospace">NIL</font> and get the same behavior: the
form there gets eaten, is not compiled, and everything works.<br>
<br>
So what evil thing in this file, that must be right above the
skipped form, is causing this? I commented out whatever it was.
Nothing changes -- the form still gets eaten. Something before
that, then? Nope. And I tediously went through commenting out
one form after another and recompiling in a fresh sbcl and
retesting.<br>
<br>
And then I ran out of things to comment out.<br>
At this point, there is the in-package at the top of the file,
then the NIL/WARN, then the form that used to get skipped, and
the rest of the original source file that has always been
compiled without problem. If I take the NIL/WARN out, the next
form gets skipped. Doesn't matter what the next form is.<br>
<br>
</font><font face="monospace">(in-package :foo)<br>
(warn "skip") ;; remove and the next form will be skipped<br>
(defwhatever sometimes-skipped ()...)<br>
(more stuff that never had a problem...)</font></p>
<p><font size="4">There can be any forms (or as in the above
illustration, no) forms between the in-pacakage and the warn.
Anything above the warn gets compiled, anything after the warn
gets compiled. Take the warn away, and one form (any defun or
defmethod, anyway) will be skipped instead of the warn.<br>
<br>
I know this sounds impossible, like I must be doing something
else without realizing it, that messes up the test. I think I
was perfectly methodical. It does not make any sense. If someone
came to me with this story I would not believe them.<br>
<br>
I am going to assume that some previous file is somehow
corrrupting things. I cannot even imagine what this could mean
or how it could happen. It is too weird.<br>
<br>
(Before I stumbled on this business of inserting the warn, I was
removing whole files and then portions of the files, trying to
narrow it down. This is really hard to get to compile. Another
experiment I am going to do is to just try compiling the system
in another Lisp implementation. CCL or Lispworks.)<br>
<br>
I've now spent about 40 hours on this problem, and if I don't
get it figured out soon, I will just leave that WARN in there,
since it solves the problem, and hope for the best.<br>
<br>
Suggestions?<br>
<br>
<br>
</font></p>
<p><font size="4"><br>
<br>
<br>
<br>
<br>
</font></p>
<p><font size="4"><br>
</font></p>
<p><font size="4"><br>
<br>
</font><br>
<font size="4"><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</font></p>
<p><font size="4"><br>
</font></p>
</body>
</html>
--------------hG3XVTAh70iwWFgH1q7vQeeH--
--===============2639936368080263225==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============2639936368080263225==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help
--===============2639936368080263225==--