[asdf-devel] possible clisp/win32 incompatibility
Hi all, I'm trying to get ABLE running on mswin and hit multiple issues at once... For one, it appears the a recent version of ASDF broke compatibility with clisp on windows. If *enable-asdf-binary-locations* is t, I get "invalid :directory (clisp-2.48...)"; if it is nil, ASDF is trying to load sources from the wrong location. This could be a configuration issue on my side, but it affects both clisp 2.48 and clisp 2.45, and this configuration works fine with ccl 1.3 and 1.4. Both clisp versions work fine with the same configuration using a ~5 month old version of ASDF... I'm focusing on other bugs now. Later, Daniel
On 1/24/10 Jan 24 -2:32 PM, Daniel Herring wrote:
Hi all,
I'm trying to get ABLE running on mswin and hit multiple issues at once...
For one, it appears the a recent version of ASDF broke compatibility with clisp on windows. If *enable-asdf-binary-locations* is t, I get "invalid :directory (clisp-2.48...)"; if it is nil, ASDF is trying to load sources from the wrong location.
This could be a configuration issue on my side, but it affects both clisp 2.48 and clisp 2.45, and this configuration works fine with ccl 1.3 and 1.4. Both clisp versions work fine with the same configuration using a ~5 month old version of ASDF...
Will you please explain the problem further? Is it simply because asdf-binary-locations wants to make directory names (with periods) that cause windows to choke? If so, I suggest you patch implementation-specific-directory-name by wrapping something around its output format statement that will substitute either #\- or #\_ for #\. If that's not it, I don't know what's wrong... Got a backtrace for us? cheers, r
On Sun, 24 Jan 2010, Robert Goldman wrote:
On 1/24/10 Jan 24 -2:32 PM, Daniel Herring wrote:
Hi all,
I'm trying to get ABLE running on mswin and hit multiple issues at once...
For one, it appears the a recent version of ASDF broke compatibility with clisp on windows. If *enable-asdf-binary-locations* is t, I get "invalid :directory (clisp-2.48...)"; if it is nil, ASDF is trying to load sources from the wrong location.
This could be a configuration issue on my side, but it affects both clisp 2.48 and clisp 2.45, and this configuration works fine with ccl 1.3 and 1.4. Both clisp versions work fine with the same configuration using a ~5 month old version of ASDF...
Will you please explain the problem further? Is it simply because asdf-binary-locations wants to make directory names (with periods) that cause windows to choke?
If so, I suggest you patch implementation-specific-directory-name by wrapping something around its output format statement that will substitute either #\- or #\_ for #\.
Thanks for the ideas. Poking around a bit further, it appears that in the following snippet from output-files-using-mappings (*centralize-lisp-binaries* is false), (pathname-directory path) is nil. (make-pathname :type (pathname-type path) :directory (append (pathname-directory path) (implementation-specific-directory-name)) :defaults path))))) Thus clisp is seeing ":directory (clisp)" without a leading :relative or :absolute. I don't know the cause and am focused on other issues right now (this one has a couple workarounds: use ccl or an older asdf). Thanks, Daniel
On 1/24/10 Jan 24 -3:01 PM, Daniel Herring wrote:
On Sun, 24 Jan 2010, Robert Goldman wrote:
On 1/24/10 Jan 24 -2:32 PM, Daniel Herring wrote:
Hi all,
I'm trying to get ABLE running on mswin and hit multiple issues at once...
For one, it appears the a recent version of ASDF broke compatibility with clisp on windows. If *enable-asdf-binary-locations* is t, I get "invalid :directory (clisp-2.48...)"; if it is nil, ASDF is trying to load sources from the wrong location.
This could be a configuration issue on my side, but it affects both clisp 2.48 and clisp 2.45, and this configuration works fine with ccl 1.3 and 1.4. Both clisp versions work fine with the same configuration using a ~5 month old version of ASDF...
Will you please explain the problem further? Is it simply because asdf-binary-locations wants to make directory names (with periods) that cause windows to choke?
If so, I suggest you patch implementation-specific-directory-name by wrapping something around its output format statement that will substitute either #\- or #\_ for #\.
Thanks for the ideas. Poking around a bit further, it appears that in the following snippet from output-files-using-mappings (*centralize-lisp-binaries* is false), (pathname-directory path) is nil.
(make-pathname :type (pathname-type path) :directory (append (pathname-directory path) (implementation-specific-directory-name)) :defaults path)))))
Thus clisp is seeing ":directory (clisp)" without a leading :relative or :absolute. I don't know the cause and am focused on other issues right now (this one has a couple workarounds: use ccl or an older asdf).
Can you trace pathname-type inside the invocation of output-files-using-mappings? This smells like a CLISP bug to me.... best, R
On 1/24/10 Jan 24 -3:05 PM, Robert Goldman wrote:
On 1/24/10 Jan 24 -3:01 PM, Daniel Herring wrote:
On Sun, 24 Jan 2010, Robert Goldman wrote:
Can you trace pathname-type inside the invocation of output-files-using-mappings? This smells like a CLISP bug to me....
d'oh --- I meant pathname-directory...
Robert Goldman wrote:
On 1/24/10 Jan 24 -3:01 PM, Daniel Herring wrote:
Thanks for the ideas. Poking around a bit further, it appears that in the following snippet from output-files-using-mappings (*centralize-lisp-binaries* is false), (pathname-directory path) is nil.
(make-pathname :type (pathname-type path) :directory (append (pathname-directory path) (implementation-specific-directory-name)) :defaults path)))))
Thus clisp is seeing ":directory (clisp)" without a leading :relative or :absolute. I don't know the cause and am focused on other issues right now (this one has a couple workarounds: use ccl or an older asdf).
Can you trace pathname-type inside the invocation of output-files-using-mappings? This smells like a CLISP bug to me....
Here's some relevant FORMAT ~S output. "p:" is the full path right before the error; p-d is the pathname-directory. ;; Loaded file #<INPUT BUFFERED FILE-STREAM CHARACTER C:\Documents and Settings\nuntius\Desktop\able-release\systems\ltk\ltk.asd @19> p: #P"C:ltk.fas" p-d: NIL *** - MAKE-PATHNAME: Illegal :DIRECTORY argument ("clisp-2.48-win32-i386") Something bad happened before this call; the paths list is screwed up in the output-files defmethod around compile-op (a few lines below the above snippet). It is merely (#P"C:ltk.fas").
From a few TRACEs, it appears that *default-pathname-defaults* is #P"C:", and this is the value of component-parent-pathname. Component-relative-pathname is "ltk.lisp".
- Daniel
On 1/24/10 Jan 24 -9:39 PM, dherring@tentpost.com wrote:
Robert Goldman wrote:
On 1/24/10 Jan 24 -3:01 PM, Daniel Herring wrote:
Thanks for the ideas. Poking around a bit further, it appears that in the following snippet from output-files-using-mappings (*centralize-lisp-binaries* is false), (pathname-directory path) is nil.
(make-pathname :type (pathname-type path) :directory (append (pathname-directory path) (implementation-specific-directory-name)) :defaults path)))))
Thus clisp is seeing ":directory (clisp)" without a leading :relative or :absolute. I don't know the cause and am focused on other issues right now (this one has a couple workarounds: use ccl or an older asdf).
Can you trace pathname-type inside the invocation of output-files-using-mappings? This smells like a CLISP bug to me....
Here's some relevant FORMAT ~S output. "p:" is the full path right before the error; p-d is the pathname-directory.
;; Loaded file #<INPUT BUFFERED FILE-STREAM CHARACTER C:\Documents and Settings\nuntius\Desktop\able-release\systems\ltk\ltk.asd @19> p: #P"C:ltk.fas" p-d: NIL *** - MAKE-PATHNAME: Illegal :DIRECTORY argument ("clisp-2.48-win32-i386")
Something bad happened before this call; the paths list is screwed up in the output-files defmethod around compile-op (a few lines below the above snippet). It is merely (#P"C:ltk.fas").
From a few TRACEs, it appears that *default-pathname-defaults* is #P"C:", and this is the value of component-parent-pathname. Component-relative-pathname is "ltk.lisp".
Hm. That looks like the *default-pathname-defaults* has only a :device (or possibly a :host) but no :directory component. I really don't have the foggiest idea how that could have happened. I'm afraid I am neither a windows nor a clisp user, so someone else will have to step in here. Looks like that :directory argument is simply the output of (implementation-specific-directory-name) and that agrees that pathname-directory of path NIL. No idea why this is happening, but I suspect it's a problem with the system pathname somehow. Best of luck, r
On 2010/01/25, at 05:07 , Robert Goldman wrote:
On 1/24/10 Jan 24 -9:39 PM, dherring@tentpost.com wrote:
Robert Goldman wrote:
On 1/24/10 Jan 24 -3:01 PM, Daniel Herring wrote:
Thanks for the ideas. Poking around a bit further, it appears that in the following snippet from output-files-using-mappings (*centralize-lisp-binaries* is false), (pathname-directory path) is nil.
(make-pathname :type (pathname-type path) :directory (append (pathname-directory path) (implementation-specific-directory- name)) :defaults path)))))
Thus clisp is seeing ":directory (clisp)" without a leading :relative or :absolute. I don't know the cause and am focused on other issues right now (this one has a couple workarounds: use ccl or an older asdf).
Can you trace pathname-type inside the invocation of output-files-using-mappings? This smells like a CLISP bug to me....
Here's some relevant FORMAT ~S output. "p:" is the full path right before the error; p-d is the pathname-directory.
;; Loaded file #<INPUT BUFFERED FILE-STREAM CHARACTER C:\Documents and Settings\nuntius\Desktop\able-release\systems\ltk\ltk.asd @19> p: #P"C:ltk.fas" p-d: NIL *** - MAKE-PATHNAME: Illegal :DIRECTORY argument ("clisp-2.48-win32- i386")
Something bad happened before this call; the paths list is screwed up in the output-files defmethod around compile-op (a few lines below the above snippet). It is merely (#P"C:ltk.fas").
From a few TRACEs, it appears that *default-pathname-defaults* is #P"C:", and this is the value of component-parent-pathname. Component-relative-pathname is "ltk.lisp".
Hm. That looks like the *default-pathname-defaults* has only a :device (or possibly a :host) but no :directory component. I really don't have the foggiest idea how that could have happened. I'm afraid I am neither a windows nor a clisp user, so someone else will have to step in here.
Looks like that :directory argument is simply the output of (implementation-specific-directory-name) and that agrees that pathname-directory of path NIL.
No idea why this is happening, but I suspect it's a problem with the system pathname somehow.
If the *default-pathname-defaults* has a logical host, then all the paths that are parsed (ie. by #P) must have the same logical host, if it's a logical pathname syntax, or implementation dependant if it's a physical pathname syntax. My conclusion is that it is a very bad idea to put a logical host in *default-pathname-defaults*. In the case of MS-Windows, an additionnal problem is that the physical device syntax is indistinguishable from a logical host syntax. How does (let ((*default-pathname-defaults* (make-pathname :host nil :device nil :directory nil :name nil :type nil :version nil))) (values (make-pathname :host "C") and (make- pathname :device "C"))) print in clisp on MS-Windows? In the case of clisp on cygwin or macosx, :device "C" is illegal. -- __Pascal Bourguignon__ http://www.informatimago.com
Daniel Herring wrote:
Thanks for the ideas. Poking around a bit further, it appears that in the following snippet from output-files-using-mappings (*centralize-lisp-binaries* is false), (pathname-directory path) is nil.
(make-pathname :type (pathname-type path) :directory (append (pathname-directory path) (implementation-specific-directory-name)) :defaults path)))))
Thus clisp is seeing ":directory (clisp)" without a leading :relative or :absolute. I don't know the cause and am focused on other issues right now (this one has a couple workarounds: use ccl or an older asdf).
I think the code should be (merge-pathnames (make-pathname :directory (cons :relative (implementation-specific-directory-name))) path) (your code above seems to assume that (implementation-specific-directory-name) returns a list) also, if path could be relative, you will need to bind *MERGE-PATHNAMES-ANSI* to T around this call. Sam.
On 1/25/10 Jan 25 -4:46 PM, Sam Steingold wrote:
Daniel Herring wrote:
Thanks for the ideas. Poking around a bit further, it appears that in the following snippet from output-files-using-mappings (*centralize-lisp-binaries* is false), (pathname-directory path) is nil.
(make-pathname :type (pathname-type path) :directory (append (pathname-directory path) (implementation-specific-directory-name)) :defaults path)))))
Thus clisp is seeing ":directory (clisp)" without a leading :relative or :absolute. I don't know the cause and am focused on other issues right now (this one has a couple workarounds: use ccl or an older asdf).
I think the code should be
(merge-pathnames (make-pathname :directory (cons :relative (implementation-specific-directory-name))) path)
(your code above seems to assume that (implementation-specific-directory-name) returns a list)
also, if path could be relative, you will need to bind *MERGE-PATHNAMES-ANSI* to T around this call.
Is that really right? Seems like (pathname-directory path) here should NEVER return NIL, and that's what the bug is.... best, Robert
participants (5)
-
Daniel Herring -
dherring＠tentpost.com
-
Pascal J. Bourguignon -
Robert Goldman -
Sam Steingold