On 2010-03-10, at 00:49 , Faré wrote:
Dear James,
[ ... ]
2. the description of the interaction between a :pathname
specification and a default file type was not clear.
i added various combinations to the tests.
please advise as to which ones are intended to be supported.
root
On 3/10/10 Mar 10 -3:40 AM, james anderson wrote:
On 2010-03-10, at 00:49 , Faré wrote:
Dear James,
These are not currently portably valid:
* module ./
= remove these entries.
elsewhere it is described that . should work.
Question of clarification: is elsewhere somewhere in the
3- for aesthetic reasons, I find that it's nicer if I don't have to
mysteriously do bar/baz but bar/baz-V1.200.lisp. I feel that the
rule .lisp is always added to the filename is simpler and easier for
newcomers to understand than the rule .lisp is added to the filename
iff there isn't a dot
These are not currently portably valid:
* module ./
= remove these entries.
elsewhere it is described that . should work.
? add entries for . to the module and system lists?
As rpg says, I don't know where that somewhere is,
and I suspect it's bogus. If you want non-portable stuff,
you can
good afternoon;
On 2010-03-10, at 14:47 , Robert Goldman wrote:
On 3/10/10 Mar 10 -3:40 AM, james anderson wrote:
On 2010-03-10, at 00:49 , Faré wrote:
Dear James,
These are not currently portably valid:
* module ./
= remove these entries.
elsewhere it is described that . should work.
On 2010-03-10, at 15:00 , Faré wrote:
These are not currently portably valid:
* module ./
= remove these entries.
elsewhere it is described that . should work.
? add entries for . to the module and system lists?
As rpg says, I don't know where that somewhere is,
and I suspect it's
On 10 March 2010 09:41, james anderson james.ander...@setf.de wrote:
These are not currently portably valid:
* module ./
ok. ? i don't put them in. or, i put them in and (as i need to
anyway) add machinery to verify error cases?
Don't put them in, since we don't currently catch such
good evening;
i have reformulated the test cases and run them through several
implementations.[0]
1. i had thought (eg. [1]) that abcl and asdf were compatible. is
there some special version involved? the cl.net release failed to
load.[2]
2. the description of the interaction between a
On 2010-03-09, at 19:00 , james anderson wrote:
good evening;
i have reformulated the test cases and run them through several
implementations.[0]
i have pushed these tot eh asdf-x repository[1] in case anyone wants
to suggest changes.
---
[1] :
On 3/9/10 Mar 9 -5:49 PM, Faré wrote:
Yes, it hasn't been documented so far. My bad. At least it now has a
well-defined meaning, as opposed to the previous mess.
a- when the source-file-type of a component is NIL, then the file type
is read from the last /-separated component of the string as
On 3/9/10 Mar 9 -5:49 PM, Faré wrote:
Dear James,
i have reformulated the test cases and run them through several
implementations.[0]
Thanks a lot!
1. i had thought (eg. [1]) that abcl and asdf were compatible. is
there some special version involved? the cl.net release failed to
b- when the source-file-type of a component is a string, then it will
be the type, and the last /-separated component of the string provides
the name.
This case worries me. It seems to require that every system definer
have a strongish sense of the internals of ASDF, and will give odd
On 3/9/10 Mar 9 -9:46 PM, Faré wrote:
b- when the source-file-type of a component is a string, then it will
be the type, and the last /-separated component of the string provides
the name.
This case worries me. It seems to require that every system definer
have a strongish sense of the
good afternoon;
[the first version of this message tripped on the size threshold for
attachments. this copy is with links]
On 2010-03-05, at 21:35 , Robert Goldman wrote:
On 3/5/10 Mar 5 -2:18 PM, james anderson wrote:
i would be as well.
that's why i sent it to you at the other end of a
Dear James,
On 8 March 2010 11:08, james anderson james.ander...@setf.de wrote:
please find referenced below, a suggestion as to the use cases which
the component pathname computation should support.[1]
specifying :pathname arguments to ASDF components as strings had NEVER
been working
good evening;
On 2010-03-08, at 17:53 , Faré wrote:
Dear James,
On 8 March 2010 11:08, james anderson james.ander...@setf.de wrote:
please find referenced below, a suggestion as to the use cases which
the component pathname computation should support.[1]
specifying :pathname arguments to
i understand, that in some environments neither logical pathname
designators nor logical pathnames themselves are seen as portable,
but i continue to try to treat them as if they were. so far, with
success. mostly.
I believe logical pathnames as defined in the CLHS are widely
supported, and
17 matches
Mail list logo