patch for allegro8 (was: Re: [asdf-devel] Ready to release?)

[Faré]

1- these tests really aren't geared to be run concurrently by two (or
more) implementations at once. Some tests, such as the stamp
propagation test or the other that failed, do various side-effects to
the filesystem, to check how asdf responds to them. Therefore, until
this is fixed, it does not necessarily make sense to try to
distinguish multiple systems that share the same results directory at
once, etc.

2- Yes, there is a bootstrap problem with putting things in
implementation dependent directories before the UIOP support for that
has been loaded. That's why I don't try, and there are parts of the
system that use cruder techniques.

3- Resolving all these issues is not impossible, but doing it right,
especially without massive inefficiency or unmaintainability, is more
work than I'm willing to put at present.

Therefore, I don't feel your patch as is is ready for inclusion — much
more work needed.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If it's not worth doing right, it's not worth doing. — Scott McKay


On Fri, Oct 18, 2013 at 1:41 AM, Dave Cooper <david.cooper at genworks.com> wrote:
>
> On Fri, Oct 18, 2013 at 12:16 AM, Faré <fahree at gmail.com> wrote:
>>
>> If/when you get an intermittent failure, can you grab the error output?
>> Is it "just" a case of polluted fasl cache between alisp and alisp8?
>
>
>
> I didn't succeed in getting any more yet.
>
> But I did get a stamp-propagation-test failure on SBCL/Linux (attached).
>
> There is also a test-multiple failure in there, but that's because I am
> running Linux in a mounted VM guest filesystem which doesn't allow symbolic
> linking (it comes back with "Read-only Filesystem" when you try to make a
> symbolic link in an OS terminal shell). I wonder if this test can query the
> OS somehow to see if the current filesystem allows symbolic links, and don't
> try to make them if not.
>
> Also attached is a patch which makes the output *.text files in
> build/results/ be os-specific, to allow for running the tests in the same
> asdf/ directory mounted across multiple machines.
>
> There are other outputs (e.g. fasl cache directories) which I feel also
> ought to be named in an os-specific manner, to support running the tests
> from a common directory across all machines. But the bootstrapping issues
> involved with that are a bit beyond obvious to me at first glance ---
> presumably some of these names would have to be determined in
> script-support.lisp, before asdf is loaded with its "detect-os" etc.
> goodness. So I guess a subset of that functionality would have to be copied
> into script-support.lisp.
>
>
> --
> My Best,
>
> Dave Cooper, Genworks Support
> david.cooper at genworks.com, dave.genworks.com(skype)
>