[racket-dev] need help with pr-13350: readline busy polling vs callback fix?

From: Danny Yoo (dyoo at hashcollision.org)
Date: Sat Feb 9 00:09:18 EST 2013

>
> However, when I try using this in the larger context of xrepl, I've
> found that I've completely broken it.
>
> #######
> $ ~/local/racket/bin/racket
> Welcome to Racket v5.3.3.1.
>> (require xrepl)
> -> hello
> -> world
> -> help
> #######



There's something funny with buffered input going on.  If I do the
following interaction on my pr-13350 branch, then the results are much
better:

#################################
128-110-82-95:readline dyoo$ ~/local/racket/bin/racket
Welcome to Racket v5.3.3.1.
> (file-stream-buffer-mode (current-input-port) 'none)
> (require xrepl)
->
   1
1
-> 2
2
-> 3
3
#################################


So part of the problem I'm running into seems related to how Racket is
block-buffering the standard input port.  This probably messes with
readline, which needs to look at the raw stdin object to make sense of
it.

I'm still very confused!  How do FFI-wrapped C functions deal with
standard input?  Does that mean that they normally need to access
stdin via Racket itself, since the port is probably eating blocks of
stdin already?



There are still a few oddities.

* It's off by a little because of the extra newline, which I don't
understand yet.  Is that the newline right after the "(require xrepl)"
that hasn't been consumed yet?

* If I try to set file-stream-buffer-mode within an xrepl module, I
see no benefit yet.  I seem to have to do this at the REPL, before
loading xrepl.  Very confused... :(

Posted on the dev mailing list.