Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-10 Thread james anderson
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-10 Thread Robert Goldman
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-10 Thread Faré
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-10 Thread Faré
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-10 Thread james anderson
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.

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-10 Thread james anderson
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-10 Thread Faré
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-09 Thread james anderson
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-09 Thread james anderson
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] :

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-09 Thread Robert Goldman
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-09 Thread Robert Goldman
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-09 Thread Faré
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-09 Thread Robert Goldman
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-08 Thread james anderson
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-08 Thread Faré
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-08 Thread james anderson
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

Re: [asdf-devel] never ending component relative pathnames [2]

2010-03-08 Thread Faré
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