On 9 June 2011 09:35, Mark Evenson evenson@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