![](https://secure.gravatar.com/avatar/e116be369e48b01a81c5e04706bf70fe.jpg?s=120&d=mm&r=g)
On Tue, Apr 8, 2014 at 11:16 AM, Faré <fahree@gmail.com> wrote:
Right now, I have it busy-looping into plenty of ;;; Loading "/home/tunes/src/mkcl/contrib/alexandria_2012_08_14/alexandria.asd"
...
This suggests that one of the things you need to do is have tighter
control over the CL_SOURCE_REGISTRY and ASDF_OUTPUT_TRANSLATIONS around this compilation, to prevent the unwanted ASDF upgrade.
I have to admit that interference from the process environment was not on my list of identified threats. I just committed two lines in my src/build-asdf-contrib.lsp to guard against that. I hope its enough. I looked into the source code of ASDF and saw that it read the content of at least 11 environment variables! Should I be paranoid and guard also against the 9 nine others beside the two you mentioned?
...
I will back port to MKCL 1.1.9 the fixes I currently have in MKCL 1.2.0. You will have them in the git repository in a few hours. compiler::*speed* is going away anyway since proclaim at al. need to work even when the "CMP" module has not been loaded, use si::*speed* instead. Also, nickname "C" for package "COMPILER" has been removed since MKCL 1.1.0 at least (too clash prone).
Done and pushed to the git repo. So you now have si::*speed*, si::*safety*, si::*space*, si::*debug* and si::*compilation-speed* that store the global level environment for "optimize", each with integer values between 0 and 3 inclusively by convention. Crude but does the job...
Great. Is it OK if I don't include compatibility with older versions of MKCL?
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.