[plt-scheme] MzScheme and read-line

Thanks, YC.  I will give this a try. Note, however, that if I found this
confusing, others will too. This is a difference in behavior from running
under DrScheme and MzScheme.  I would recommend that it be documented
somewhere.  -- Eric

On Fri, Oct 2, 2009 at 11:50 AM, YC <yinso.chen at gmail.com> wrote:

>
>
> On Fri, Oct 2, 2009 at 9:23 AM, Eric Swenson <eric at swenson.org> wrote:
>
>>
>>
>> On Fri, Oct 2, 2009 at 9:21 AM, Eric Swenson <eric at swenson.org> wrote:
>>
>>> Hello Chongkai,
>>> Thanks for your suggestions.  I tried this, but it didn't work.  In the
>>> case where (read-line) is returning "\r", I note that read-bytes-avail!* is
>>> returning 0, yet a subsequent read-line still returns "\r".  (I tried your
>>> example code exactly, and my-read-line returns "\r" as well.)  I wonder if
>>> this is a Win32 issue (line-ending issue) where some of the win32-specific
>>> support is not stripping the "\r" from the end-of-line sequence "\n\r"?
>>>
>>
> The line ending on Windows is \r\n instead of \n\r.  The reason you have \r
> returned is because (read-line) as is by default only use \n as a
> terminator, so when it sees \r\n it thinks \r is the data and returns it (on
> Unix it only sees \n, so the data is "").
>
> Use (read-line (current-port) *'any*) instead of just plain (read-line)
> will treat \r\n as a single terminator.
>
> As Chongkai said - when you type (read-line)<enter> the reader will consume
> the (read-line) but leaves <enter> in the buffer, which read-line then
> consumes, so you need a function that has two read-line calls, the first
> will consume the left over, and the second will then wait on input.
>
> (define (my-read-line)
>   (read-line (current-input-port) 'any)
>   (read-line (current-input-port) 'any))
>
> Since this specifically tackles the behavior of REPL - it has limited
> applicability elsewhere.
>
> Cheers,
> yc
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20091002/99995147/attachment.html>