From: Alex M. <kil...@ne...> - 2004-10-01 14:07:02
|
hello (compile-system) failed on my system, sources are newest from cvs. my system is winxp, sun java 1.4.2_05. if fails on asdf.lisp, function operate. here's a backtrace: 0: (EXTENSIONS:BACKTRACE-AS-LIST) 1: (SIGNAL #<FORMAT::FORMAT-ERROR @ #x1443800>) 2: (ERROR FORMAT::FORMAT-ERROR :COMPLAINT "unknown directive ~@[(character: ~A)~]" :ARGS ("Return")) 3: (FORMAT::EXPAND-DIRECTIVE #S(FORMAT::FORMAT-DIRECTIVE :STRING "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>" :START 34 :END 36 :CHARACTER #\Ret urn :COLONP NIL :ATSIGNP NIL :PARAMS NIL) (" " #S(FORMAT::FORMAT-DIRECTIVE :STRING "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>" :START 76 :END 76 :CHARACTER #\_ : COLONP T :ATSIGNP NIL :PARAMS NIL) "having " #S(FORMAT::FORMAT-DIRECTIVE :STRING "~@<Continue, treatin g ~S on ~S as ~ having been successful.~@:>" :START 83 :END 83 :CHARACTER #\_ : COLONP T :ATSIGNP NIL :PARAMS NIL) "been " #S(FORMAT::FORMAT-DIRECTIVE :STRING "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>" :START 88 :END 88 :CHARACTER #\_ : COLONP T :ATSIGNP NIL :PARAMS NIL) "successful.")) .. and so on.. 9: (FORMAT::EXPAND-CONTROL-STRING "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>") 10: (FORMAT::%FORMATTER "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>") 11: (#<FUNCTION @ #xe0fcac> (FORMATTER "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>") #<ENVIRONMENT @ #xecb3f1>) 12: (MACROEXPAND-1 (FORMATTER "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>")) 13: (PRECOMPILER::EXPAND-MACRO (FORMATTER "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>")) 14: (PRECOMPILER::PRECOMPILE1 (FORMATTER "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>")) 15: (MAPCAR #<FUNCTION PRECOMPILER::PRECOMPILE1> (S (FORMATTER "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>") OP COMPONENT)) 16: (PRECOMPILER::PRECOMPILE-CONS (FORMAT S (FORMATTER "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>") OP COMPONENT)) 17: (PRECOMPILER::PRECOMPILE1 (FORMAT S (FORMATTER "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>") OP COMPONENT)) 18: (MAPCAR #<FUNCTION PRECOMPILER::PRECOMPILE1> ((FORMAT S (FORMATTER "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>") OP COMPONENT))) 19: (PRECOMPILER::MAYBE-REWRITE-LAMBDA (LAMBDA (S) (FORMAT S (FORMATTER "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>") OP COMPONENT))) when i tried to compile it with binaries 0.21.0 it just crashed into infinite errors.. with best regards, Alex 'killer_storm' Mizrahi. |
From: Peter G. <pe...@ar...> - 2004-10-01 19:14:26
|
On Fri, 1 Oct 2004 at 17:06:43 +0300, Alex Mizrahi wrote: > hello > > (compile-system) failed on my system, sources are newest from cvs. > my system is winxp, sun java 1.4.2_05. > if fails on asdf.lisp, function operate. > here's a backtrace: > > 0: (EXTENSIONS:BACKTRACE-AS-LIST) > 1: (SIGNAL #<FORMAT::FORMAT-ERROR @ #x1443800>) > 2: (ERROR FORMAT::FORMAT-ERROR :COMPLAINT "unknown directive > ~@[(character: ~A)~]" :ARGS ("Return")) It looks like you're trying to compile source files with lines that end in #\return + #\linefeed; that's not going to work as things stand. The issue is really with FORMAT, and there is some disagreement about the proper fix. (formatter "~@<Continue, treating ~S on ~S as ~ having been successful.~@:>") Currently the tilde newline format directive at the end of the first line won't work if the #\newline after the tilde is preceded by a #\return. =46rom section 22.3.9.3: "Tilde immediately followed by a newline ignores the newline and any following non-newline whitespace characters." where newline is defined in the Glossary as follows: newline n. the standard character <Newline>, notated for the Lisp reader as #\Newline. My own inclination is to define a "tilde return" format directive for ABCL which would do the right thing on Windows (it would ignore the return and any following non-return whitespace characters, including #\newline), and make this a part of ABCL's FORMAT both on Windows and on Unix, so that both platforms could use source files with either kind of line ending. But I don't think that's quite ANSI, and the idea was not universally well-received, so I haven't implemented it. The workaround is to fix the line endings. It's also possible that asdf.lisp is the only library file that will run into this problem, so you might try commenting out the "asdf.lisp" line in compile-system.lisp.= -Peter |
From: Alex M. <kil...@ne...> - 2004-10-01 20:03:49
|
hello PG> My own inclination is to define a "tilde return" format directive PG> for PG> ABCL which would do the right thing on Windows (it would ignore the PG> return and any following non-return whitespace characters, including PG> #\newline), and make this a part of ABCL's FORMAT both on Windows PG> and on Unix, so that both platforms could use source files with PG> either kind of line ending. But I don't think that's quite ANSI, and PG> the idea was not universally well-received, so I haven't implemented PG> it. this solution looks fine for me. and not only for me - all implementations i can run under win32 are performing in that way. they are: clisp allegro cl lispworks cormanlisp and even ECLs with best regards, Alex 'killer_storm' Mizrahi. |
From: Alex M. <kil...@ne...> - 2004-10-01 21:45:05
|
hello AM> this solution looks fine for me. and not only for me - all AM> implementations i can run under win32 are performing in that way. AM> they are: AM> clisp allegro cl lispworks cormanlisp and even ECLs i was wrong, they are not performing in that way.. clisp, allegro, lispworks and cormanlisp ignore #\return when reading from file. (this looks odd as for me) ecl reads all characters from file as they are. lispworks and clisp break down telling that #\~ #\return is invalid, others have (format nil (coerce (list #\A #\~ #\Return #\Newline #\B) 'string)) => "AB". if i remove #\Newline from above it can be deduced how they do that.. cormanlisp tells that ~B is wrong, so it just ignore #\Return in string. allegro does something similar. only ecl raises no error in this case, so looks like there's ~Return in ecl.. with best regards, Alex 'killer_storm' Mizrahi. |
From: Christophe R. <cs...@ca...> - 2004-10-02 09:38:07
|
Peter Graves <pe...@ar...> writes: > On Fri, 1 Oct 2004 at 17:06:43 +0300, Alex Mizrahi wrote: >> hello >> >> (compile-system) failed on my system, sources are newest from cvs. >> my system is winxp, sun java 1.4.2_05. >> if fails on asdf.lisp, function operate. >> here's a backtrace: >> >> 0: (EXTENSIONS:BACKTRACE-AS-LIST) >> 1: (SIGNAL #<FORMAT::FORMAT-ERROR @ #x1443800>) >> 2: (ERROR FORMAT::FORMAT-ERROR :COMPLAINT "unknown directive >> ~@[(character: ~A)~]" :ARGS ("Return")) > > It looks like you're trying to compile source files with lines that end > in #\return + #\linefeed; that's not going to work as things stand. Wait a minute. Alex is on Windows, where the #\Newline character in lisp naturally translates to the byte sequence <CR><LF>. Are you saying that abcl on Windows reads in <CR><LF> as two characters? Surely that is wrong. (The default external format for character streams should perform newline conversion transparently for the platform in question) Cheers, Christophe |
From: Peter G. <pe...@ar...> - 2004-10-02 19:57:11
|
On Sat, 02 Oct 2004 at 10:29:58 +0100, Christophe Rhodes wrote: > Wait a minute. Alex is on Windows, where the #\Newline character in > lisp naturally translates to the byte sequence <CR><LF>. Are you > saying that abcl on Windows reads in <CR><LF> as two characters? > Surely that is wrong. (The default external format for character > streams should perform newline conversion transparently for the > platform in question) Fair enough. I've committed a fix that purports to implement this suggestion. Character input streams should now convert <CR><LF> to #\newline on input and #\newline to <CR><LF> on output, on Windows only. This fixes the problem with the tilde newline FORMAT directive in asdf.lisp. I only touched the code for file-based streams. Interactive streams seemed to just work, but I didn't do much testing. Running the ANSI test suite on Windows yields 147 failures, compared to 135 on Linux. I haven't had a chance to investigate the additional failures in detail, but in general they don't seem to be related to line endings. Thanks to Christophe for clearing up my confusion (as he often does). -Peter |