Re: missing methods
Christopher Stacy <[email protected]> Thu, 2 Apr 2026 03:33:49 -0400
| Newsgroups | gmane.lisp.steel-bank.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============7155877148903163057==
Content-Type: multipart/alternative;
boundary="------------Mcef0SpxnLTXBuJLsrcWs0c6"
Content-Language: en-US
This is a multi-part message in MIME format.
--------------Mcef0SpxnLTXBuJLsrcWs0c6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
SBCL 2.4.6 on Mac x86. 2.4.6 on Linux x86.
I did some more experiments.
There are two methods on a generic function,
with these signatures.
(defmethod frob ((clause dispatch-class)
x
y))
(defmethod frob ((clause dispatch-class)
(x cons)
y))
They are together just like that in the source file.
The file has other stuff in it, all of which compiles properly.
Moving the defmethods to their own file (before or after) does nothing
-- this doesn't seem to have anything to do with other code in the system.
The defclasses and defgeneric are in earlier files.
(defgeneric frob (clause token rest))
The bug is that these methods don't get compiled!
There are no compiler messages about; all looks normal
But when you try to invoke them, it's NO-APPLICABLE-METHOD.
However, if you then edit the source file in slime and compile the
definitions from there, the methods appear and everything works!
I then did two experiments.
First, I replicated the class hierarchy and these methods in a new
system. In that simplest scenario, the bug does not happen.
Then, upon less panicked observation, I noticed that (in the real
system) the CONS method /was/ actually getting compiled. It is only the
unspecialized method that is entirely missing. I used the inspector on
the GF, and saw that one method /was/ there.
If I rearrange the source definitions so that the CONSP method comes
first, then both methods get compiled. That is my workaround.
In the trivial test system, the order does not matter. But that source
file in both systems is exactly the same. (The test system has only two
files. The other is the entire class hierarchy. Those defclass and
defgeneric are in the same order as in the real system. There's nothing
interesting about them, they are trivial inheritance. It's a parser, by
the way.
There are no other methods for that GF in either system.
The real system has subclasses, with other methods on the class,
superclasses, and subclasses.
The fact that just swapping the order of those two defmethods in the
source file (and there's nothing between them) convinces me that this is
some compiler bug. I cannot imagine what it is.
Alternatively, am I doing something so stupid I can't see it?
--------------Mcef0SpxnLTXBuJLsrcWs0c6
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>
<p><font size="4">SBCL 2.4.6 on Mac x86. 2.4.6 on Linux x86.</font></p>
<p><font size="4">I did some more experiments.</font></p>
<p><font size="4">There are two methods on a generic function,<br>
with these signatures.<br>
<br>
</font><font face="monospace">(defmethod frob ((clause
dispatch-class)<br>
x <br>
y))<br>
<br>
(defmethod frob ((clause dispatch-class)<br>
(x cons)<br>
y))</font></p>
<p><font size="4">They are together just like that in the source
file.<br>
The file has other stuff in it, all of which compiles properly.<br>
Moving the defmethods to their own file (before or after) does
nothing -- this doesn't seem to have anything to do with other
code in the system.<br>
<br>
The defclasses and defgeneric are in earlier files.<br>
</font><font face="monospace">(defgeneric frob (clause token
rest))</font><font size="4"><br>
<br>
The bug is that these methods don't get compiled!<br>
There are no compiler messages about; all looks normal<br>
But when you try to invoke them, it's NO-APPLICABLE-METHOD.<br>
<br>
However, if you then edit the source file in slime and compile
the definitions from there, the methods appear and everything
works!<br>
<br>
I then did two experiments.<br>
First, I replicated the class hierarchy and these methods in a
new system. In that simplest scenario, the bug does not happen.<br>
<br>
Then, upon less panicked observation, I noticed that (in the
real system) the CONS method <i>was</i> actually getting
compiled. It is only the unspecialized method that is entirely
missing. I used the inspector on the GF, and saw that one method
<i>was</i> there.<br>
<br>
If I rearrange the source definitions so that the CONSP method
comes first, then both methods get compiled. That is my
workaround.<br>
<br>
In the trivial test system, the order does not matter. But that
source file in both systems is exactly the same. (The test
system has only two files. The other is the entire class
hierarchy. Those defclass and defgeneric are in the same order
as in the real system. There's nothing interesting about them,
they are trivial inheritance. It's a parser, by the way.<br>
<br>
There are no other methods for that GF in either system.<br>
The real system has subclasses, with other methods on the class,
superclasses, and subclasses.<br>
<br>
The fact that just swapping the order of those two defmethods in
the source file (and there's nothing between them) convinces me
that this is some compiler bug. I cannot imagine what it is.<br>
<br>
Alternatively, am I doing something so stupid I can't see it?<br>
<br>
<br>
</font></p>
</body>
</html>
--------------Mcef0SpxnLTXBuJLsrcWs0c6--
--===============7155877148903163057==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--===============7155877148903163057==
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
--===============7155877148903163057==--