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