On Fri, Oct 18, 2013 at 5:01 PM, Dave Cooper david.cooper@genworks.com wrote:
On Fri, Oct 18, 2013 at 4:02 PM, Faré fahree@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.
OK, I pushed something along the same idea, except also patching uiop/stream.lisp to match the behavior.
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.
I'm curious about what happens to string with non-latin1 characters in them: do they cause the loading to abort, or are they interned as string with different lengths depending on the unicode support? (Similarly for latin1 strings that are malformed as utf-8.)
I am also still getting intermittent test-stamp-propagation failures,
This has not popped up again.
I'll ascribe that to interferences between multiple implementations formerly sharing the same directory simultaneously, then (assuming they used to).
—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org If mice were the ultimate input device, humans would be born with one arm and three fingers.