Dear JCB,
I managed to compile MKCL from git, but only after I updated its ASDF.
Unless you have a good reason, I recommend you only include a bootstrapped version of asdf.lisp in your source tree. You should of course keep generating it from an asdf checkout, and send us any local patch you create (thanks a lot for that!)
In 3.1.0.109, I have an attempt at implementing get-optimization-settings on most implementations (allegro is still missing, plus ecl-bytecmp, genera, corman, mcl); my implementation for MKCL does not work and/or proclaim does not work: c::*speed* exists but isn't updated by proclaim. Can you help me fix that?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Compulsory apologies mostly train children to say things they don't mean — that is, to lie. ― Alfie Kohn, 'Unconditional Parenting'
On Mon, Apr 7, 2014 at 8:22 AM, Faré fahree@gmail.com wrote:
Dear JCB,
I managed to compile MKCL from git, but only after I updated its ASDF.
I just did the following sequence on a fresh Ubuntu 13.10 x86 with proper tools and libs installed without any incident:
git clone git://common-lisp.net/projects/mkcl/mkcl.git cd mkcl ./configure make all sudo make install
So I don't see what your problem could have been. Could you cut and paste the exact error messages you received.
Unless you have a good reason, I recommend you only include a bootstrapped version of asdf.lisp in your source tree. You should of course keep generating it from an asdf checkout, and send us any local patch you create (thanks a lot for that!)
I am building a separate uiop module out of that set of sources so that part would have to stay anyway. File asdf.lisp is not an original source file but a derived one, concatenated from the real original source files kept in the asdf directory, as you well know, so it is not really a proper base for the build process. Further I do not see any real and concrete inconvenience to the current layout of things in contrib/asdf. To the contrary, I find it very convenient when I need to diff against a more current asdf git clone or tarball.
In 3.1.0.109, I have an attempt at implementing get-optimization-settings on most implementations (allegro is still missing, plus ecl-bytecmp, genera, corman, mcl); my implementation for MKCL does not work and/or proclaim does not work: c::*speed* exists but isn't updated by proclaim. Can you help me fix that?
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).
On Tue, Apr 8, 2014 at 1:07 AM, Jean-Claude Beaudoin < jean.claude.beaudoin@gmail.com> wrote:
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...
: Faré
: JCB
: JCB
I managed to compile MKCL from git, but only after I updated its ASDF.
I just did the following sequence on a fresh Ubuntu 13.10 x86 with proper tools and libs installed without any incident:
git clone git://common-lisp.net/projects/mkcl/mkcl.git cd mkcl ./configure make all sudo make install
So I don't see what your problem could have been. Could you cut and paste the exact error messages you received.
Right now, I have it busy-looping into plenty of ;;; Loading "/home/tunes/src/mkcl/contrib/alexandria_2012_08_14/alexandria.asd"
the last messages before that are: ;;; Loading "asdf.fasb" ;;; Loading "/home/tunes/cl/asdf/asdf.asd" ;;; Loading "/home/tunes/cl/asdf/uiop/uiop.asd" ;;; Loading "/home/tunes/.cache/common-lisp/mkcl-1.1.9-linux-x64/home/tunes/cl/asdf/build/asdf.fas" ; Upgrading ASDF from version 3.0.3.0.1 to version 3.1.0.111 ;;; Warning: The following packages were referenced in compiled file (/home/tunes/cl/asdf/build/asdf.lisp) but d o not exist yet: (ASDF/PARSE-DEFSYSTEM). ;;; Warning: The following packages were referenced in compiled file (NIL) but do not exist yet: (ASDF/PARSE-DEF SYSTEM). ;;; 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.
On the other hand, this suggests a bug in ASDF itself and how it upgrades, that I need to investigate. Sigh.
Unless you have a good reason, I recommend you only include a bootstrapped version of asdf.lisp in your source tree. You should of course keep generating it from an asdf checkout, and send us any local patch you create (thanks a lot for that!)
I am building a separate uiop module out of that set of sources so that part would have to stay anyway. File asdf.lisp is not an original source file but a derived one, concatenated from the real original source files kept in the asdf directory, as you well know, so it is not really a proper base for the build process. Further I do not see any real and concrete inconvenience to the current layout of things in contrib/asdf. To the contrary, I find it very convenient when I need to diff against a more current asdf git clone or tarball.
Oh, that's great — and I commend your attention to detail. Another option you might consider is a git module, but I understand it's heavier weight.
In 3.1.0.109, I have an attempt at implementing get-optimization-settings on most implementations (allegro is still missing, plus ecl-bytecmp, genera, corman, mcl); my implementation for MKCL does not work and/or proclaim does not work: c::*speed* exists but isn't updated by proclaim. Can you help me fix that?
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).
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?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Tomorrow, I stop procrastinating.
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.
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?
grep 'getenv.*"' *p u*/*p actually finds 15 different variables that *may* be used. But when these two are controlled, all other variables are unused, except for __CL_ARGV0 that you shouldn't care about and TMPDIR (or TEMP, on Windows) that should be left in the user's control — if it's bogus, a lot more things than ASDF will break; and if the user wants to divert it, he probably knows what he's doing.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Love doesn't scale. — Eric S. Raymond
OK, here's a better patch for MKCL and ASDF. You were having ASDF re-load itself before it's configured; that's the recipe for loading the one that is in the user's normal configuration, environment variable or not. Later in the script, you correctly configure ASDF, and ASDF 3 does its own reloading automatically, so you don't need this step. Actually, if you're upgrading from ASDF2, you'll need more steps than that, before of the package punting; but you're not, are you?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Poetry is what gets lost in translation." — Robert Frost
On Wed, Apr 9, 2014 at 8:36 AM, Faré fahree@gmail.com wrote:
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?
grep 'getenv.*"' *p u*/*p actually finds 15 different variables that *may* be used. But when these two are controlled, all other variables are unused, except for __CL_ARGV0 that you shouldn't care about and TMPDIR (or TEMP, on Windows) that should be left in the user's control — if it's bogus, a lot more things than ASDF will break; and if the user wants to divert it, he probably knows what he's doing.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Love doesn't scale. — Eric S. Raymond
Question of clarification: how does MKCL interact with the ASDF release process?
MKCL will bundle a specially-tailored version of ASDF, is that right?
If so, there is no requirement that we wait for completion of the MKCL version before releasing ASDF 3.1, is there? What we want is just an ASDF that is a suitable candidate for bundling. Is that correct?
Sent from my iPad
On Apr 16, 2014, at 12:44, Faré fahree@gmail.com wrote:
OK, here's a better patch for MKCL and ASDF. You were having ASDF re-load itself before it's configured; that's the recipe for loading the one that is in the user's normal configuration, environment variable or not. Later in the script, you correctly configure ASDF, and ASDF 3 does its own reloading automatically, so you don't need this step. Actually, if you're upgrading from ASDF2, you'll need more steps than that, before of the package punting; but you're not, are you?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org "Poetry is what gets lost in translation." — Robert Frost
On Wed, Apr 9, 2014 at 8:36 AM, Faré fahree@gmail.com wrote:
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?
grep 'getenv.*"' *p u*/*p actually finds 15 different variables that *may* be used. But when these two are controlled, all other variables are unused, except for __CL_ARGV0 that you shouldn't care about and TMPDIR (or TEMP, on Windows) that should be left in the user's control — if it's bogus, a lot more things than ASDF will break; and if the user wants to divert it, he probably knows what he's doing.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Love doesn't scale. — Eric S. Raymond
<0001-Don-t-re-load-asdf-before-you-configure-it-or-you-mi.patch> _______________________________________________ Asdf-devel mailing list Asdf-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
On Wed, Apr 16, 2014 at 10:13 PM, Robert P. Goldman rpgoldman@sift.infowrote:
Question of clarification: how does MKCL interact with the ASDF release process?
MKCL tries to bundle the latest official release of ASDF at the time of its own release and tries to do so at most a few months behind the ASDF release timeline.
MKCL will bundle a specially-tailored version of ASDF, is that right?
I much prefer to bundle with the least amount of tailoring possible (ideally none, just drop-in).
If so, there is no requirement that we wait for completion of the MKCL version before releasing ASDF 3.1, is there? What we want is just an ASDF that is a suitable candidate for bundling. Is that correct?
I don't see MKCL as a reference or a required platform for ASDF newest releases. Granting to a Common Lisp implementation any of such statuses is solely your privilege as ASDF maintainer. But obviously, if you were to promote MKCL to any of those levels I would naturally be flattered. :-)
As you say, a ASDF version that is a suitable candidate for bundling is perfectly fine. My original idea was that ASDF 3.1 would come bundled with MKCL 1.2.0 due a few months from now, but I'd like very much that ASDF 3.1 be good to run on the latest MKCL 1.1.X also (bundled or not).
This email is just to inform you that I performed the following in a MKCL 1.1.8 a few minutes ago:
-------------------------------------------------------
(asdf:load-system :asdf)
;;; Loading "/home/jean-claude/CL/MKCL/dev/releases/mkcl-1.1/git/mkcl.git/src/test/asdf/asdf.asd" ;;; Loading "/home/jean-claude/CL/MKCL/dev/releases/mkcl-1.1/git/mkcl.git/src/test/asdf/uiop/uiop.asd" ;;; Compiling /home/jean-claude/CL/MKCL/dev/releases/mkcl-1.1/git/mkcl.git/src/test/asdf/build/asdf.lisp. ; Upgrading ASDF from version 3.0.3.0.1 to version 3.1.0.114 ;;; Finished compiling /home/jean-claude/CL/MKCL/dev/releases/mkcl-1.1/git/mkcl.git/src/test/asdf/build/asdf.lisp. ;;; Loading "/home/jean-claude/.cache/common-lisp/mkcl-1.1.8-linux-x64/home/jean-claude/CL/MKCL/dev/releases/mkcl-1.1/git/mkcl.git/src/test/asdf/build/asdf.fas" T
(asdf::asdf-version)
"3.1.0.114"
(lisp-implementation-version)
"1.1.8"
------------------------------------------------------
And I did not get any error. No sign of the class instance update bug reported by Faré a little while ago. So since I cannot reproduce it I am a bit at a loss here. Faré, do you have a sure way of triggering that one?
On Sun, Apr 20, 2014 at 7:20 AM, Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com wrote:
This email is just to inform you that I performed the following in a MKCL 1.1.8 a few minutes ago: [successful upgrade]
git checkout syntax-control make u l=mkcl
Some of the tests pass, but one of them fails, and gives you instructions to reproduce.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The ancients stole all our ideas from us. — Mark Twain
Faré wrote:
On Sun, Apr 20, 2014 at 7:20 AM, Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com wrote:
This email is just to inform you that I performed the following in a MKCL 1.1.8 a few minutes ago: [successful upgrade]
git checkout syntax-control make u l=mkcl
Some of the tests pass, but one of them fails, and gives you instructions to reproduce.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org The ancients stole all our ideas from us. — Mark Twain
I just tried this on linux and, on the master branch, all 53 tests pass for me.
As far as I'm concerned, this is good enough for us to be ready to release.
Remaining tasks involve finishing the package-system renaming, and getting docs finished and merged.
I'd like to also check with Dave Cooper and make sure that all the tests are passing on Windows.
This is great news. I think we are on target to release by the end of the month!
Cheers, r
-
Faré -
Jean-Claude Beaudoin -
Robert P. Goldman