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