Hi all,

I think I roughly see the policy for the way ABCL treats newlines on different operating systems. But there are some bits that don't seem to fit well with Slime.

I have a specific problem in mind here. In the latest (3 Mar) slime/swank, I narrowed the issue down to this (ignore indentation, and the REPL numbers, they're out of order):

Firstly, this is the 0.13.0 ABCL tarball. Running on Windows.

CL-USER(33): (lisp-implementation-type) "Armed Bear Common Lisp" CL-USER(34): (lisp-implementation-version) "0.13.0" CL-USER(39): *features* (:ASDF :X86 :JAVA-1.5 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :WINDOWS :CDR6)

Internal newline representation

CL-USER(35): #\linefeed #\Newline SWANK(57): #\return #\Return

CL-USER(31): (coerce (format nil "~%") 'list) (#\Newline) CL-USER(32): (mapcar #'char-code (coerce (format nil "~%") 'list)) (10)

CL-USER(30): (with-open-file (s "c:/home/temp/temp.txt" :direction :output :if-exists :supersede) (write-string (format nil "~%") s)) " " CL-USER(38): (with-open-file (s "c:/home/temp/temp.txt" :element-type '(unsigned-byte 8)) (loop for b = (read-byte s nil nil) while b collect b)) (13 10)

It looks like ABCL uses #\Newline internally. Conversion happens on print/reading. Doesn't clisp do conversions on prints? Swank's encode-message ran afoul of this issue because the encoded message length (internal length of string) and what is written out with write-string are inconsistent.

From a cursory skim through the Hyperspec, I think ABCL hasn't

violated any standards, so slime is the one who's wrong here, but I don't really know the Hyperspec that well. What does everyone think?

If I apply the attached hack, I now get the following problem in my Slime REPL:

CL-USER> 60 60^M CL-USER>

So it's probably not quite the right way to do things. Any suggestions or fixes?

Cheers,

Theam Yong Chew