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

[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 bogus. If you want non-portable stuff,
> you can use #p".".
>
> I suppose I could add support for "." and maybe even ".."
> to the component name parsing function. If there is an
> outcry of demand from ASDF users, I will, but at present
> that seems overkill to me.

ok. ? i don't put them in. or, i put them in and (as i need to  
anyway) add machinery to verify error cases?

>
>>> * source test to be split between :file lisp module and :static-
>>> file data file
>>> * :file "file2.lisp" means #p"file2.lisp.lisp"
>>> * :static-file "file2.lisp" means #p"file2.lisp"
>>> * :file "module1-1/file3.lisp" means #p"module1-1/
>>> file3.lisp.lisp" (assuming /)
>>> * :static-file "module1-1/file3.lisp" means #p"module1-1/file3.lisp"
>>
>> ? == add a :static-file as a sibling to the :file component
>> ? == add combinations for variations in the component name
>>
> add :static-file as a sibling, and note that various things behave
> differently, since :file always adds .lisp to a specified string
> whereas :static-file never adds anything (and neither ever substract).

i think i finally am not unclear about this.

>
>>> * similarly for absolute path as a string.
>> ? do not understand
> We probably want to check that these work (at least on Unix):
> "/foo/bar/baz.quux"

still do not completely understand. i need a matrix


   \  initialization  
argument             :name                                       
|      :pathname <as string>
                                  <as string> <as string w/ 
separators> <as symbol>   |   <as string> <as pathname>
component class \
   file -> lisp-source-file             ?
   static-file                          ?                         ...
   module
    
system                                                                   
                   ?            ?

i have fabricated a mechanism to verify the results, but - while i am  
no longer completely unclear, i am not certain what the intended  
values are.
especially since the two column regions are not independent and it's  
actually a 3-d table.
plus the interaction because leaf component values are not  
independent of module and system values.

the assertions in component-pathname-test.lisp were (and remain) just  
my best guesses.

if one could fill out a table like this (yes, somehow n-dimensional)  
with a performance specification in each cell for which support is  
intended, i would be very happy.


>
>>> 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 the  
>>> last
>>> dot-separated component (unless there's only one dot and  it's the
>>> first character, in which case the type is NIL and that's the name).
>>> 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.
>>> c- when the source-file-type of a component is :DIRECTORY, then all
>>> /-separated components of the string including the last one are
>>> interpreted as directories.
>>
>> ? but not when it is a file or file specialization?
>>
> When it's a file, the previous to last components are interpreted as
> directories, but the last is interpreted as a file name. When it's
> a directory, all components are interpreted as directories.
>
>
>>>> please describe the syntax for pathname pseudo-namestrings.
>>>> i have added pathname specifications to the tests[3] which mirror
>>>> clhs 19.3.1, but
>>>> a. use '/' instead of ';' as the (relative)-directory-marker;
>>>> b. follow the unix convention for "relative" rather than the  
>>>> logical
>>>> pathname convention;
>>>> c. exclude hosts
>>>>
>>>> is that the intended syntax?
>>>>
>>> Yes. Plus the fact that either a type is provided by the component
>>> class,
>>> or none is and the type is taken from the string.
>>
>> ? still no clear one this. please describe a few examples with the
>> intended effective component pathname.
>>
> (:module "a/b/c.d") => (make-pathname :directory '(:relative "a"  
> "b" "c.d"))
> (:file "a/b/c.d") => (make-pathname :directory '(:relative "a" "b")
> :name "c.d" :type "lisp"))
> (:static-file "a/b/c.d") => (make-pathname :directory '(:relative "a"
> "b") :name "c" :type "d"))
> (:module "/a/b/c.d") => (make-pathname :directory '(:absolute "a"  
> "b" "c.d"))
> (:file "/a/b/c.d") => (make-pathname :directory '(:absolute "a" "b")
> :name "c.d" :type "lisp"))
> (:static-file "/a/b/c.d") => (make-pathname :directory '(:absolute "a"
> "b") :name "c" :type "d"))

these help. could they be organized somehow like imagined above.
especially to show the interaction with a :pathname argument and with  
parent location specifications.