Re: I/O in geiser-eval-buffer

[Jose A. Ortega Ruiz]

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 <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 :)
>
>     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)