[asdf-devel] [bugfix] Fix ABCL loading ASDF definitions from jars under Windows

[Mark Evenson]

On 5/1/10 9:26 PM, Faré wrote:
> Dear Mark,
>
> thanks a lot for your patch. Your efforts are appreciated.
>

Not as much as I appreciate your unflagging energy (and time) towards 
shipping ASDF2.  You will be missed after you ship this puppy!

> On 1 May 2010 14:04, Mark Evenson<evenson-VmQCmMdMyN0AvxtiuMwx3w at public.gmane.org>  wrote:
>> Attached please find a patch which fixes problems pointed out by Carlos
>> Ungil when ABCL would catastrophically fail to translate the output location
>> for ASDF systems located within jar files under Windows.
>
> Now, your patch looks slightly fishy to me.
> You notably produce a string rather than a pathname;
> on the one hand, that is poor taste, on the other hand,
> it's not clear what device that string will resolve to;
> does ABCL ensure that it will be read as a device-less pathname,
> as opposed to say a pathname relative to the "current device",
> which may change, in which case you lose?

You are correct:  under Windows, my returning a string as opposed to a 
pathname was a recipe for failure, as any merge to the defaults would 
include the "current device".

> Also, instead of using concatenate 'string everywhere,
> you might want to use merge-pathnames* and relativize-pathname-directory;
> or not - after all, you know what is or isn't guaranteed
> to work on your implementation.

Your use of these functions is both more elegant and concise.  As far as 
my testing and analysis goes, both functions seem to work just fine 
under ABCL.

> Also, is it on purpose that these translations are in FRONT
> of the wrapping-output-translations? That means they will be impossible
> to override, as opposed to what would happen if they were on the BACK
> of same list (i.e. *after* :inherit-configuration),
> or relegated to the optional default-output-translations.

Again, you are correct as I apparently still don't fully understand the 
output location interface.

>> We've fixed this in the version of ASDF 1.679 which we are planning to ship
>> as part of abcl-0.20.0 in the next week.  After ASDF goes through the
>> shakedown of your code-freeze over the next two weeks, we'll pick up the end
>> result to ship as part abcl-0.21.0, if this seems reasonable to the ASDF
>> developers.
>>
> It's easier for us to support the latest ASDF than an already old one,
> especially if you're going to ship a patched old one. But yours might
> be the conservative way to go 1.679, and the call is yours, of course.

Given the much better implementation you coded for 
TRANSLATE-JAR-PATHNAME, [I've just included ASDF 1.719 wholesale in the 
upcoming abcl-0.20 release][1], so ABCL is now in sync with ASDF2. 
Hopefully we won't get burned by something in the recoded TRAVERSE 
stuff, but since no one has complained yet, I presume it is stable enough