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 Evensonevenson@panix.com 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.
[1]: http://trac.common-lisp.net/armedbear/changeset/12655