Hi,
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.
Rudi
Sent from my iPad
On 4 Aug 2012, at 14:00, Erik Huelsmann ehuels@gmail.com wrote:
Even more puzzling:
There seems to be a difference in behaviour between the slime C-c C-c, C-c C-r behaviour (compile a form, evaluate a region) and running a PROGN with the forms from the slime repl.
Sure hope others can help out here. All I can do now is create the correct D-M-C implementation but writing tests and verifying them for their behaviour is not possible this way.
BTW: the PROGN and the C-c C-c approach probably differ in that one is interpreted and the other compiled. So, it looks like an interaction between compilation and D-M-C.
Bye,
Erik.
On Sat, Aug 4, 2012 at 11:31 AM, Erik Huelsmann ehuels@gmail.com wrote:
Hi all,
In an attempt to solve ticket 201 and everything related (now that I'm into it anyway), I've been staring at the failure of one of ABCL's own tests and can't seem to understand what's going on.
So, DMC-TEST-MC.1 is failing because it uses a non-standard METHOD-QUALIFIER. STD-COMPUTE-EFFECTIVE-METHOD throws an error when matching the qualifiers of the defined methods with the method groups and finds that the method combination isn't one of type long-form. However, the problem is: it really *is* of type long form. However, this seems to happen *only* in the compiled case....s
So, I inserted a trace:
(eval-when (:compile-toplevel) (trace mop::STD-COMPUTE-EFFECTIVE-METHOD))
and extracted the test form from outside the test case, in order to be able to see the error triggered (RT just prints #<simple-error >):
(dmc-test-mc.1 :k 1)
The result is this backtrace:
[java] 0: (MOP::STD-COMPUTE-EFFECTIVE-METHOD #<STANDARD-GENERIC-FUNCTION DMC-TEST-MC.1 {10D3D99}> #<METHOD-COMBINATION {69B861}> (#<STANDARD-METHOD {C821EF}>))which clearly shows the method combination is of type METHOD-COMBINATION and not of type LONG-METHOD-COMBINATION.
I do understand that this is the error, but I can't for the life of me figure out how we get into the situation that the method combination being instantiated is of the resulting type METHOD-COMBINATION...
Any help on debugging or additional insights would be extremely appreciated!
Bye,
Erik.