Apart from some documentation and copyright notices, two major changes:
- ECL will support two compilers. ASDF needs to be aware of that.
- The plug-in for REQUIRE allows ECL users to supply another default operator. LOAD-FASL-OP is recommended because it builds each library into a single shared library, saving resources.
Juanjo
On Mon, Aug 1, 2011 at 16:20, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
Apart from some documentation and copyright notices, two major changes:
- ECL will support two compilers. ASDF needs to be aware of that.
- The plug-in for REQUIRE allows ECL users to supply another default
operator. LOAD-FASL-OP is recommended because it builds each library into a single shared library, saving resources. Juanjo
With over a month of delay, I merged Juan Jo's patch, but find that I am unable to test it thoroughly for the next few days. Can someone apply it, test it, and commit upstream if it passes all tests?
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
On 9/4/11 Sep 4 -11:25 PM, Faré wrote:
On Mon, Aug 1, 2011 at 16:20, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
Apart from some documentation and copyright notices, two major changes:
- ECL will support two compilers. ASDF needs to be aware of that.
- The plug-in for REQUIRE allows ECL users to supply another default
operator. LOAD-FASL-OP is recommended because it builds each library into a single shared library, saving resources. Juanjo
With over a month of delay, I merged Juan Jo's patch, but find that I am unable to test it thoroughly for the next few days. Can someone apply it, test it, and commit upstream if it passes all tests?
I looked at this, and it looks fine to me (although there's an oddity in the copyright line, which seems to remove copyright from one of the authors).
I don't have any way to evaluate this, since I don't run ECL.
I'd be happy to merge and push this if someone will test this out. Alternatively, if no member of asdf-devel but Juanjo will admit to using ECL, then I figure we should delegate responsibility to him for vetting patches to asdf-ecl.
best, r
On Tue, Sep 6, 2011 at 4:51 PM, Robert Goldman rpgoldman@sift.info wrote:
I'd be happy to merge and push this if someone will test this out. Alternatively, if no member of asdf-devel but Juanjo will admit to using ECL, then I figure we should delegate responsibility to him for vetting patches to asdf-ecl.
I try to ensure that the extensions do not interfere with the core and could take care of further testing if you give me a hint how to do so.
Juanjo
On 9/7/11 Sep 7 -11:33 AM, Juan Jose Garcia-Ripoll wrote:
On Tue, Sep 6, 2011 at 4:51 PM, Robert Goldman <rpgoldman@sift.info mailto:rpgoldman@sift.info> wrote:
I'd be happy to merge and push this if someone will test this out. Alternatively, if no member of asdf-devel but Juanjo will admit to using ECL, then I figure we should delegate responsibility to him for vetting patches to asdf-ecl.I try to ensure that the extensions do not interfere with the core and could take care of further testing if you give me a hint how to do so.
I am afraid that Faré overestimated the time I had available for ASDF! Sorry to have taken so long to get back to you.
I was looking over Faré's version of the patch. AFAICT, most of the patch would only affect your private codebase (asdf-ecl.lisp). The exceptions are:
1. Mods to OUTPUT-FILES and *COMPILE-OP-COMPILE-FILE-FUNCTION* for compile-op that are conditionalized on (member :ecl-bytecmp *features*)
I think it is safe (shouldn't interfere with any other implementations use of ASDF), but this use of *FEATURES* at *run-time* instead of the conventional use at compile-time makes me feel a little uncomfortable. It feels to me like an abuse of a facility.
I presume that this is necessary (instead of #+ecl-bytecmp) because you could have the SAME compiled version of asdf.lisp used in byte compiling and standard compiling contexts? Is there some reason you use a feature for this purpose instead of a dynamically bound variable (e.g., *ecl-bytecomp-p*) or a special ECL-BYTE-COMPILE-OP?
2. Export of *require-asdf-operator*. This seems entirely reasonable to me --- it's intended as a hook, so it seems like external access is The Right Thing.
LMK a bit more about #1, and then we should be able to get this merged and pushed.
I don't know of any special testing requirements. It would be good to get as many tests run on as many implementations as possible (both our internal tests and the informal tests that come from, e.g., Xach using the latest ASDF). I will run a bunch of tests on linux and Mac for several implementations.
Might be nice to set up some sort of web-checklist so that we can know when the tests are run, and on what lisps.
cheers, r
On Fri, Sep 9, 2011 at 9:37 PM, Robert Goldman rpgoldman@sift.info wrote:
I think it is safe (shouldn't interfere with any other implementations use of ASDF), but this use of *FEATURES* at *run-time* instead of the conventional use at compile-time makes me feel a little uncomfortable. It feels to me like an abuse of a facility.
Right now this is how my two compilers expose their presence to their users. I do not see how this could be an abuse and why further variables are needed. Besides, this is ECL's design, not ASDF's.
Juanjo
On 9/9/11 Sep 9 -2:50 PM, Juan Jose Garcia-Ripoll wrote:
On Fri, Sep 9, 2011 at 9:37 PM, Robert Goldman <rpgoldman@sift.info mailto:rpgoldman@sift.info> wrote:
I think it is safe (shouldn't interfere with any other implementations use of ASDF), but this use of *FEATURES* at *run-time* instead of the conventional use at compile-time makes me feel a little uncomfortable. It feels to me like an abuse of a facility.Right now this is how my two compilers expose their presence to their users. I do not see how this could be an abuse and why further variables are needed. Besides, this is ECL's design, not ASDF's.
OK. But why do you need to do
(member :foo *features*)
instead of
#+foo
?
That was the original question.
thanks, r
On Fri, Sep 9, 2011 at 9:55 PM, Robert Goldman rpgoldman@sift.info wrote:
OK. But why do you need to do (member :foo *features*) instead of #+foo ? That was the original question.
Simple: because the user may switch compilers at run time at any time he/she wishes. This is quite typical in Windows, where the bytecodes compiler is active by default because many people do not have a C compiler in their PC.
Using #+ hardcodes the behavior in ASDF. This would be short-sighted: the same ASDF library can handle multiple compilers without needing to re-load it again.
Juanjo
On 9/9/11 Sep 9 -4:11 PM, Juan Jose Garcia-Ripoll wrote:
On Fri, Sep 9, 2011 at 9:55 PM, Robert Goldman <rpgoldman@sift.info mailto:rpgoldman@sift.info> wrote:
OK. But why do you need to do (member :foo *features*) instead of #+foo ? That was the original question.Simple: because the user may switch compilers at run time at any time he/she wishes. This is quite typical in Windows, where the bytecodes compiler is active by default because many people do not have a C compiler in their PC.
Using #+ hardcodes the behavior in ASDF. This would be short-sighted: the same ASDF library can handle multiple compilers without needing to re-load it again.
That is what I had suspected.
Question: any objection to modifying your patch so that we have something like:
#+ecl (defun use-ecl-byte-compiler-p () (member :ecl-bytecomp *features*)) #-ecl (defun use-ecl-byte-compiler-p () nil)
and then call the function in place of the member query in other code?
If so, lmk, and we can push this.
cheers, r
On Fri, Sep 9, 2011 at 18:33, Robert Goldman rpgoldman@sift.info wrote:
Question: any objection to modifying your patch so that we have something like:
#+ecl (defun use-ecl-byte-compiler-p () (member :ecl-bytecomp *features*)) #-ecl (defun use-ecl-byte-compiler-p () nil)
and then call the function in place of the member query in other code?
No. Juanjo will confirm, but IIUC it can change at runtime after having loaded ASDF, so it's
#+ecl (defun use-ecl-bytecode-compiler-p () (member :ecl-bytecmp *features*))
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
On Sat, Sep 10, 2011 at 12:41 AM, Faré fahree@gmail.com wrote:
On Fri, Sep 9, 2011 at 18:33, Robert Goldman rpgoldman@sift.info wrote:
Question: any objection to modifying your patch so that we have something like:
#+ecl (defun use-ecl-byte-compiler-p () (member :ecl-bytecomp *features*)) #-ecl (defun use-ecl-byte-compiler-p () nil)
and then call the function in place of the member query in other code?
No. Juanjo will confirm, but IIUC it can change at runtime after having loaded ASDF, so it's
Yes, the change may happen after ASDF is loaded, without problems.
#+ecl (defun use-ecl-bytecode-compiler-p () (member :ecl-bytecmp *features*))
Isn't this the same as the code above?
Juanjo
On Fri, Sep 9, 2011 at 18:53, Juan Jose Garcia-Ripoll juanjose.garciaripoll@googlemail.com wrote:
On Sat, Sep 10, 2011 at 12:41 AM, Faré fahree@gmail.com wrote:
On Fri, Sep 9, 2011 at 18:33, Robert Goldman rpgoldman@sift.info wrote:
Question: any objection to modifying your patch so that we have something like:
#+ecl (defun use-ecl-byte-compiler-p () (member :ecl-bytecomp *features*)) #-ecl (defun use-ecl-byte-compiler-p () nil)
and then call the function in place of the member query in other code?
No. Juanjo will confirm, but IIUC it can change at runtime after having loaded ASDF, so it's
Yes, the change may happen after ASDF is loaded, without problems.
#+ecl (defun use-ecl-bytecode-compiler-p () (member :ecl-bytecmp *features*))
Isn't this the same as the code above?
If by "the code above" you mean your original patch and my merge thereof, then yes it is the same, with just a tiny bit of refactoring. If by "the code above" you mean Robert's version with #+ecl, then no, it's different, since Robert's version resolves the features at read-time; by the time the features are updated, it's then too late for ASDF to change its mind.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Not exactly. The feature I (was trying to) resolve at compile time was just ECL versus other implementation. Byte compiler versus not would be resolved at run time. Cheers
I have incorporated Juanjo's patches, together with my slight modification, and tested them on Mac OS X against:
ACL ACL modern ABCL CCL CLISP SBCL
... and it passes all of these tests.
So I am pushing a new ASDF version (2.017.2).
Juanjo, will you please test this ASAP? Also, will anyone who has a linux box set up with all the latest and greatest lisp releases give it a whirl? I will test on 64-bit ACL there, and a slightly-old SBCL.
Cheers, r
OK, so Robert pushed something as 2.017.3, and I made a few adjustments as 2.017.4.
Juanjo, can you test whether this satisfies you?
Regarding ECL, do fasls have a different extension when using the bytecode compiler than when using the normal compiler? I hope so and suppose so. Otherwise there will be an "interesting" issue of having to reset asdf:implementation-string when switching compiler.
(Also, port install ecl failed on a MacOS 10.6.8 machine. But 2.017.4 passes ASDF tests on ECL on a Linux x64 box.)
Thanks a lot for your support, and sorry for the delay!
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
On Mon, Sep 12, 2011 at 09:02, Robert Goldman rpgoldman@sift.info wrote:
I have incorporated Juanjo's patches, together with my slight modification, and tested them on Mac OS X against:
ACL ACL modern ABCL CCL CLISP SBCL
... and it passes all of these tests.
So I am pushing a new ASDF version (2.017.2).
Juanjo, will you please test this ASAP? Also, will anyone who has a linux box set up with all the latest and greatest lisp releases give it a whirl? I will test on 64-bit ACL there, and a slightly-old SBCL.
Cheers, r
On Tue, Sep 13, 2011 at 12:04 AM, Faré fahree@gmail.com wrote:
Juanjo, can you test whether this satisfies you?
Yes, sorry, I did not answer before: I am away from home and took some time to get the changes. It all seems correct to me.
Regarding ECL, do fasls have a different extension when using the
bytecode compiler than when using the normal compiler? I hope so and suppose so. Otherwise there will be an "interesting" issue of having to reset asdf:implementation-string when switching compiler.
Different compilers produce different file extensions.
Thanks a lot for your support, and sorry for the delay!
Thanks indeed a lot you all for your help.
Juanjo
Is there a way to specifically run the tests on ecl using the byte compiler? If not, should we develop such a capability and add it to our test suite?
cheers, r
On Tue, Sep 13, 2011 at 4:03 PM, Robert Goldman rpgoldman@sift.info wrote:
Is there a way to specifically run the tests on ecl using the byte compiler? If not, should we develop such a capability and add it to our test suite?
I do not think this has been actually considered in the ASDF sources, but activating the bytecodes compiler (if it does not come active by default) is just
(ext::install-bytecodes-compiler)
while loading the ordinary compiler is done through
(require :cmp)
Juanjo
On 9/13/11 Sep 13 -10:59 AM, Juan Jose Garcia-Ripoll wrote:
On Tue, Sep 13, 2011 at 4:03 PM, Robert Goldman <rpgoldman@sift.info mailto:rpgoldman@sift.info> wrote:
Is there a way to specifically run the tests on ecl using the byte compiler? If not, should we develop such a capability and add it to our test suite?I do not think this has been actually considered in the ASDF sources, but activating the bytecodes compiler (if it does not come active by default) is just
(ext::install-bytecodes-compiler)
while loading the ordinary compiler is done through
(require :cmp)
Currently, when we test ECL, we do neither of these (as far as I can tell).
Would we want to make two different versions of the ECL tests, as follows:
ecl-bytecomp : first compile and load asdf, then call INSTALL-BYTECODES-COMPILER, then run the tests.
ecl : first (require :CMP), then compile and load asdf, then run tests.
Question: does this recipe FORCE us to have the right compiler for the tests?
thanks, r
On Fri, Sep 16, 2011 at 11:54 PM, Robert Goldman rpgoldman@sift.infowrote:
Currently, when we test ECL, we do neither of these (as far as I can tell).
Would we want to make two different versions of the ECL tests, as follows:
ecl-bytecomp : first compile and load asdf, then call INSTALL-BYTECODES-COMPILER, then run the tests.
ecl : first (require :CMP), then compile and load asdf, then run tests.
Question: does this recipe FORCE us to have the right compiler for the tests?
I do not fully understand the last question. What is "the right compiler". There are simply two, which may be used interchangably without problems -- otherwise to be reported as an error.
Juanjo
On 9/17/11 Sep 17 -1:47 AM, Juan Jose Garcia-Ripoll wrote:
On Fri, Sep 16, 2011 at 11:54 PM, Robert Goldman <rpgoldman@sift.info mailto:rpgoldman@sift.info> wrote:
Currently, when we test ECL, we do neither of these (as far as I can tell). Would we want to make two different versions of the ECL tests, as follows: ecl-bytecomp : first compile and load asdf, then call INSTALL-BYTECODES-COMPILER, then run the tests. ecl : first (require :CMP), then compile and load asdf, then run tests. Question: does this recipe FORCE us to have the right compiler for the tests?I do not fully understand the last question. What is "the right compiler". There are simply two, which may be used interchangably without problems -- otherwise to be reported as an error.
What I want to do is to be able to set up two versions of the ASDF test cases for ECL, one for ECL with the byte-compiler and one with it's normal compiler.
To do that, I need to be able to force one or the other compiler to be active (and the other /not/ to be active).
Currently the regression tests just start up ECL and I don't believe any attempt is made to ensure one or the other compilers. That means, at least theoretically, ASDF could be working with the normal compiler, and not the byte compiler, or vice versa, and it would be impossible to tell using our regression tests.
Does that clarify?
Cheers, r
On Sun, Sep 18, 2011 at 3:39 AM, Robert Goldman rpgoldman@sift.info wrote:
On 9/17/11 Sep 17 -1:47 AM, Juan Jose Garcia-Ripoll wrote:
On Fri, Sep 16, 2011 at 11:54 PM, Robert Goldman <rpgoldman@sift.info mailto:rpgoldman@sift.info> wrote: ecl-bytecomp : first compile and load asdf, then call INSTALL-BYTECODES-COMPILER, then run the tests.
ecl : first (require :CMP), then compile and load asdf, then runtests.
Question: does this recipe FORCE us to have the right compiler forthe
tests?I do not fully understand the last question. What is "the right compiler". There are simply two, which may be used interchangably without problems -- otherwise to be reported as an error.
What I want to do is to be able to set up two versions of the ASDF test cases for ECL, one for ECL with the byte-compiler and one with it's normal compiler.
Yes, the protocol above would achieve that. The only thing is that the bytecodes compiler is not always present in ECL (someone may choose to deactivate it) and it is only a recent development, not available in the latest stable release -- I should make one soon.
A way to check for it is to see whether INSTALL-BYTECODES-COMPILER is fboundp.
Juanjo
On 9/18/11 Sep 18 -4:00 PM, Juan Jose Garcia-Ripoll wrote:
On Sun, Sep 18, 2011 at 3:39 AM, Robert Goldman <rpgoldman@sift.info mailto:rpgoldman@sift.info> wrote:
On 9/17/11 Sep 17 -1:47 AM, Juan Jose Garcia-Ripoll wrote: > On Fri, Sep 16, 2011 at 11:54 PM, Robert Goldman <rpgoldman@sift.info <mailto:rpgoldman@sift.info> > <mailto:rpgoldman@sift.info <mailto:rpgoldman@sift.info>>> wrote: > ecl-bytecomp : first compile and load asdf, then call > INSTALL-BYTECODES-COMPILER, then run the tests. > > ecl : first (require :CMP), then compile and load asdf, then run tests. > > Question: does this recipe FORCE us to have the right compiler for the > tests? > > I do not fully understand the last question. What is "the right > compiler". There are simply two, which may be used interchangably > without problems -- otherwise to be reported as an error. What I want to do is to be able to set up two versions of the ASDF test cases for ECL, one for ECL with the byte-compiler and one with it's normal compiler.Yes, the protocol above would achieve that. The only thing is that the bytecodes compiler is not always present in ECL (someone may choose to deactivate it) and it is only a recent development, not available in the latest stable release -- I should make one soon.
A way to check for it is to see whether INSTALL-BYTECODES-COMPILER is fboundp.
So may we expect that the bytecodes compiler will NEVER be active out of the box? I.e., all we need to do is turn ON the bytecode compiler when we want it, not make sure it's off when we don't (for the purposes of testing)?
Unfortunately, I am lost in the mire of RUN-SHELL-COMMAND, and it'll be a while before I can get to this (git can have multiple branches --- me, not so much!).
thanks, r
On Tue, Sep 20, 2011 at 3:27 PM, Robert Goldman rpgoldman@sift.info wrote:
So may we expect that the bytecodes compiler will NEVER be active out of the box? I.e., all we need to do is turn ON the bytecode compiler when we want it, not make sure it's off when we don't (for the purposes of testing)?
No, what I meant is that you have to make sure whether the version contains a bytecompiler (it is about 5 or 6 months old), and whether it was built at all (there are ways to suppress components from ECL during configuration)
Unfortunately, I am lost in the mire of RUN-SHELL-COMMAND, and it'll be
a while before I can get to this (git can have multiple branches --- me, not so much!).
No problem. If I find time I will try to add the options for ECL.
Juanjo
On 9/20/11 Sep 20 -9:10 AM, Juan Jose Garcia-Ripoll wrote:
On Tue, Sep 20, 2011 at 3:27 PM, Robert Goldman <rpgoldman@sift.info mailto:rpgoldman@sift.info> wrote:
So may we expect that the bytecodes compiler will NEVER be active out of the box? I.e., all we need to do is turn ON the bytecode compiler when we want it, not make sure it's off when we don't (for the purposes of testing)?No, what I meant is that you have to make sure whether the version contains a bytecompiler (it is about 5 or 6 months old), and whether it was built at all (there are ways to suppress components from ECL during configuration)
Unfortunately, I am lost in the mire of RUN-SHELL-COMMAND, and it'll be a while before I can get to this (git can have multiple branches --- me, not so much!).No problem. If I find time I will try to add the options for ECL.
If you find time, will you please look into tests/run-tests.sh? And also tests/compile-asdf.lisp? That's where the tests start up. I am thinking we might modify the tests so that it accepts both
ecl and ecl-bytecompiler
as lisp implementation names.
thanks, r
On Tue, Sep 20, 2011 at 4:25 PM, Robert Goldman rpgoldman@sift.info wrote:
If you find time, will you please look into tests/run-tests.sh? And also tests/compile-asdf.lisp? That's where the tests start up. I am thinking we might modify the tests so that it accepts both
I attach a patch file. The changes are minimal and now allow using "make lisp=ecl-bytecmp test". One test is failing with the bytecodes compiler. I have to see that with greater care at some other time.
Juanjo
-
Faré -
Juan Jose Garcia-Ripoll -
Robert Goldman -
Robert P. Goldman