On Thu, Dec 4, 2014 at 5:20 AM, D. Martinez <denis.martinez(a)live.com> wrote:
> Hello. Being new to "serious" CL programming I am hitting a brick wall
> right now in one CLOS project.
> 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.
>
>
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.
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.
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.
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.
In the meantime there is a workaround for this bug possible in MKCL 1.1.X.
It is simple but not without some drawback.
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:
(let ((clos::*redefine-class-in-place* t)) (asdf::load-system :hello))
With this the global environment pollution of CL::COMPILE-FILE is paved
over, and you can merrily attend the rest of your business.
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!
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.
Regards,
JCB
P.S.: Bug reports of the quality of yours are a treat, thank you so much.
