Dear James,
i have reformulated the test cases and run them through several implementations.[0]
Thanks a lot!
- 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]
Oh my, the asdf:around fiasco again. ABCL apparently uses an old version of ASDF to avoid a lot DEFINE-METHOD-COMBINATION.
Couldn't we instead just have a do-perform function do the wrapping stuff and call perform gf, and skip that method-combination complication?
Is there a good reason to use this method-combination protocol? Does anyone rely on either defining asdf:around methods or on calling perform directly and having it do the restart magic?
- 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 should be (make-pathname :name nil :type nil :version nil :defaults *load-pathname*) These are not currently portably valid: * module "./"
For completeness, these should be added: * system nil (default from *load-truename*) * module "module2/submodule1/" * module "module2/submodule1" (same as above, without ending /) * for completeness, "module2/submodule4.foo/" and "module2/submodule4.foo" * 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" * similarly for absolute path as a string.
- neither the syntax nor the semantics of the "lisp",
nil, :directory use cases is clear.
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 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.
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)
Yes, currently, that's the case. That's how we allow the user to have fine-control over the file type when he so desires. If you want control you can have it - use pathnames and you're on your own. If you want automation, use a string and let ASDF parse it the way that makes obvious sense. But you're right, it's one more thing that needs to be documented. Sigh.
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?
Yes, it is always necessarily absolute, and therefore we can trust its host and device to matter. Unless the user is playing games of some sort.
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.
Probably no need to support c in the tests, as it's implicit from b. Just make sure some absolute paths are included in the test for b.
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.
Well, you can put anything in your #p"..." but because the behavior of parse-namestring is largely left unspecified, well-behaved portable system definitions should not rely on it.
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.
Good. Thanks a lot for that.
Namestrings without #p"..." are out.
ok. meaning physical pathname namestrings and logical pathname namestrings?
Yes. Strings are interpreted by ASDF::MERGE-COMPONENT-NAME-TYPE, not by CL:PARSE-NAMESTRING.
Pathnames made with (make-pathname ...) are in.
there were lots of those. are there any variations which should be added?
I think you've covered all the bases, but I'll have to take a third look.
/-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?
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.
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.
See the spec in previous message. I'll have to document that.
Thanks a *LOT* for your help with clarifying the semantics of pathname specifications for ASDF.
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] Always remember that you are unique. Just like everyone else.