[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