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.
[…]