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