Dear Mark,
I merged your patch in, after rearranging it a little bit. Tell me how it's working for you...
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Procrastination is great. It gives me a lot more time to do things that I'm never going to do.
On 5 April 2010 14:09, Mark Evenson evenson@panix.com wrote:
[With the attached patches, the following email get rejected by both the asdf-devel and armedbear-devel mailing lists. If the mail doesn't get through in the next day, I'll stash the patches at a URL and resend.]
-------- Original Message -------- Subject: Patches for ASDF2 for translation function Date: Mon, 05 Apr 2010 14:52:00 +0200 From: Mark Evenson evenson@panix.com To: ASDF-devel asdf-devel@common-lisp.net CC: Armed Bear armedbear-devel@common-lisp.net
On 3/29/10 11:33 AM, Mark Evenson wrote: […]
I'd favor either a keyword argument or :function as a magic marker to be inserted in FIRST position, followed by a function designator (and additionally, parameters to curry?). Unless of course, you symmetrically accept a FUNCTION in first position to denote a "recognize if this matching rule applies".
I would think that we want to preserve the current ability for the user to vistually scan down the list of translations to determine what should match, so I would favor going for your second proposal. It doesn't make sense that there be a match predicate paired with a translation pathname right? So the two new possibilities for output translation lists would be:
("/**/foo/*.*" (:function FOO-OUTPUT-TRANSLATION)) ((:function BAR-PATHNAME-P) (:function BAR-OUTPUT-TRANSLATION))
Attached is a patch against ASDF that allows a user specified function to take the place of TRANSLATE-PATHNAME as the ASDF2 output translation function.
Additionally it adds an ABCL specific extension to ASDF2 that uses this ability by providing the following translations by default
(#p"jar:file:/**/*.jar!/**/*.*" (:function translate-jar-pathname)) (#p"/:jar:file/**/*.*" (:user-cache #p"**/*.*")))
that will map all ASDF loads from jar pathnames to an output location under the per user cache location. This will allow the loading of ASDF systems packaged in jar files which first compiles and then loads FASLs to the local filesystem.
To run this with ABCL you will need to build a custom build of ABCL with the attached patch which is currently necessary to OPEN a jar pathname. This patch is part of a large set of modifications that allow ABCL to open a pathname specified as a url, that I am developing and testing as a unit. These modiictions will be placed in ABCL trunk soon, but first I need to add create more unit tests for the introduced functionality and implement a few more suggestions (like URI encoding functions).
I did not implement Faré's suggestion of including a syntax for a predicate function as the first argument for a output translation pair, because I couldn't come up with a use case in which the current default function PATHNAME-MATCH-P would not work. If someone can come up with such a case, or this deficiency prevents ASDF from accepting this patch, I can have a go at it again.
-- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On 4/5/10 8:59 PM, Faré wrote:
Dear Mark,
I merged your patch in, after rearranging it a little bit. Tell me how it's working for you...
Seems to work just fine in my tests. Thanks for including this!