[Asdf-devel] Program with metaclass on MKCL.

D. Martinez denis.martinez at live.com
Thu Dec 4 13:30:04 UTC 2014

I understand your hypothesis and I guess it makes sense.

I have done the testing as you suggest.
1. load-source-op is good
2. load-op fails on the first time. But it produces fasl.
3. load-op succeeds, on the second time.
In a larger program, the load-op seems to fail as many times as there are custom metaclasses so I have to repeat the operation that many times (certainly why I haven't had the idea to do that in the first place).

This is hardly a satisfactory solution but it is way better than nothing. For lack of a good solution it will do for now.
So, should I conclude that MKCL is at fault and redirect my bug reporting there ?

> To: asdf-devel at common-lisp.net
> From: pjb at informatimago.com
> Date: Thu, 4 Dec 2014 13:45:32 +0100
> Subject: Re: [Asdf-devel] Program with metaclass on MKCL.
> "D. Martinez" <denis.martinez at live.com> writes:
>> Thank you Pascal for pointing this out, but I don't think this relates to my problem.
>> I have looked at MKCL source and it was evident that it does not
>> implement superclass validation at this time.
>> Its MOP is not supported either in Closer-MOP so I assume it is somewhat young.
>> Quoting for clos/standard.lsp:
>>   ;; FIXME!!! Here should come the invocation of VALIDATE-SUPERCLASS!
>> As I have played with various CLs I noted that some required
>> VALIDATE-SUPERCLASS and some did not. I have not really checked what
>> is the standard's stance on this.
>> I can trace the error rising from defclass to standard.lsp in mkcl.
>> It is the cond clause from ensure-class-using-class. I display some more information to post here.
>>           ((not (eq (class-of class) metaclass))
>>            (format *error-output* "class: ~A~%" class)
>>            (format *error-output* "(class-of class): ~A~%" (class-of class))
>>            (format *error-output* "metaclass: ~A~%" metaclass)
>>            (error "When redefining a class, the metaclass can not change.")))
>> Which provides this output
>> class: &<The A-CLASS A 140012460512096>
>> (class-of class): &<The STANDARD-CLASS A-CLASS 140012464325568>
>> metaclass: &<The STANDARD-CLASS A-CLASS 140012460537344>
>> Error during command line arguments processing:
>> When redefining a class, the metaclass can not change..
>> This does show that A-CLASS is intanciated twice, and it is why the EQ test fails.
>> The mystery is why there happen two instanciations when I use ASDF.
> An explaination could be that MKCL uses the same environment for
> compilation and loading, and that ASDF does both COMPILE-FILE and LOAD
> (when the file is not already compiled).
> A compiler doesn't have to define the class completely when compiling; it
> only has to do the following:
> If a defclass form appears as a top level form, the compiler must
> make the class name be recognized as a valid type name in subsequent
> declarations (as for deftype) and be recognized as a valid class
> name for defmethod parameter specializers and for use as the
> :metaclass option of a subsequent defclass. The compiler must make
> the class definition available to be returned by find-class when its
> environment argument is a value received as the environment
> parameter of a macro.
> You could test and compare:
> 1.1- remove the fasl files.
> 1.2- from a fresh image, (asdf:oos 'asdf:load-source-op :hello)
> this only LOAD the source file (situation :execute)
> 2.1- remove the fasl files (if any)
> 2.2- from a fresh image, (asdf:oos 'asdf:load-op :hello)
> this uses COMPILE-FILE and LOAD (situations :compile-toplevel and :load-toplevel)
> 3.1- keep the fasl files from the previous compilation.
> 3.2- from a fresh image, (asdf:oos 'asdf:load-op :hello)
> this should only LOAD the fasl file (situation :load-toplevel)
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> “The factory of the future will have only two employees, a man and a
> dog. The man will be there to feed the dog. The dog will be there to
> keep the man from touching the equipment.” -- Carl Bass CEO Autodesk
> _______________________________________________
> Asdf-devel mailing list
> Asdf-devel at common-lisp.net
> http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel

More information about the asdf-devel mailing list