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."
_______________________________________________
asdf-devel mailing list
[email protected]
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/asdf-devel
