<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Dec 4, 2014 at 5:20 AM, D. Martinez <span dir="ltr"><<a href="mailto:denis.martinez@live.com" target="_blank">denis.martinez@live.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello. Being new to "serious" CL programming I am hitting a brick wall right now in one CLOS project.<br>
After some time of infructuous searching I cannot find the source of my problem, which may be of either MKCL or ASDF but I lack the knowledge to debug this. Mr. JCB, who I have seen active on this list, may (hopefully!) be able to shed some light on the issue.<br>
<br></blockquote><div><br></div><div>This is definitely a MKCL 1.1.X bug, and one of the "unexpected consequence" variety.  ASDF is not concerned by this problem. It may have helped in revealing the issue but nothing more, and it played only an incidental role in the matter.<br><br></div><div>This bug is fixed in MKCL 1.2.0 (currently only in my own private branch) but I do not plan to back port this fix to MKCL 1.1.X, the change-set would just be way too large.<br><br></div><div>Pascal Bourguignon is right in pointing out the fact that CL:COMPILE-FILE on MKCL 1.1.X is persistently polluting the global environment of its running image with by-products of the compilation (structures, classes, symbols, etc.). This has been an hereditary defect of the KCL family from its origins (circa 1984) until now. MKCL 1.2.0 features, among other things, a vastly improved separation between the global environment and the (transient) compilation environment. And the code you provided compiles and loads in it exactly as you would expect, without error, because of that separation.<br><br></div><div>MKCL 1.2.0 has been in the works for far too long (almost two years now) but it is not quite ready for release yet (I need to finish 2 major features and add a new one). I hope to be able to initiate its release process in 2 to 3 months from now.<br><br></div><div>In the meantime there is a workaround for this bug possible in MKCL 1.1.X. It is simple but not without some drawback.<br></div><div><br></div><div>All you need to do is to bind special (dynamic) variable clos::*redefine-class-in-place* to T before doing any call (direct or indirect) to cl:load. Something like this would do, I tested it in my current MKCL 1.1.10 git:<br><br>(let ((clos::*redefine-class-in-place* t)) (asdf::load-system :hello))<br><br></div><div>With this the global environment pollution of CL::COMPILE-FILE is paved over, and you can merrily attend the rest of your business.<br><br></div><div>The drawback is that by doing so you may wake up cl:update-instance-for-redefined-class and its friend of the class redefinition protocol. And that protocol is definitely thread-unsafe!<br><br></div><div>If you are sure not to share among threads any instance of your classes that would exist through the compilation/redefinition step of the said classes then you are safe. Otherwise you may witness surprising and unexpected results and I waive any responsibility into that since you have been warned.<br><br></div><div>Regards,<br><br></div><div>JCB<br><br></div><div>P.S.: Bug reports of the quality of yours are a treat, thank you so much.<br><br></div></div></div></div>