[slime-devel] ABCL newline & input/output

[szergling]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: swank.patch
Type: application/octet-stream
Size: 689 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/slime-devel/attachments/20090304/7ae22961/attachment.obj>