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

james anderson james.anderson at setf.de
Tue Mar 9 18:00:21 UTC 2010


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 :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.

3. neither the syntax nor the semantics of the "lisp",  
nil, :directory use cases is clear.

On 2010-03-09, at 01:35 , Faré wrote:

>> [ ... ]
>
> Now supported (1.630):
> 1- the name is a string or symbol (the name of which will be
> downcased). It will be interpreted by merge-component-name-type as a
> /-separated path, using the type specified by the component class if
> any.
> 2- the :pathname specification overrides the name. It is interpreted
> similarly if a symbol or a string. It can also be a pathname, in which
> case it is not further interpreted.

if "overrides" and "not further interpreted" are intended to mean,  
that the :pathname specification must include any eventual file type,  
then the documentation should be _very_ clear about that. from my  
first look at the test results, it seems that this restriction  
applies, but i am still uncertain. (see [2] above)


> 3- the parent's pathname from is an absolute pathname, with proper
> host and device.

this is not clear. is not a parent pathname - as a component- 
pathname, v/s a component-relative-pathname, always necessarily  
absolute?

> 4- the pathname obtained from 1 or 2 is merged with the one from 3 as
> with merge-pathnames*, i.e. if it's relative, then the parent's host
> and device are used.
>
> Actually, now that we are using merge-pathnames* instead of
> merge-pathnames, I find that the default argument to
> merge-component-name-type becomes useless. Unless anyone objects, I
> will remove it in ASDF 1.631 (and rename the function).
>
> Regarding 2, note that the only portable ways to obtain a pathname are
> a- #p"LOGICAL-HOST:logical;path;name"
> b- #.(make-pathname ...)
> c- More #. magic with merge-pathnames, *load-pathname*,
> *load-truename*, (user-homedir-pathname), etc.

a and b were the only ways which were present in the tests.
are there any 'c' forms which should be added.

please endeavour to make clear in asdf documentation, that a and b  
are the only ways which asdf supports. as #p"..." is defined as  
equivalent to (parse-namestring "...") any limitation is that of asdf  
support, not of general portability.

>
> In particular, non-logical namestrings are NOT portable, MUST NOT be
> used in a portable .asd file, and are otherwise not supported.

there were never any in the test. all namestrings were logical  
pathname designators. which are intended to be portable.

>
> [ ... ]
>
>>> It would be nice if from your file was extracted a test for the
>> if someone would enumerate the cases which are supported. i will try
>> again.
>> as i understand your demurral, relative to the tested enumeration[2],
>> one should eliminate the cases which involve string designators for
>> logical pathnames.
>> should anything else be removed?
>> are that any additional cases for which support should be tested?
>>
> Non-logical pathnames are out.

there were never any in the test.

> Namestrings without #p"..." are out.

ok. meaning physical pathname namestrings and logical pathname  
namestrings?

> Pathnames made with (make-pathname ...) are in.

there were lots of those. are there any variations which should be  
added?

> /-separated pseudo-namestrings relative paths are in.

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?

> Tests should include cases where the source-file-type is "lisp", NIL
> or :directory.

i don't understand how these are intended to be used. please give me  
some examples.

i can leave the server up for the next couple of hours.

---
  [0] : http://ec2-184-73-77-22.compute-1.amazonaws.com/test/
  [1] : http://abcl-dev.blogspot.com/2010/02/require-now-works-with- 
asdf-systems.html
  [2] : http://ec2-184-73-77-22.compute-1.amazonaws.com/test/output.txt
  [3] : http://ec2-184-73-77-22.compute-1.amazonaws.com/test/asdf- 
pathname-test.lisp



More information about the asdf-devel mailing list