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

[Faré]

On 9 June 2011 09:35, Mark Evenson <evenson at panix.com> wrote:
> Stellian's [normalization to ANSI semantics of COMPILE-FILE-PATHNAME*][1]
> has the unfortunate effect of breaking ABCL's translation of systems
> packaged in jar files.
>
Oops. This wasn't caught by my tests. My sincere apologies.
Can you write a simple test to be added to test/asdf-pathnames.script,
and/or send me an example such that I can reproduce the bug at home?
Maybe just a trace output of the relevant functions:
(trace translate-pathname* and compile-file-pathname* apply-output-translations)
(add any function there necessary to show where it breaks).

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.
Note that if requires you could keep a cache of the pathname
in addition (or underlying store?) to any namestring in the device.

> I have applied the subsequent patch to the asdf-2.016 packaged with ABCL to
> restore our needed functionality but am  unhappy at the necessity of
> introducing a runtime implementation conditional, as sure a sign as anything
> that I'm "doing it wrong,"  and can't really request that ASDF patch itself
> in this manner.  Maybe if I explain things as I have analyzed them, someone
> else can suggest a better way forward.
>
Yes, something is wrong.

> Recall that ABCL uses the presence of a cons in the DEVICE component to
> indicate that a Pathname represents an entry in a jar archive.  A pathname
> located within a jar archive is not a writable location, so we introduced
> ABCL specific ASDF output translation rules which translate such a source
> location to an appropriately differentiated output location in the ASDF
> cache hierarchy.  This results in ASDF making the following kind of call in
> preparation of the output file location it will pass to COMPILE-FILE:
>
>  (compile-file-pathname* <path with a DEVICE> :output-file <path without a
> DEVICE>)
>
What output-file do you get and where is it from?
Is any path there not absolute, and if so why?

> If there were some mechanism to indicate that the invocation of
> APPLY-OUTPUT-TRANSLATIONS had really "finished" so that no further
> processing was necessary, we could possibly plausibly short-circuit this
> call to COMPILE-FILE-PATHAME*.
Well, output-files accepts a secondary value of T
to specify that no more translations are needed.
I don't understand yet what to change into ASDF, but
either we can somehow reuse that mechanism, or
we can provide something similar inside apply-output-translations,
or somehow be more clever in translate-jar-pathname.

> I suppose my recursive invocation of
> APPLY-OUTPUT-TRANSLATIONS in the ABCL-specific TRANSLATE-JAR-PATHNAME adds
> the missing TYPE to the pathname which other code paths don't have at this
> point, which is why the call to COMPILE-FILE-PATHNAME* is necessary.
>
My head hurts. What type is added to what where?
Can you give examples of functions giving the "wrong" results?

> ANSI allows the addition of implementation specific arguments to
> COMPILE-FILE-PATHNAME, so we could maybe add a :strip-device for ABCL but
> this seems even less elegant.
>
Probably.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
First they ignore you. Then they laugh at you.
Then they fight you. Then you win.
	— Gandhi