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

[Faré]

Dear James,

> i have reformulated the test cases and run them through several
> implementations.[0]
>
Thanks a lot!

> 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]
>
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?

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

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