When trying to compile a file from slime (with slime-compile-and-load-file) I get the following error:
PARSE-NAMESTRING: syntax error in filename "g:\Programme\cygwin\home\Joreji\opengl-test.lisp" at position 2
This is due to the convert-standard-filename function which slime-to-lisp-filename-function is set to (with the recent cvs revision). Once I change slime-to-lisp-filename-function to #'identity it all works again (well, the way it "works" on windows anyway, heh). Is it possible PARSE-NAMESTRING has difficulties with the backslash ("") ?
I'm using: GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600) of 2008-09-09 on LENNART-69DE564 (patched) Cygwin on Windows XP Recent (updated 10 minutes ago) version of cvs slime (though the change to convert-standard-filename has been made a few days ago as I see it).
Regards, Thomas K.
* Thomas Karolski [2008-10-10 22:39+0200] writes:
When trying to compile a file from slime (with slime-compile-and-load-file) I get the following error:
PARSE-NAMESTRING: syntax error in filename "g:\Programme\cygwin\home\Joreji\opengl-test.lisp" at position 2
This is due to the convert-standard-filename function which slime-to-lisp-filename-function is set to (with the recent cvs revision). Once I change slime-to-lisp-filename-function to #'identity it all works again (well, the way it "works" on windows anyway, heh). Is it possible PARSE-NAMESTRING has difficulties with the backslash ("") ?
Probably, or it could also be a problem with "g:". Which lisp is this?
PARSE-NAMESTRING isn't very useful for parsing filenames because a (name)string can also be a logical pathname and the syntax for filenames (where filename is whatever the file system defines as filename) can clash with the syntax for logical pathnames. There is no function in the CL standard to parse filenames, we have to write our own.
Helmut.
Helmut Eller wrote:
Probably, or it could also be a problem with "g:". Which lisp is this?
GNU CLISP 2.46 (2008-07-02) (built on reini [10.0.0.5]) Software: GNU C 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) gcc -O2 -pipe -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -Wmissing-declarations -Wno-sign-compare -O2 -fexpensive-optimizations -falign-functions=4 -DUNICODE -DDYNAMIC_FFI -I. -Wl,--enable-auto-image-base -Wl,--enable-auto-import -Wl,--stack,8388608 -x none -lintl -liconv -lavcall -lcallback -lreadline -lncurses -lsigsegv -L/usr/X11R6/lib SAFETY=0 HEAPCODES STANDARD_HEAPCODES SPVW_PAGES SPVW_MIXED libsigsegv 2.4 libiconv 1.11 libreadline 5.2 Features: (READLINE REGEXP SYSCALLS I18N LOOP COMPILER CLOS MOP CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI GETTEXT UNICODE BASE-CHAR=CHARACTER PC386 UNIX CYGWIN) C Modules: (clisp i18n syscalls regexp readline) Installation directory: /usr/lib/clisp-2.46/ User language: ENGLISH
PARSE-NAMESTRING isn't very useful for parsing filenames because a (name)string can also be a logical pathname and the syntax for filenames (where filename is whatever the file system defines as filename) can clash with the syntax for logical pathnames. There is no function in the CL standard to parse filenames, we have to write our own.
In CLISP the following works (note the single backslash): (parse-namestring "g:\path") the following does not (note the double backslash): (parse-namestring "g:\path") => PARSE-NAMESTRING: syntax error in filename "g:\path" at position 2
I somewhat fail to debug slime, since edebug in emacs has trouble tracing the swank functions. Though it seems the problem lies with the two backslashes.
Regards, Thomas K.
* Thomas Karolski [2008-10-11 23:15+0200] writes:
Helmut Eller wrote:
Probably, or it could also be a problem with "g:". Which lisp is this?
GNU CLISP 2.46 (2008-07-02) (built on reini [10.0.0.5])
[...]
BASE-CHAR=CHARACTER PC386 UNIX CYGWIN)
I guess the cygwin version wants Unix style filenames.
PARSE-NAMESTRING isn't very useful for parsing filenames because a (name)string can also be a logical pathname and the syntax for filenames (where filename is whatever the file system defines as filename) can clash with the syntax for logical pathnames. There is no function in the CL standard to parse filenames, we have to write our own.
In CLISP the following works (note the single backslash): (parse-namestring "g:\path")
Note that \ is also the escape character in strings, so "g:\path" is the same as "g:path".
the following does not (note the double backslash): (parse-namestring "g:\path") => PARSE-NAMESTRING: syntax error in filename "g:\path" at position 2
Has CLISP/Cygwin a function to parse Windows filenames? We could use that to provide an implementation for swank-backend:filename-to-pathname.
I somewhat fail to debug slime, since edebug in emacs has trouble tracing the swank functions. Though it seems the problem lies with the two backslashes.
The *slime-events* buffer contains the log of the messages sent over the wire.
Helmut.
Helmut Eller wrote:
Note that \ is also the escape character in strings, so "g:\path" is the same as "g:path".
Ah yes, true. Then indeed the problem must be the "" inside the path.
Has CLISP/Cygwin a function to parse Windows filenames? We could use that to provide an implementation for swank-backend:filename-to-pathname.
Unfortunately I don't know of any such function. Though basically all it would need to do, is to make sure to convert any backslashes to normal slashes, as these are not allowed with parse-namestring.
The *slime-events* buffer contains the log of the messages sent over the wire.
Interesting, I didn't know that. Here's what I get (trimmed backtrace): ---------------------------------------------------- (:emacs-rex (swank:compile-file-for-emacs "e:\temp\Coden\_Lisp\space\space.asd" t) ":space-asd" t 2) (:debug 0 1 ("PARSE-NAMESTRING: syntax error in filename "e:\\temp\\Coden\\_Lisp\\space\\space.asd" at position 2" " [Condition of type SYSTEM::SIMPLE-PARSE-ERROR]" nil) (("ABORT" "Return to SLIME's top level.") ("CLOSE-CONNECTION" "Close SLIME connection")) [...] (2)) (:debug-activate 0 1 nil) (:emacs-rex (swank:throw-to-toplevel) nil 0 3) (:return (:abort) 3) (:debug-return 0 1 nil) (:return (:abort) 2) ----------------------------------------------------
Regards, Thomas K.
-
Helmut Eller -
Thomas Karolski