Am Fr., 24. Apr. 2020 um 14:28 Uhr schrieb Marc Feeley
<xxxxxx@iro.umontreal.ca>:

[...]

> Say you want to debug a program remotely, so from your program’s main thread you start a thread that implements a REPL through a network connection.  The following code could be used with Gambit, but it should be easy to adapt to other Scheme’s with threads and networking:
>
>  ;; remote-repl.scm
>
>  (define (remote-repl addr)
>    (let ((conn (open-tcp-client addr)))
>      (let loop ()
>        (display "\n> " conn)
>        (force-output conn)
>        (write (eval (read conn)) conn)
>        (loop))))
>
>  (thread-start!
>   (make-thread
>    (lambda ()
>      (remote-repl "localhost:7000"))))
>
> In another terminal you run “nc -l 7000” to listen for the connection.  Now in this terminal you can inspect through this REPL what is happening in your program.
>
> If your program’s main thread has an issue because its binding for the current-directory parameter is not /tmp as it should be, then you can simply enter (current-directory "/tmp") in the remote REPL.  It is that simple because the main thread and the REPL thread share the same parameter cells.  With the b semantics you can’t implement this because current-directory is a predefined parameter and you can’t wrap it in a “box” to get the sharing semantics (more generally semantics b doesn’t scale because even if you could easily add the “box” to this parameter, you would also need to change all the places that access the current-directory in all your code and libraries, some of which are part of the runtime system that you can’t change).

I have just noticed that this wouldn't work reliably, would it? The
setting of parameters needn't be an atomic operation, so one of the
two threads may see a corrupted state of the current directory. Or do
you want to make setting parameters an atomic operation, which would
probably involve locks around every reading and writing of parameters?

Marc