[cmucl-imp] Compiling files with traditional Mac EOL in CMUCL
Hi, I'm surprised that CMUCL doesn't support lisp files with traditional Mac EOL, that is, lines are separated by a single '\r', there's no `\n` at all. Here is my recent story: I'm porting some old Lisp code originally developed in Macintosh Common Lisp 4.2. All files use Mac EOL. I can't convert them to Unix EOL, because that will break some Lisp functions in MCL. The problem when compiling these files in CMUCL is, if there's a line-based comment starting with semicolon ";", CMUCL compiler will consider all the rest code in the file is at the "same" line, thus they're all commented! It looks like CMUCL has correctly compiled the file (because there's no warning at all), but actually it compiled almost nothing. SBCL and LispWorks have no such issues, I can imagine Clozure CL must natively support Mac EOL. Is this a CMUCL bug that can be fixed? Regards, Chun Tian -- Chun Tian (binghe) University of Bologna (Italy)
"Chun Tian (binghe)" <binghe.lisp@gmail.com> wrote:
I'm surprised that CMUCL doesn't support lisp files with traditional Mac EOL, that is, lines are separated by a single '\r', there's no `\n` at all.
Here is my recent story: I'm porting some old Lisp code originally developed in Macintosh Common Lisp 4.2. All files use Mac EOL. I can't convert them to Unix EOL, because that will break some Lisp functions in MCL. The problem when compiling these files in CMUCL is, if there's a line-based comment starting with semicolon ";", CMUCL compiler will consider all the rest code in the file is at the "same" line, thus they're all commented! It looks like CMUCL has correctly compiled the file (because there's no warning at all), but actually it compiled almost nothing.
SBCL and LispWorks have no such issues, I can imagine Clozure CL must natively support Mac EOL.
Are you sure that SBCL is doing what you want ? The definitions of read-comment look very similar in CMUCL and SBCL. I also don't understand why you can't convert the source files to UNIX line endings.
OK, sorry, I carefully checked again. SBCL also doesn't support compiling files with Mac EOLs. Clozure CL, which I confirmed now, indeed support Mac EOLs. For the reason I can't convert the source files to UNIX line endings, there's a Lisp function for parsing (multi-line) literal strings defined in source files with MAC line endings. It seems that, #\Newline was mapped to "\r" in MCL, thus Lisp forms like (position #\Newline string) doesn't work in MCL for other line endings, especially the UNIX endings, because in this case there would be no #\Newline in the string at all! Of course, by carefully adjusting the source code there must be a way to make the code works in both MCL and SBCL/CMUCL with UNIX line endings, but I don't want to do such modifications unless necessary. There's another workaround solution: if I convert all comments to closed forms: #| ... |#, everything is fine again, but this again changed too much in the original code, not what I wanted. But if there's a small patch to let SBCL/CMUCL recognize '\r' as line separators, it would be the best for me (or others who met the same issue, while I highly doubt there would be anyone). Regards, Chun Tian On 6 September 2017 at 13:59, Robert Swindells <rjs@fdy2.co.uk> wrote:
"Chun Tian (binghe)" <binghe.lisp@gmail.com> wrote:
I'm surprised that CMUCL doesn't support lisp files with traditional Mac EOL, that is, lines are separated by a single '\r', there's no `\n` at all.
Here is my recent story: I'm porting some old Lisp code originally developed in Macintosh Common Lisp 4.2. All files use Mac EOL. I can't convert them to Unix EOL, because that will break some Lisp functions in MCL. The problem when compiling these files in CMUCL is, if there's a line-based comment starting with semicolon ";", CMUCL compiler will consider all the rest code in the file is at the "same" line, thus they're all commented! It looks like CMUCL has correctly compiled the file (because there's no warning at all), but actually it compiled almost nothing.
SBCL and LispWorks have no such issues, I can imagine Clozure CL must natively support Mac EOL.
Are you sure that SBCL is doing what you want ? The definitions of read-comment look very similar in CMUCL and SBCL.
I also don't understand why you can't convert the source files to UNIX line endings.
-- Chun Tian (binghe) University of Bologna (Italy)
"Chun" == Chun Tian <(binghe)" <binghe.lisp@gmail.com>> writes:
Chun> OK, sorry, I carefully checked again. SBCL also doesn't support compiling Chun> files with Mac EOLs. Clozure CL, which I confirmed now, indeed support Mac Chun> EOLs. Chun> For the reason I can't convert the source files to UNIX line endings, Chun> there's a Lisp function for parsing (multi-line) literal strings defined in Chun> source files with MAC line endings. It seems that, #\Newline was mapped to Chun> "\r" in MCL, thus Lisp forms like (position #\Newline string) doesn't work Chun> in MCL for other line endings, especially the UNIX endings, because in this Chun> case there would be no #\Newline in the string at all! I haven't tried this out in a long time, but maybe something like this will work: (compile-file "foo.lisp" :external-format '(:utf8 :cr)) This says to read the file using utf8 with a composing format of :cr which converts CR to/from #\newline. (I think I got the syntax right). Let us know if this works. -- Ray
"Raymond" == Raymond Toy <toy.raymond@gmail.com> writes:
"Chun" == Chun Tian <(binghe)" <binghe.lisp@gmail.com>> writes: Chun> OK, sorry, I carefully checked again. SBCL also doesn't support compiling Chun> files with Mac EOLs. Clozure CL, which I confirmed now, indeed support Mac Chun> EOLs.
Chun> For the reason I can't convert the source files to UNIX line endings, Chun> there's a Lisp function for parsing (multi-line) literal strings defined in Chun> source files with MAC line endings. It seems that, #\Newline was mapped to Chun> "\r" in MCL, thus Lisp forms like (position #\Newline string) doesn't work Chun> in MCL for other line endings, especially the UNIX endings, because in this Chun> case there would be no #\Newline in the string at all! Raymond> I haven't tried this out in a long time, but maybe something like this Raymond> will work: Raymond> (compile-file "foo.lisp" :external-format '(:utf8 :cr)) Did you get a chance to try this out? -- Ray
participants (3)
-
Chun Tian (binghe) -
Raymond Toy -
Robert Swindells