Is anyone at all using asdf-bundle with ECL?
It looks like the prologue and epilogue support were casualties of some operation canonicalization. Also, the way the flags are or aren't propagated to sub-operations is misdesigned. Finally, it seems like prologue and epilogue ought to be part of the system, not of the operation — and they are possibly superseded by ASDF3's image support.
If anyone is using these features, please contact me ASAP. Otherwise, I'm going to commit into asdf/bundle whatever I believe makes sense.
(Bug found through thorough testing of cl-launch.)
And of course, please fix that bug that breaks building a program in recent ECL: https://sourceforge.net/p/ecls/bugs/285/
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Politicians are like diapers: they must be changed often. And for the same reasons. [Also, adults don't need either of them. — Faré]
On Sat, Mar 1, 2014 at 1:39 PM, Faré fahree@gmail.com wrote:
Is anyone at all using asdf-bundle with ECL?
Well, I did hack that bundle thing, in the end.
If any ECL user uses the bundle functionality, please contact the asdf-devel mailing-list. * prologue and epilogue functionality was restored from asdf3, but a new mechanism is in place going forward to attach them to the system rather than the operation, which is flaky. Or is that functionality superseded by the portable initialization hooks of ASDF3 ? * in general, passing flags through operations is flaky — does anyone rely on that? if you do, more love is required, and probably further refactoring to do it differently. If you don't, the feature should be deleted. * the class hierarchy has changed. * binary-op has been renamed to deliver-asd-op, same for monolithic- * an new image-op was created.
After this and some more debugging and testing both asdf and cl-launch, a flurry of corner cases have been fixed in the portability layer. While I was at it, I implemented argv0, which should help buildapp's dispatched-entry become more portable (except to abcl).
As of 3.1.0.83 (!), all tests pass on Linux x64 on: ccl clisp sbcl cmucl allegro allegromodern lispworks ecl_bytecodes scl ecl abcl xcl
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org No man would listen to you talk if he didn't know it was his turn next. — Edgar Watson Howe
Regarding ASDF and ECL, it seemed to me that *load-system-operation* had been designed so I could/should do this in asdf/bundle: (unless (use-ecl-byte-compiler-p) (setf *load-system-operation* 'load-fasl-op))
Unhappily, when I did, I got 4 errors while testing. I found 1 bug in ASDF, 2 bugs in test scripts that didn't expect load-fasl-op (good for ECL to find them! all of them fixed), and what looks like one bug in ECL.
If you uncomment the lines mentioned above in bundle.lisp, modify this test so it uses load-fasl-op instead of load-op, have it (trace c::builder load* perform-plan perform) if you want, and run it: make t l=ecl t='test-xach-update-bug.script'
The .fasb is loaded, but fails to define the second-version package. If you load it into another fresh image, it works.
Therefore, after adding two lines, I commented them out again.
Or is it per design that if you load a fasb, then another incompatible version of a same-named, same location, fasb in the very same image, the results are undefined? But it looks like it's working for a regular fas, since the test works using load-op.
In any case, if some ECL maintainer has spare cycles, this deserves to be investigated eventually.
I'm running ECL 13.5.1 (git:e7daee08e8cb7d4b4cea4bc27ce9c7839e236938) on Linux amd64. It's the last version that doesn't bug out with program-op because of the bug
If you tell me I should use load-fasl-op anyway, I will.
PS: Anton, if you have time, can you re-run tests after uncommenting the mentioned lines in bundle.lisp? I'm interested in whether there are regressions using ECL this way... it did error out on missing dependencies in a few of ASDF's tests (including in asdf-encodings). Otherwise, I think we have a release candidate with 3.1.0.92.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There are two kinds of pacifists: those who try to disarm the criminals, and those who try to disarm the victims.
Speaking of asdf-bundle and ECL...
In ASDF 3.1, I renamed the misnomer binary-op to deliver-asd-op; is there any user in the ECL world who cares about that old name from asdf-ecl? I could add a backward-compatible shim.
While I'm at renaming misnomers, I'd like to rename fasl-op to compile-bundle-op and load-fasl-op to load-bundle-op. I expect these classes to be used, though, and do intend to have backward-compatible classes available — even though nothing shows in either the ECL sources or Quicklisp.
[I need to confirm these renamings with the current ASDF maintainer, though].
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Yield to temptation; it may never pass your way again. — Robert Heinlein, "Time Enough For Love"
On Thu, Mar 6, 2014 at 12:14 AM, Faré fahree@gmail.com wrote:
Regarding ASDF and ECL, it seemed to me that *load-system-operation* had been designed so I could/should do this in asdf/bundle: (unless (use-ecl-byte-compiler-p) (setf *load-system-operation* 'load-fasl-op))
Unhappily, when I did, I got 4 errors while testing. I found 1 bug in ASDF, 2 bugs in test scripts that didn't expect load-fasl-op (good for ECL to find them! all of them fixed), and what looks like one bug in ECL.
If you uncomment the lines mentioned above in bundle.lisp, modify this test so it uses load-fasl-op instead of load-op, have it (trace c::builder load* perform-plan perform) if you want, and run it: make t l=ecl t='test-xach-update-bug.script'
The .fasb is loaded, but fails to define the second-version package. If you load it into another fresh image, it works.
Therefore, after adding two lines, I commented them out again.
Or is it per design that if you load a fasb, then another incompatible version of a same-named, same location, fasb in the very same image, the results are undefined? But it looks like it's working for a regular fas, since the test works using load-op.
In any case, if some ECL maintainer has spare cycles, this deserves to be investigated eventually.
I'm running ECL 13.5.1 (git:e7daee08e8cb7d4b4cea4bc27ce9c7839e236938) on Linux amd64. It's the last version that doesn't bug out with program-op because of the bug
If you tell me I should use load-fasl-op anyway, I will.
PS: Anton, if you have time, can you re-run tests after uncommenting the mentioned lines in bundle.lisp? I'm interested in whether there are regressions using ECL this way... it did error out on missing dependencies in a few of ASDF's tests (including in asdf-encodings). Otherwise, I think we have a release candidate with 3.1.0.92.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org There are two kinds of pacifists: those who try to disarm the criminals, and those who try to disarm the victims.
Do you plan to change the name of monolithic-fasl-op ?
On Thu, Mar 20, 2014 at 5:16 PM, Faré fahree@gmail.com wrote:
Speaking of asdf-bundle and ECL...
In ASDF 3.1, I renamed the misnomer binary-op to deliver-asd-op; is there any user in the ECL world who cares about that old name from asdf-ecl? I could add a backward-compatible shim.
While I'm at renaming misnomers, I'd like to rename fasl-op to compile-bundle-op and load-fasl-op to load-bundle-op. I expect these classes to be used, though, and do intend to have backward-compatible classes available — even though nothing shows in either the ECL sources or Quicklisp.
[I need to confirm these renamings with the current ASDF maintainer, though].
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Yield to temptation; it may never pass your way again. — Robert Heinlein, "Time Enough For Love"
On Thu, Mar 6, 2014 at 12:14 AM, Faré fahree@gmail.com wrote:
Regarding ASDF and ECL, it seemed to me that *load-system-operation* had been designed so I could/should do this in asdf/bundle: (unless (use-ecl-byte-compiler-p) (setf *load-system-operation* 'load-fasl-op))
Unhappily, when I did, I got 4 errors while testing. I found 1 bug in ASDF, 2 bugs in test scripts that didn't expect load-fasl-op (good for ECL to find them! all of them fixed), and what looks like one bug in ECL.
If you uncomment the lines mentioned above in bundle.lisp, modify this test so it uses load-fasl-op instead of load-op, have it (trace c::builder load* perform-plan perform) if you want, and
run it:
make t l=ecl t='test-xach-update-bug.script'
The .fasb is loaded, but fails to define the second-version package. If you load it into another fresh image, it works.
Therefore, after adding two lines, I commented them out again.
Or is it per design that if you load a fasb, then another incompatible version of a same-named, same location, fasb in the very same image, the results are undefined? But it looks like it's working for a regular fas, since the test works using load-op.
In any case, if some ECL maintainer has spare cycles, this deserves to be investigated eventually.
I'm running ECL 13.5.1 (git:e7daee08e8cb7d4b4cea4bc27ce9c7839e236938) on Linux amd64. It's the last version that doesn't bug out with program-op because of the bug
If you tell me I should use load-fasl-op anyway, I will.
PS: Anton, if you have time, can you re-run tests after uncommenting the mentioned lines in bundle.lisp? I'm interested in whether there are regressions using ECL this way... it did error out on missing dependencies in a few of ASDF's tests (including in asdf-encodings). Otherwise, I think we have a release candidate with 3.1.0.92.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics•
There are two kinds of pacifists: those who try to disarm the criminals,
and
those who try to disarm the victims.
On Thu, Mar 20, 2014 at 5:34 PM, Dave Cooper david.cooper@genworks.com wrote:
Do you plan to change the name of monolithic-fasl-op ?
Yes, it would become monolithic-compile-bundle-op. I presume this question means means you're using it, so I'd leave an alias behind.
I also plan to not rename anything without a green light from the maintainer, even though my fingers are itching.
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org Consider algebra in XML: instead of (sin (+ x y)), sin(x+y) or x y + sin, you just use <apply><sin/><apply><plus/><ci>x</ci><ci>y</ci></apply></apply>.
On Mar 21, 2014 11:20 AM, "Faré" fahree@gmail.com wrote:
On Thu, Mar 20, 2014 at 5:34 PM, Dave Cooper david.cooper@genworks.com
wrote:
Do you plan to change the name of monolithic-fasl-op ?
Yes, it would become monolithic-compile-bundle-op. I presume this question means means you're using it, so I'd leave an alias behind.
Did you mean compile-monolithic-bundle-op instead? Unless I misunderstood the intent, it's verb first, since this is lisp :-)
Yong
-
Dave Cooper -
Faré -
Theam Yong Chew