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@common-lisp.net From: pjb@informatimago.com Date: Thu, 4 Dec 2014 13:45:32 +0100 Subject: Re: [Asdf-devel] Program with metaclass on MKCL.
"D. Martinez" denis.martinez@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@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel