In asdf-pathname-test.script, in function test-file, L126, changing: :rename-and-delete to: #+(and sbcl os-windows) :rename-and-delete #-(and sbcl os-windows) :supsersede seems to resolve the issue. This :supersede was changed to :rename-and-delete last night in order to make SBCL/Windows work. Originally this was :supersede. I don't know if this is a real solution or if we should look for a deeper fix which allows leaving it unconditionally as :rename-and-delete. On Tue, Oct 15, 2013 at 5:58 PM, Dave Cooper <david.cooper@genworks.com>wrote:

I can replicate this on Linux as well, with both mlisp and alisp.

On Tue, Oct 15, 2013 at 5:18 PM, Robert P. Goldman <rpgoldman@sift.info>wrote:

...

I pulled an update this afternoon, and now on ACL 9.0 on Mac OS X I get a failure on asdf-pathname-test.script

I get an error as follows:

Above backtrace due to this condition: attempt to take the length of a non-sequence: :UNSPECIFIC

I get an enormous backtrace, but this is I think the direct call that gets an error:

(LET

((STREAM (OPEN . #16=((ASDF/COMPONENT:COMPONENT-PATHNAME ASDF-PATHNAME-TEST::FILE) :DIRECTION :OUTPUT :IF-EXISTS :RENAME-AND-DELETE :IF-DOES-NOT-EXIST :ERROR))) (#12=#:WITH-OPEN-FILE-ABORT-398 . #61=(T))) (UNWIND-PROTECT (MULTIPLE-VALUE-PROG1 (PROGN . #17=((PRINT ASDF-PATHNAME-TEST::START-TIME STREAM) T)) (SETQ #12# . #58=(NIL))) (WHEN (STREAMP STREAM) (CLOSE STREAM :ABORT #12#))))

More as I find out more.

Best, r

-- My Best,

Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

-- My Best, Dave Cooper, Genworks Support david.cooper@genworks.com, dave.genworks.com(skype) USA: 248-327-3253(o), 1-248-330-2979(mobile) UK: 0191 645 1699

Faré wrote:

I committed more or less the change Dave suggested.

You are in a maze of subtly incompatible implementation buglets, all different.

All that because the standard tried to compromise between incompatible implementations, instead of (1) mandating some standardized 1-1 access to the underlying OS, and (2) standardizing on constructions on top of that or parametric abstractions from that. So instead of having well-defined tools (that may not be a complete solution indeed), we have horribly undefined tools (that still may not be a complete solution, and now actually cannot be).

And so, instead of having two standard APIs, one for Windows and one for Unix, on top of which to build robust things, we have thirty-odd different APIs, all of them incompatible, none of them reasonably standard.

That's an old problem of having a standard that is never-changing. When the standard was made Windows was hardly a thing -- certainly not for serious computing -- and they were concerned with portability to things like Lisp machines that hardly even had an OS.... No, the problem is that the standard has never evolved beyond the ANSI.... :-( Seems like each of the implementations has some good ideas, but none has all of the good ones. I'll pull again and re-test. It should make you feel better that your hard work on the regression tests has let us spot these bugs almost instantly. Best, r