[asdf-devel] never ending component relative pathnames

james anderson james.anderson at setf.de
Mon Mar 15 21:24:53 UTC 2010


On 2010-03-15, at 21:07 , Faré wrote:

> On 14 March 2010 21:04, james anderson <james.anderson at setf.de> wrote:
>>
>> 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.
>>
> The amazon host is down. Also, when I last glanced, it looked like you
> needed some subdirectory with test files.
> Can you send on the list a tarball with the .lisp, .sh, and any
> ancillary file or does your script already create the files?

for now, amazon is up when i use it. the files are in github.[0],[1],[2]
as you read, below, the test creates everything it needs.

>
>> 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;")
>>
> Does "missing" means that you tried that pathname in the end, and
> failed?

for a file component, it means that (open ... :if-does-not- 
exist :error) failed.[3]

> i.e. in that case, you were expecting a .lisp type, when
> you're not providing one in an explicit pathname?

the component name and the three configuration pathnames indicate  
what was supplied in the defsystem.
the missing is the actual component pathname form a source file  
component in a system of that configuration.
as it should not have been, no target file had been created for it.
thus, the failure.

> We explicitly won't
> merge any type when a pathname object is specified, so that the user
> can override component-provided types.

i understand, that is your spec. the missing file is the reality with  
allegro.
i believe this error is specific to allegro. it is representative of  
many in the alisp/output.txt file which i sent to you.

>
>>> 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]
>>
> Ouch. I had missed this section. What about I change merge-pathnames*
> to squash :unspecific if and only if the host is a logical host?

once that is in the a released version, i will test it.

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

---
  [0] : http://github.com/lisp/de.setf.asdf.x/blob/master/test/asdf- 
pathname-test.sh
  [1] : http://github.com/lisp/de.setf.asdf.x/blob/master/test/test- 
init.lisp
  [2] : http://github.com/lisp/de.setf.asdf.x/blob/master/test/asdf- 
pathname-test.lisp
  [3] : http://github.com/lisp/de.setf.asdf.x/blob/master/test/asdf- 
pathname-test.lisp#L208
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20100315/3cd1907b/attachment.html>


More information about the asdf-devel mailing list