[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I/O in geiser-eval-buffer
Jose A. Ortega Ruiz
Re: I/O in geiser-eval-buffer
Sun, 19 Jan 2020 01:11:20 +0000
On Sat, Jan 18 2020, Vladimir Nikishkin wrote:
> Well, the input of the repl buffer does get delivered to the interpreter,
> doesn't it?
> I can imagine it working the following way:
> When a piece of code (containing something that reads stdin) is
> submitted for evaluation, it gets evaluated in a separate thread, with
> stdin and stdout (parameterize)'d with something, so the thread would
> lock on reading from an empty port.
That's tricky. Detecting that "a piece of code reads from stdin" is in
> Meanwhile the main loop would return '(request nrequest accepted) and
> wait for the new requests.
Having more than one evaluation requests active at the same time in a
single scheme is possible in some implementations, but very prone to
cause confusing behaviour due to race conditions.
> In Emacs, it would be possible to change to the repl buffer and the
> next request would be not evaluated, but rather unmarshalled and
> written into the parameterized port.
> I'm a bit confused that geiser seems to be mixing it's own environment
> with that of the executable code.
It's not optimal, but the only part of the environment mixed is the
standard input/output, used for communication. Other than that, all
geiser computations occur in a separate module. Except of course the
ones requested by the user, which must occur in the environment of the
executable code, by design.
> Moreover, the thread monitor could be potentially polling the output
> parameterized port, and deliver the output to the repl (or any other
> consumer) piecemeal.
> Does this make any sense?
It does. It's just not the way Geiser is implemented. While what you
propose is doable, it involves trade-offs and it's a lot of work for a
feature that i, personally, don't consider worth it. That doesn't mean
that it isn't, and i'll happily review and accept patches :)
> Jose A. Ortega Ruiz <address@hidden> 於 2020年1月18日週六 12:00 寫道：
> On Sat, Jan 18 2020, Vladimir Nikishkin wrote:
> > Hello, everyone
> > I have the following tiny example:
> > (display "hello")
> > (read)
> > I also have guile running in run-geiser
> > M-x geiser-eval-buffer RET doesn't work. Or, rather, it works in a
> weird way.
> > After I type the command, Emacs locks.
> > I can then C-g and switch to the REPL buffer, and type
> > (hi)^J
> > The parentheses are shown, but "hi" isn't.
> > Then I C-g again, and the repl shows:
> > ((result "(hello)") (output . "hello"))
> > typeset in red.
> > So I am not really able to debug anything interactive with geiser.
> Nope, that's a limitation of geiser.
> > Can evaluation be made asynchronous?
> It is already asynchronous, but it doesn't know how to read
> interactively (it cannot prompt you easily, in part precisely because
> it's async).
> The place to try interactive things is the REPL; there typing (read)
> will work. When I want to try interactive things, it's never evaluating
> (read) or similar directly in a *module*. Rather, i've got modules with
> functions that are interactive
> ;; scheme buffers in geiser are always considered modules
> (define-module ...)
> ;; lots of code here, then...
> (define (ask-user) .... (read))
> and then i go to the REPL and there i evaluate (ask-user) to try. It is
> unusual to have a module that calls anything interactive when loaded,
> and what geiser-eval-buffer does is loading a module.
> One can also run a guile independently, and connect to it from emacs
> with geiser-connect (check the manual for details), and then run
> interactive things in the independent guile. That again is not what
> you're asking for, but it's all that we have :)
> We are usually convinced more easily by reasons we have found
> ourselves than by those which have occurred to others.
> -Blaise Pascal, philosopher and mathematician (1623-1662)
Convictions are more dangerous enemies of truth than lies.
-Friedrich Wilhelm Nietzsche, philosopher (1844-1900)