Re: [racket-dev] need help with pr-13350: readline busy polling vs callback fix?
On Sat, Feb 9, 2013 at 6:12 AM, Robby Findler ro...@eecs.northwestern.edu wrote: I can't really help with the other questions, but yes, I expect it is the newline after the require. Read doesn't read past that matching paren: I'm observing that if I try to set the file-stream-buffer-mode during module-load time, it seems ineffective for readline. I can observe this with the following program rl.rkt at the console repl. https://gist.github.com/dyoo/4743135 If I do: slab:Desktop dyoo$ racket Welcome to Racket v5.3.2. (require rl.rkt) (start) then the port seems ok, and the readlines work. But if modify rl.rkt by uncommenting the toplevel call to setup-io, and comment out the setup-io in start, https://gist.github.com/dyoo/4746640 then the readline breaks very badly when I do: slab:Desktop dyoo$ racket Welcome to Racket v5.3.2. (require rl-broken.rkt) (start) I observe that sync/enable-break in the readline loop reports that the port is available, but the underlying C world doesn't think so, hence rl-callback-read-char blocks when it tries to look at stdin. So I'm left with a puzzle: why does doing the file-stream-buffer-mode at require run time not have the same effect as doing it after the module load? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] need help with pr-13350: readline busy polling vs callback fix?
Ok. I can dodge this problem by re-routing the getc-like function that readline uses with Racket-aware stuff. (set-ffi-obj! rl_getc_function libreadline (_fun _pointer - _int) (lambda (_) (define next-byte (read-byte)) (if (eof-object? next-byte) -1 next-byte))) If I do this, then everything appears to work fine. I'll do that, and avoid the fight with the input port buffering for now. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] need help with pr-13350: readline busy polling vs callback fix?
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... :( _ Racket Developers list: http://lists.racket-lang.org/dev
