[asdf-devel] ASDF 2.016 breaks ABCL translations for jar files

[Mark Evenson]

On 6/9/11 6:44 PM, Faré wrote:
>>> Note that when I (describe #p"jar:file:///foo/bar.jar!/baz/quux.lisp")
>>> I get:
>>>         #P"jar:file:/foo/bar.jar!/baz/quux.lisp" is an object of type
>>> EXTENSIONS:JAR-PATHNAME:
>>>    HOST         NIL
>>>    DEVICE       (#P"/foo/bar.jar")
>>>    DIRECTORY    (:ABSOLUTE "baz")
>>>    NAME         "quux"
>>>    TYPE         "lisp"
>>>    VERSION      NIL
>>>
>>> I believe that a pathname instead of a namestring
>>> makes that non-conformant. Sigh.
>>
>> You mean the list with pathname in the device field?  Yes, ABCL is
>> non-conformant in this manner in order to support addressing entries in jar
>> files.
>>
>>> Note that if requires you could keep a cache of the pathname
>>> in addition (or underlying store?) to any namestring in the device.

On re-reading CLHS, I retract my admission that ABCL is non-conformant. 
  From the CLHS glossary a "valid pathname device [is a]  a string, nil, 
:unspecific, or some other object defined by the implementation to be a 
valid pathname device." ABCL is using the "some other object" ability 
here. The "might" description in CLHS 19.2.2.4.2 offers guidance as to 
the allowed types, but doesn't put a firm requirement.  Or is this 
understanding incorrect somehow?  Note I am trying to use "conformant" 
here in the manner prescribed by CLHS 1.5, not in the informal sense of 
"what a friendly CL implementation" should do.

The two main design reasons for allowing a list of pathnames in our 
device component:  they allow pathnames representing URI locations so 
our jars may be loaded over the network, and they allow us to reference 
jar archives stored within archives which is important for ABCL fasls. 
We could plausibly convert the device pathname to namestrings, as every 
URI has an suitably encoded string representation, but without the 
ability to use a cons in the device slot we would lose the ability to 
refer to a nested entry.

> You could be conformant if the device component were ("/foo/bar.jar")
> instead of (#P"/foo/bar.jar").

But have the device component be a cons violates the first sentence of 
CLHS 19.2.2.4.2 that you are presumably referencing.  Or how do I 
misunderstand?

[…]

> At this point can you trace COMPILE-FILE-PATHNAME, too?
> Since the output-file satisfies absolute-pathname-p,
> the branch taken by COMPILE-FILE-PATHNAME* should be to just call
> COMPILE-FILE-PATHNAME, at which point I expect it to *not*
> merge the device of the source file.
> OH I GET IT! (I think.) The bug is that
> (1) COMPILE-FILE-PATHNAME uses MERGE-PATHNAMES
>    instead of ASDF:MERGE-PATHNAMES* (as you would, I assume).
> (2) Your absolute pathnames have a host and device of NIL,
>    instead of a non-nil host device of say "FILE" and "LOCALHOST"
>    or say "" and "".

Yes, it is our use of NIL here that is causing problems.

What I was going to suggest is that the TRANSLATE-JAR-PATHNAME function 
return a pathname with an :UNSPECIFIC device component.  This should 
allow the COMPILE-FILE-PATHNAME merge algorithm to do what we want, but 
I see you have incorporated this into your next message, which I will 
reply to.

> Sigh. I would have suggested fixing things by having
> ABCL's pathname scheme not use NIL for HOST and DEVICE in such cases,
> but who knows what other interesting (positive or negative) consequences
> that might or might not have. It could be a big win or a big headache.

I think we should probably insert :UNSPECIFIC for more cases than where 
we do from MAKE-PATHNAME.

[…]


-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."