On 3/30/10 Mar 30 -12:32 PM, james anderson wrote:
On 2010-03-30, at 19:12 , Robert Goldman wrote:
On 3/30/10 Mar 30 -11:52 AM, james anderson wrote:
On 2010-03-30, at 16:25 , Robert Goldman wrote:
On 3/30/10 Mar 30 -5:00 AM, Juan Jose Garcia-Ripoll wrote:
[...]
Question: are we going to create a logical pathname translation for just the system sources? Or should we create also something like
CL-PPCRE;FASLS;*.*.*
if asdf decides to befried logical pathnames, it should allow the system to define its own mapping.
in addition? This seems a little tricky, since it requires that we hook into the output name rewriting logic, but probably is The Right Thing.
i had understood that the name rewriting logic is disabled for logical pathnames. which is as it should be.
Clarification: the name-rewriting logic would still be disabled for logical pathnames. What I was suggesting was that
<SYSTEM-NAME>:FASL;
should be a logical pathname that would point to the location where <SYSTEM-NAME>'s (direct) fasls would be written by Faré's name rewriting.
I.e., this would be a way for the system to find its own fasls reliably, no matter what the output name rewriting does.
Is that more clear?
yes and no. if one wants to map binary files differently that source files, the present (last i looked) asdf behavior was adequate. the last i looked, my binaries were at the specified locations. my experience[1] is that it works better if the pattern matches on the file type. given the proper mapping one neither needs nor wants any asdf internal mapping.
I believe what Juanjo wants here is an ability to have the LOADING of the ASDF file generate some logical pathnames. So that after I asdf-load my system FOO, then code /inside/ foo could use a logical pathname like
"FOO:SRC;DATAFILES;DATA1.DAT"
with the guarantee that ASDF has set up the logical pathname translations for "FOO:SRC;"
best, r