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) -
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 see
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 Yo
>
> 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 o
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 #">>> ")
5 matches
Mail list logo
