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