[asdf-devel] Patches for ASDF2 for translation function

Faré fahree at gmail.com
Mon Apr 5 18:59:31 UTC 2010


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 at 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 at panix.com>
> To: ASDF-devel <asdf-devel at common-lisp.net>
> CC: Armed Bear <armedbear-devel at 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."




More information about the asdf-devel mailing list