D. Martinez wrote: > 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 ?
One thing I notice is that you are defining like this: (defclass A (standard-object) () (:metaclass A-class)) I don't believe that this is in general correct. Looking at the spec: Each superclass-name argument specifies a direct superclass of the new class. If the superclass list is empty, then the superclass defaults depending on the metaclass, with standard-object being the default for standard-class. As I read this, you should drop the specification of STANDARD-OBJECT, because the implementation is licensed to choose a more appropriate default superclass. If it does, probably you want that more appropriate superclass. I don't mean to be troublesome, but if you are new to serious CL programming maybe 1. You should try using a more mature CL implementation. 2. You should avoid the MOP. Unless you are doing something that, with all due respect, someone who's new to serious CL programming shouldn't be doing, you don't need the MOP. CLOS is already so powerful, that unless you are doing something that fundamentally changes the object system, you don't need the MOP. And see my earlier point: if you are new to serious CL programming, you shouldn't be fundamentally changing the object system. Cheers, r > > ---------------------------------------- >> 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 _______________________________________________ Asdf-devel mailing list Asdf-devel@common-lisp.net http://mailman.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
