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?
On Sat, Feb 9, 2013 at 6:12 AM, Robby Findler 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?
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: Welcome to Racket v5.3.3.1. > (define p (open-input-string "()\n")) > (read p) '() > (peek-char p) #\newline On Fri, Feb 8, 2013 at 11:09 PM, Danny Yoo wrote: > > > > 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 > _ 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
[racket-dev] need help with pr-13350: readline busy polling vs callback fix?
I'm trying to attack PR-13350, which is the busy-polling bug involving readline. The closest I've got so far is: https://github.com/dyoo/racket/tree/pr-13350 When I run the small test program: ### $ cat test.rkt #lang racket/base (require readline/mzrl) (list (readline-bytes #">>> ") (readline "... ")) ### Everything is happy: CPU usage is close to zero, and the program appears to do the right thing: ### $ ~/local/racket/bin/racket test.rkt >>> hello ... world '(#"hello" "world") ### 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 ### where the repl isn't paying attention at all. There is something crucial that I don't understand, but I've stared at this too long. I'm completely baffled at the moment. _ Racket Developers list: http://lists.racket-lang.org/dev
