[asdf-devel] never ending component relative pathnames

[james anderson]

On 2010-03-15, at 01:36 , Faré wrote:

> Dear James,
>
> is there a tarball I can download with enough stuff to replace those
> tests or yours?

?
the tests are all in the one asdf-pathname-test.lisp file.

> I don't understand which cases exactly fail on which implementations.

the respective output.txt file lists the failures.[0]

the head of the file has three lists:
- the pathnames which i understand to be the complete set given the  
enumerated variations.
- the logical host mapping
- the system/module/file pathname variations

>

if the system definition failed, the definition is cited with the  
error message.

if the pathname reference failed, the entry looks like

  CL-SOURCE-FILE         "file"
   missing:              #P"/ebs/test/asdf-src/system1/module1/ 
untyped-file.lisp"
   configuration:        (#P"ASDFTEST:system1;"  
#P"ASDFTEST:system2;module4;" #P"/ebs/test/asdf-src/system1/module1/ 
untyped-file")
   parent pathnames:     (#P"ASDFTEST:system1;"  
#P"ASDFTEST:system2;module4;")

this displays

  <the component type>  <the component name>
  missing:              <the actual component pathname> which is a  
(physical . logical) pair if that applies
  configuration:        (<system pathname arg> <module pathname arg>  
<file pathname arg>)
  parent pathnames:     (<actual system pathname> <actual module  
pathname>)

the last line in each file reports the counts

>
> Also, why do you map :unspecific to nil in merge-pathnames* ? What
> issues does that solve? Isn't that against what we want?

i changed it to pass no argument when no value is intended.
on this topic clhs/make-pathname -> 19.2.1 lets you down.
you need to attend to 19.3.2.1 [1], to which it appears lispworks  
pays attention.[2]


> Shouldn't we
> rather have split-name-type return type :unspecific more often? Maybe
> your function should compare namestrings instead of pathnames?

the test does not explicitly "compare". it create the files, then  
uses the component pathnames to try to write to them (or just probe  
for directories), and then confirms that it found all the intended  
files by checking their modification times. at least, that is what it  
is supposed to do.

---
  [0] : http://ec2-174-129-136-72.compute-1.amazonaws.com/test/ 
20100314T224221/
  [1] : http://www.lispworks.com/documentation/HyperSpec/Body/19_cba.htm
  [2] : http://ec2-174-129-136-72.compute-1.amazonaws.com/test/ 
20100309T173540/lw/output.txt