Re: [Asdf-devel] native-namestring in asdf/cache:normalize-namestring?

Orivej Desh wrote:

Currently, between CFFI-GROVEL and ASDF, neither normalizes pathnames with a dot in :NAME and NIL in :TYPE.

 (cffi-grovel:grovel-file "grovel.cffi")

in a system definition may cause an error under SBCL in ASDF/CACHE:NORMALIZE-NAMESTRING when it calls NAMESTRING on the value of CFFI-GROVEL::EXE-FILENAME:

Calling

 (cffi-grovel::exe-filename #p"grovel.cffi.lisp")

returns

 #<pathname (with no namestring)
            :HOST #<sb-impl::unix-host {10002ACE43}>
            :DEVICE nil
            :DIRECTORY (:relative ".")
            :NAME "grovel.cffi"
            :TYPE nil
            :VERSION :newest>

to ASDF/ACTION:COMPUTE-ACTION-STAMP which can't deal with it when called with :JUST-DONE NIL.

Backtrace: http://report.quicklisp.org/cl-libssh2/2014-09-26/failtail.txt

One solution is to make CFFI-GROVEL::EXE-FILENAME normalize resulting pathname: https://github.com/cffi/cffi/pull/52

Another is to make ASDF/CACHE:NORMALIZE-NAMESTRING call NATIVE-NAMESTRING instead of NAMESTRING.

Who should be responsible for normalizing such a pathname, ASDF of CFFI-GROVEL?

Two things:

1. REPLICATION:

Would you please let me know how to replicate this error?

Looks like you are triggering this through use of some code that's internal to ... CFFI? QUICKLISP?

I was hoping that (ql:quickload "libssh2") would get this for me, but not in my current client.

2. Is this simply an SBCL bug? I.e., there's nothing to stop me from making an executable called foo.bar where "bar" is not a file type. I mean, my file system doesn't have a real notion of filetype, except for mime type, does it? So why is this an error:

CL-USER> (make-pathname :name "foo.bar" :type nil) #<PATHNAME (with no namestring) :HOST #<SB-IMPL::UNIX-HOST {10002BE793}> :DEVICE NIL :DIRECTORY NIL :NAME "foo.bar" :TYPE NIL :VERSION NIL>

CL-USER> (namestring (make-pathname :name "foo.bar" :type nil)) ; Evaluation aborted on #<SIMPLE-ERROR "too many dots in the name: ~S" {100638D463}>.

Without taking a ton of time to grovel the ANSI spec, my guess is that all this stuff is implementation-specific, and so we can't say that this is a bug.

But SBCL seems internally not-so-consistent, because I can use one of these "erroneous" pathnames to find a file:

CL-USER> (make-pathname :directory '(:absolute "tmp") :name "foo.blort" :type nil) #<PATHNAME (with no namestring) :HOST #<SB-IMPL::UNIX-HOST {10002BE793}> :DEVICE NIL :DIRECTORY (:ABSOLUTE "tmp") :NAME "foo.blort" :TYPE NIL :VERSION NIL> CL-USER> (probe-file (make-pathname :directory '(:absolute "tmp") :name "foo.blort" :type nil)) #P"/private/tmp/foo.blort"

at which time it gets put into an acceptable form.... CL-USER> (namestring (probe-file (make-pathname :directory '(:absolute "tmp") :name "foo.blort" :type nil))) "/private/tmp/foo.blort"

thanks, r