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 general non-decidable. > 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 :) Cheers, jao > > Jose A. Ortega Ruiz <m...@jao.io> 於 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 :) > > Cheers, > jao > -- > 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)
