[asdf-devel] Pushed :here-directive topic branch
rpgoldman at sift.info
Mon Nov 29 02:55:00 UTC 2010
On 11/24/10 Nov 24 -9:59 AM, Faré wrote:
> On 24 November 2010 09:46, Robert Goldman <rpgoldman at sift.info> wrote:
>>> 1- you should probably be using (default-directory) instead of
>> I will modify the code accordingly.
> Scratch that. You should be using *default-pathname-defaults*,
> but to save work, bind it to (default-directory) around
> the call to inherit-source-registry in flatten-source-registry.
Done. Look for push to come, after I've checked to make sure these
changes don't break the tests.
BTW, if there's a condition you think I ought to add to the tests,
please let me know. I covered a reasonable set of cases, but there are
certainly more. I'm not sure which are "interesting" --- i.e. likely to
>>> 3- you can wrap the whole body of process-source-registry (pathname
>>> &key ...) in a
>>> (let ((*proper-variable* (pathname-directory-pathname pathname))) ...)
>> I wasn't confident of what would happen in the third branch of the COND
>> --- the one with
>> (inherit-source-registry inherit :register register)
>> if I did that. If you're sure I won't mess something up that way, I'll
>> make the change. I'm looking at the test suite, and I'm pretty sure I
>> could bork ASDF by messing up I-S-R without the test suite noticing.
> You're totally right, my suggestion was wrong on point 2,
> because of your point 3 below. We probably want to
> a- distinguish "here" (relative to config file) from "default"
> (something global set by the user).
> b- reset "here" to "default" when processing something that's not a file,
> around the body of inherit-source-registry.
That's what I was trying to do by taking :here to mean
*default-pathname-defaults* when *here-directory* is unbound. That was
the only expedient I could think of that would make :here do something
sensible when it was used interactively....
More information about the asdf-devel