patch for allegro8 (was: Re: [asdf-devel] Ready to release?)
Dave Cooper
david.cooper at genworks.com
Fri Oct 18 21:01:05 UTC 2013
On Fri, Oct 18, 2013 at 4:02 PM, Faré <fahree at gmail.com> wrote:
>
>
> > I am reliably replicating test-encoding.script failures now with alisp8
> and
> > mlisp8 on Windows and Linux. I will send that output separately.
> >
>
Here is a patch (with respect to d20ea551c018c46439874f6911e4522289c1196a
which you just pushed) which should take care of the test-encodings.script
failures. The issue in my case was that I was running tests for alisp
followed by alisp8. The asdf/build/fasls/alisp/asdf.fasl was being created
originally by alisp, then loaded unmodified by alisp8. Because the pushnew
of the :asdf-unicode onto *features* was being hard-coded into that fasl by
alisp at compile time, this feature was coming into the system when
asdf.fasl was being loaded into alisp8. So alisp8 ended up incorrectly
thinking that it had :asdf-unicode, which caused test-encodings.script to
become confused.
Same deal with mlisp/mlisp8.
Of course when I ran a fresh test only with alisp8, this problem was not
presenting.
One might argue that the fasls for alisp and alisp8 (similarly mlisp and
mlisp8) should be separated. And in full ASDF of course this is done
already with the implementation-identifier --- so one would never have
noticed the issue in day-to-day operational use of ASDF.
But separating the fasls between mlisp/mlisp8 and alisp/alisp8 should not
be necessary; in Allegro you are supposed to be able to compile a fasl with
alisp (mlisp) and load it with alisp8 (mlisp8), and vice-versa. It's
specifically designed to be able to do this. So even though ASDF normally
separates its fasls in production use, I still think code should be written
so as not to violate the expected ability to compile interchangeably like
this (note that it's also supported to compile a fasl with mlisp and load
it with alisp (but not the other way around) --- but that's a different
issue entirely).
> I am also still getting intermittent test-stamp-propagation failures, but
> > these seem to be more rare since I am starting with clean asdf directory
> for
> > each set of test runs. But the next time I do get one I will provide the
> > output.
> >
> Excellent. I'm looking forward to fixing those intermittent failures.
>
>
This has not popped up again. All 15 tests in the attached "run" script
now run to completion with no failures. So I'm going to leave it be for
right now...
My Best,
Dave Cooper, Genworks Support
david.cooper at genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20131018/5621c271/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check-for-unicode-at-fasl-load-time.patch
Type: application/octet-stream
Size: 1340 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20131018/5621c271/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: run
Type: application/octet-stream
Size: 1955 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20131018/5621c271/attachment-0001.obj>
More information about the asdf-devel
mailing list