<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 8, 2014 at 11:16 AM, Faré <span dir="ltr"><<a href="mailto:fahree@gmail.com" target="_blank">fahree@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right now, I have it busy-looping into plenty of<br>
;;; Loading "/home/tunes/src/mkcl/contrib/alexandria_2012_08_14/alexandria.asd"<br>
<br>
... </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This suggests that one of the things you need to do is have tighter<br>
control over the CL_SOURCE_REGISTRY<br>
and ASDF_OUTPUT_TRANSLATIONS around this compilation, to prevent the<br>
unwanted ASDF upgrade.<br>
<br></blockquote><div><br></div><div>I have to admit that interference from the process environment was not on my list of identified threats.<br></div><div>I just committed two lines in my src/build-asdf-contrib.lsp to guard against that. I hope its enough.<br>
</div><div>I looked into the source code of ASDF and saw that it read the content of at least 11 environment variables!<br></div><div>Should I be paranoid and guard also against the 9 nine others beside the two you mentioned?<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">...<br><div class="">
>> I will back port to MKCL 1.1.9 the fixes I currently have in MKCL 1.2.0.<br>
>> You will have them in the git repository in a few hours.  compiler::*speed*<br>
>> is going away anyway since proclaim at al. need to work even when the "CMP"<br>
>> module has not been loaded, use si::*speed* instead. Also, nickname "C" for<br>
>> package "COMPILER" has been removed since MKCL 1.1.0 at least (too clash<br>
>> prone).<br>
>><br>
><br>
> Done and pushed to the git repo.  So you now have si::*speed*, si::*safety*,<br>
> si::*space*, si::*debug* and si::*compilation-speed* that store the global<br>
> level environment for "optimize", each with integer values between 0 and 3<br>
> inclusively by convention. Crude but does the job...<br>
><br>
</div>Great. Is it OK if I don't include compatibility with older versions of MKCL?<br>
<div class=""><br></div></blockquote><div><br>Please DO NOT try to include compatibility with older versions of MKCL before 1.1.9 since that aspect of them is simply a hopeless broken mess that I can only wish to forget quickly.<br>
<br><br></div></div></div></div>