[asdf-devel] [bugfix] Fix ABCL loading ASDF definitions from jars under Windows
evenson at panix.com
Thu May 6 20:21:52 UTC 2010
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
> 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
> 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], 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
More information about the asdf-devel