[armedbear-devel] CLOS / D-M-C tests failure DMC-TEST-MC.1 help requested

Erik Huelsmann ehuels at gmail.com
Tue Aug 7 11:47:27 UTC 2012


Hi Rudi,

I see similar errors in other situations. My guess is that at load time,
> classes get redefined but object literals from compile-time (with the
> compile-time class) stay around in the fasl. These literals then have (come
> load-time) a class with the same name but different identity than the one
> that find-class returns.
>

Thinking about this assumption, I'm still very much puzzled what in our
code base would instate an object of class METHOD-COMBINATION. That is, not
of one of its two subclasses (SHORT-* or LONG-*), but of the direct type.
>From what I searched our code base I can't find any code which would do
that (i.e. instantiate an object of that type).

Also, when looking at the MACROEXPAND-ALL output of
DEFINE-METHOD-COMBINATION, DEFGENERIC and DEFMETHOD, there don't seem to be
any direct references to any objects or classes. E.g. the method
combination designation in DEFGENERIC gets saved as a symbol which is
passed through to our internal %DEFGENERIC function which is called upon
evaluation of the DEFGENERIC form be it compiled or interpreted.

Also, compilation of DEFINE-METHOD-COMBINATION, DEFGENERIC and DEFMETHOD
don't have any other compile-time side effects than that the symbol of the
generic function is (temporarily) assigned a function to its symbol
function slot. Meaning D-M-C compilation is completely compile-time side
effect free, as far as I can tell. Which would be completely contrary to
your expectation.

So, I'm still very puzzled. What would be our best way forward? I'd love to
fix this, because I think we'll run into it later as well in "real world"
cases. Would getting together on IRC to chat about it be a good next step?
(One issue that I see is that all these tests used to pass when I wrote
them. So at some point something must have changed which made us
incompatible with ourselves. That's another reason why I at least want to
understand what's going on...)


Bye,

Erik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20120807/a566f19c/attachment.html>


More information about the armedbear-devel mailing list