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@genworks.com wrote:
On Fri, Oct 18, 2013 at 12:16 AM, Faré fahree@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@genworks.com, dave.genworks.com(skype)