chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] read-line


From: Joerg F. Wittenberger
Subject: Re: [Chicken-users] read-line
Date: 11 Dec 2002 12:44:44 +0100
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

Anthony Carrico <address@hidden> writes:

> On 10 Dec 2002, Joerg F. Wittenberger wrote:
> 
> > Anybody who objects this change, which understands any of:
> >  #\newline #\return
> >  #\return #\newline
> >  #\newline
> >  #\return
> > as line delimiter.  Sequences, though, should result in empty lines.
> 
> A long time ago I did a lot of work on a common-lisp-to-common-lisp
> networking package. This was a real problem. The issue with your solution
> is that #\return #\newline pairs can be split across packets, so you may
> see a lone #\return and say, "ok that is an apple end of line", but then
> if it was actually a microsoft eol split across two packets, the
> char-ready? (or equivalent) procedure will indicate a character is ready,
> when there really isn't one (the last readline should have sucked it up).
> This is an ugly problem.

It seems to be an ugly problem, actually I don't really understand it.

How can the pair be split, no that's for sure, but this should be
transparent.  Isn't it?

(if (or (eq? #\newline) (eq? c #\return) )
    (begin
      (let ((c2 (peek-char p)))

this peek-char should wait for one more character, or the EOF object,
before we decide how to treat the pair.  If the characters are
actually split over packet, then peek-char will wait for the second
packet - at least I expect it to.

         (if (and (not (eq? c2 c))
                  (or (eq? c2 #\newline)
                  (eq? c2 #\return) ))

and only when we have a sequence ( #\newline #\return ) or ( #\return
#\newline ), we skip the second character:

             (read-char p)))
         (return (substring buffer 0 i))) )

> In general, if it is possible, I would say it is best to specify the
> eol character according to the protocol, instead of the OS, and to
> code the appropriate eol into a custom readline.

True.  Actually I did not intent to tie it to the OS.

But a custom read-line is not a general read-line, which could come
with the compiler.  In Scheme spirit, I would expect the latter to
read the line, regardless of it's encoding. and hide the newline
convention (which means I'll never see either #\return or #\newline in
the resulting string).

A protocol-specific read-line could/should be IMHO build on lower
level.  It had the advantage that it would not wait in the above
scenario for the next packet just to return the line.  In return it
may have to associate a state machine with the port to track the line
end convention.  Nice, but I hope I don't need that, do I?

best regards

/Jörg

-- 
The worst of harm may often result from the best of intentions.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]