[armedbear-devel] pathname-directory

[Alan Ruttenberg]

The problem surfaced with what seems to me to be a regression in the
use of the abcl-binary-locations system, which  puts compiled files in
separate directories according to implementation. I'm working on
packaging up my application in a single jar. I move the systems inside
the jar and then try to load using asdf. Because of the use of
:relative, the call to OUTPUT-FILES-USING-MAPPINGS duplicates the
leading directory components, and then the compiled file is not found.

The thing is that with the current setup has it that there is never an
:absolute directory. I think this will violate assumptions of programs
beyond abcl-binary-locations. I believe the assumption will be that
truename will give you something that has an :absolute pathname.

-Alan

CL-USER(37): (asdf::oos 'asdf::load-op (asdf::find-system "jss"))
  0: (ASDF::OUTPUT-FILES-USING-MAPPINGS
#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.lisp"
(#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.abcl") NIL)
    1: (ASDF:IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME)
    1: IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME returned
"armedbear-0.19.0-dev-darwin-unknown"
  0: OUTPUT-FILES-USING-MAPPINGS returned
(#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/lsw/jss/armedbear-0.19.0-dev-darwin-unknown/invoke.abcl")
  0: (ASDF::OUTPUT-FILES-USING-MAPPINGS
#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.lisp"
(#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.abcl") NIL)
    1: (ASDF:IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME)
    1: IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME returned
"armedbear-0.19.0-dev-darwin-unknown"
  0: OUTPUT-FILES-USING-MAPPINGS returned
(#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/lsw/jss/armedbear-0.19.0-dev-darwin-unknown/invoke.abcl")
  0: (ASDF::OUTPUT-FILES-USING-MAPPINGS
#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.lisp"
(#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/invoke.abcl") NIL)
    1: (ASDF:IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME)
    1: IMPLEMENTATION-SPECIFIC-DIRECTORY-NAME returned
"armedbear-0.19.0-dev-darwin-unknown"
  0: OUTPUT-FILES-USING-MAPPINGS returned
(#P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/lsw/jss/armedbear-0.19.0-dev-darwin-unknown/invoke.abcl")
  0: (LOAD #P"jar:file:/Users/alanr/Desktop/lsw.jar!/lsw/jss/lsw/jss/armedbear-0.19.0-dev-darwin-unknown/invoke.abcl")
Debugger invoked on condition of type FILE-ERROR:
  File not found.


On 3/11/10, Mark Evenson <evenson at panix.com> wrote:
>
> On Mar 11, 2010, at 9:37 AM, Alessio Stalla wrote:
>
> […]
>
>>> If you look at the contents of a jar file via
>>> java.util.ZipFile.entries(),
>>> all the hierarchal entries do not have an initial slash, so are
>>> best expressed as relative pathnames.
>>
>> True, they don't have an initial slash, but they're all relative to
>> the root of the jar i.e. they are absolute, to my understanding. If
>> they were relative, they could be interpreted differently depending to
>> some reference directory.
>
> Since we control the behavior of Pathname completely as a Java
> primitive, we can change the underlying implementation to properly
> treat the :ABSOLUTE component of the DIRECTORY list by special-casing
> the searching/iteration of jar file contents.  This change would
> preclude the distinction between a JAR that has entries with an
> initial '/' and  those without, but we could pave over those
> differences via some amount of if/thens sprinkled throughout the
> code.
>
> But before digging everything up again and testing it, I'd
> like to understand what we want to accomplish here.
>
> Since MERGE-PATHNAMES currently has special semantics with jar
> pathnames already, we wouldn't really gain any useful behavior that
> I can immediately think of.
>
> Would you propose that the namestring of a jar pathname remain
> "jar:URL!/foo/bar.lisp" or would it now become "jar:URL!//foo/bar.lisp"
> (which would break the behavior documented in java.net.JarURLConnection)?
>
> So, if y'all really want to change the :RELATIVE to :ABSOLUTE here,
> please convince me, as I currently a net negative in this approach.
>
> I've updated [the Pathname implementation notes][1] to explain the
> current behavior better.
>
>
> [1]:
> http://code.google.com/p/abcl-dynamic-install/source/detail?r=dcf06e25c05c80c1a17b9c417e3c1799715984a0
> --
>
> "A screaming comes across the sky.  It has happened before, but
> there is nothing to compare to it now."
>
>
>
>
>