From: Stanislaw H. <st...@te...> - 2009-08-28 12:32:53
|
CL:NAMESTRING currently fails for pathnames like this one: (make-pathname :name "foo.bar" :type nil) ASDF makes such pathnames, for instance: (defsystem :alexandria [...] ([...] (:static-file "tests.lisp") [...]) [...]) results in the following pathname: HOST = #<SB-IMPL::UNIX-HOST {1000254C51}> DEVICE = NIL DIRECTORY = (:ABSOLUTE "home" "sthalik" "instalki" "clbuild" "source" "alexandria") NAME = "tests.lisp" TYPE = NIL VERSION = :NEWEST I made a patch, would you be willing to accept it? diff --git a/src/code/unix-pathname.lisp b/src/code/unix-pathname.lisp index 82b39b7..e8eb814 100644 --- a/src/code/unix-pathname.lisp +++ b/src/code/unix-pathname.lisp @@ -166,7 +166,8 @@ (collect ((strings)) (let* ((name (%pathname-name pathname)) (type (%pathname-type pathname)) - (type-supplied (not (or (null type) (eq type :unspecific))))) + (type-supplied (not (or (null type) (eq type :unspecific)))) + (dot-position (position #\. name :start 1))) ;; Note: by ANSI 19.3.1.1.5, we ignore the version slot when ;; translating logical pathnames to a filesystem without ;; versions (like Unix). @@ -174,8 +175,10 @@ (when (and (null type) (typep name 'string) (> (length name) 0) - (position #\. name :start 1)) - (error "too many dots in the name: ~S" pathname)) + dot-position) + (setq type (subseq name (1+ dot-position)) + name (subseq name 0 dot-position) + type-supplied t)) (when (and (typep name 'string) (string= name "")) (error "name is of length 0: ~S" pathname)) |
From: Christophe R. <cs...@ca...> - 2009-08-28 12:49:45
|
Stanislaw Halik <st...@te...> writes: > I made a patch, would you be willing to accept it? Is there not a read-print consistency issue? As I recall (maybe incorrectly), the namestring of a pathname is meant to be canonical in the sense that no other pathname generates that namestring. As such, I think your patch is wrong. As well as print-read consistency, I believe that this patch does not meet the consistency criterion in the CLHS page for ENOUGH-NAMESTRING. Cheers, Christophe |
From: Stanislaw H. <st...@te...> - 2009-08-28 14:06:04
|
thus spoke Christophe Rhodes <cs...@ca...>: >> I made a patch, would you be willing to accept it? > Is there not a read-print consistency issue? As I recall (maybe > incorrectly), the namestring of a pathname is meant to be canonical in > the sense that no other pathname generates that namestring. As such, I > think your patch is wrong. Good point. How about this patch, then? With this approach there can't be any pathnames containing dots but no type, though. CL-USER> (make-pathname :name "foo.bar" :type nil) #P"foo.bar" CL-USER> (describe *) #P"foo.bar" [structure-object] Slots with :INSTANCE allocation: HOST = #<SB-IMPL::UNIX-HOST {1000254C51}> DEVICE = NIL DIRECTORY = NIL NAME = "foo" TYPE = "bar" VERSION = NIL ; No value CL-USER> (asdf:component-pathname (second (slot-value (asdf:find-system 'alexandria) 'asdf::components))) #P"/home/sthalik/instalki/clbuild/source/alexandria/tests.lisp" CL-USER> (describe *) #P"/home/sthalik/instalki/clbuild/source/alexandria/tests.lisp" [structure-object] Slots with :INSTANCE allocation: HOST = #<SB-IMPL::UNIX-HOST {1000254C51}> DEVICE = NIL DIRECTORY = (:ABSOLUTE "home" "sthalik" "instalki" "clbuild" "source" "alexandria") NAME = "tests" TYPE = "lisp" VERSION = :NEWEST ; No value diff --git a/src/code/target-pathname.lisp b/src/code/target-pathname.lisp index 04c5845..f1a358b 100644 --- a/src/code/target-pathname.lisp +++ b/src/code/target-pathname.lisp @@ -586,7 +586,12 @@ a host-structure or string." (ver (cond (versionp version) (defaults (%pathname-version defaults)) - (t nil)))) + (t nil)))) + (when (stringp name) + (let ((dot-position (position #\. name :start 1))) + (when (and dot-position (null type)) + (setq type (subseq name (1+ dot-position)) + name (subseq name 0 dot-position))))) (when (and defaults (not dirp)) (setf dir (merge-directories dir |
From: Christophe R. <cs...@ca...> - 2009-08-28 14:30:08
|
Stanislaw Halik <st...@te...> writes: > thus spoke Christophe Rhodes <cs...@ca...>: > >>> I made a patch, would you be willing to accept it? >> Is there not a read-print consistency issue? As I recall (maybe >> incorrectly), the namestring of a pathname is meant to be canonical in >> the sense that no other pathname generates that namestring. As such, I >> think your patch is wrong. > > Good point. How about this patch, then? > > With this approach there can't be any pathnames containing dots but no > type, though. That's more of a possibility, but why is the right answer not either not to have component names with dots in them in asdf, or else to treat the dot within a component name in asdf as indicating a separator between name and type? Best, Christophe |
From: Faré <fa...@gm...> - 2009-08-28 14:37:45
|
Note that I just submitted a patch to ASDF that amongst other things might hopefully remove the need to support such paths with dots in name and no type. [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] You have the capacity to learn from mistakes. You'll learn a lot today. 2009/8/28 Christophe Rhodes <cs...@ca...>: > Stanislaw Halik <st...@te...> writes: > >> thus spoke Christophe Rhodes <cs...@ca...>: >> >>>> I made a patch, would you be willing to accept it? >>> Is there not a read-print consistency issue? As I recall (maybe >>> incorrectly), the namestring of a pathname is meant to be canonical in >>> the sense that no other pathname generates that namestring. As such, I >>> think your patch is wrong. >> >> Good point. How about this patch, then? >> >> With this approach there can't be any pathnames containing dots but no >> type, though. > > That's more of a possibility, but why is the right answer not either not > to have component names with dots in them in asdf, or else to treat the > dot within a component name in asdf as indicating a separator between > name and type? > > Best, > > Christophe |
From: Stanislaw H. <st...@te...> - 2009-08-28 14:59:38
|
thus spoke Faré <fa...@gm...>: > Note that I just submitted a patch to ASDF that amongst other things > might hopefully remove the need to support such paths with dots in > name and no type. Great! Hopefully this problem will disappear after the change is ported to SBCL's ASDF and there won't be a need for kludges like the one I posted. |
From: Robert G. <rpg...@si...> - 2009-08-28 14:30:12
|
Stanislaw Halik wrote: > CL:NAMESTRING currently fails for pathnames like this one: > (make-pathname :name "foo.bar" :type nil) > > ASDF makes such pathnames, for instance: > > (defsystem :alexandria > [...] > ([...] > (:static-file "tests.lisp") > [...]) > [...]) > > results in the following pathname: > > HOST = #<SB-IMPL::UNIX-HOST {1000254C51}> > DEVICE = NIL > DIRECTORY = (:ABSOLUTE "home" "sthalik" "instalki" "clbuild" "source" > "alexandria") > NAME = "tests.lisp" > TYPE = NIL > VERSION = :NEWEST > > I made a patch, would you be willing to accept it? I haven't looked into how this happens in ASDF, but perhaps it would be more appropriate to fix it there? Have you tried asking asdf-devel? Seems like the above case could be quite simply fixed in alexandria by defining a subclass of static-file (defclass static-lisp-file (static-file) ()) (defmethod source-file-type ((c static-lisp-file) (s module)) "lisp") and then having (:static-lisp-file "tests") Note that this is COMPLETELY untested and pulled out of my right ear; I'm not sure it's the source-file-type that needs overriding, but you get the picture. Best, r |
From: Stanislaw H. <st...@te...> - 2009-08-28 15:05:17
|
thus spoke Robert Goldman <rpg...@si...>: > Note that this is COMPLETELY untested and pulled out of my right ear; > I'm not sure it's the source-file-type that needs overriding, but you > get the picture. The problem lies within ASDF:COMPONENT-PATHNAME and how it interacts with static files. Glad that Fare fixed it. |