[Ecls-list] asdf/bundle and ECL prologue / epilogue
fahree at gmail.com
Thu Mar 20 21:16:04 UTC 2014
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 at 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
> 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 220.127.116.11.
> —♯ƒ • 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.
More information about the ecl-devel