[asdf-devel] ASDF 2.016 breaks ABCL translations for jar files
fahree at gmail.com
Thu Jun 9 14:37:04 UTC 2011
On 9 June 2011 09:35, Mark Evenson <evenson at panix.com> wrote:
> Stellian's [normalization to ANSI semantics of COMPILE-FILE-PATHNAME*]
> 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")
#P"jar:file:/foo/bar.jar!/baz/quux.lisp" is an object of type
DIRECTORY (:ABSOLUTE "baz")
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
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.
—♯ƒ • 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.
More information about the asdf-devel