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 <d...@hashcollision.org> 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
