[slime-devel] ABCL newline & input/output
senatorzergling at gmail.com
Wed Mar 4 01:34:48 UTC 2009
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.
"Armed Bear Common Lisp"
(:ASDF :X86 :JAVA-1.5 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :WINDOWS :CDR6)
Internal newline representation
CL-USER(31): (coerce (format nil "~%") 'list)
CL-USER(32): (mapcar #'char-code (coerce (format nil "~%") 'list))
CL-USER(30): (with-open-file (s "c:/home/temp/temp.txt"
:direction :output :if-exists
(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
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:
So it's probably not quite the right way to do things. Any suggestions or fixes?
Theam Yong Chew
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 689 bytes
Desc: not available
More information about the slime-devel