Review of SRFI 170 through 3.2 I/O hga@xxxxxx 22 Apr 2020 17:13 UTC
Re: Review of SRFI 170 through 3.2 I/O John Cowan 22 Apr 2020 20:42 UTC
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela 22 Apr 2020 20:53 UTC
Re: Review of SRFI 170 through 3.2 I/O John Cowan 22 Apr 2020 21:29 UTC
Re: Review of SRFI 170 through 3.2 I/O hga@xxxxxx 22 Apr 2020 23:57 UTC
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela 22 Apr 2020 21:36 UTC
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela 22 Apr 2020 21:42 UTC
Re: Review of SRFI 170 through 3.2 I/O John Cowan 23 Apr 2020 03:37 UTC
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela 23 Apr 2020 07:02 UTC
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela 23 Apr 2020 07:05 UTC
Re: Review of SRFI 170 through 3.2 I/O Göran Weinholt 23 Apr 2020 10:53 UTC
Re: Review of SRFI 170 through 3.2 I/O Marc Feeley 23 Apr 2020 11:09 UTC
Per-thread umask Lassi Kortela 23 Apr 2020 11:30 UTC
Re: Per-thread umask Marc Feeley 23 Apr 2020 11:43 UTC
Re: Per-thread umask Lassi Kortela 23 Apr 2020 11:47 UTC
Re: Per-thread umask Marc Feeley 23 Apr 2020 11:59 UTC
Re: Per-thread umask John Cowan 23 Apr 2020 15:03 UTC
Re: Per-thread umask Marc Feeley 23 Apr 2020 15:20 UTC
Re: Per-thread umask Lassi Kortela 23 Apr 2020 16:02 UTC
Re: Per-thread umask John Cowan 23 Apr 2020 16:03 UTC
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela 23 Apr 2020 11:14 UTC
current directory and openat() et al Lassi Kortela 23 Apr 2020 11:27 UTC
Re: current directory and openat() et al Marc Feeley 23 Apr 2020 13:56 UTC
Re: Review of SRFI 170 through 3.2 I/O Sebastien Marie 23 Apr 2020 13:32 UTC
Definition of working directory Lassi Kortela 23 Apr 2020 13:51 UTC
Re: Definition of working directory Marc Feeley 23 Apr 2020 14:06 UTC
Re: Definition of working directory Sebastien Marie 23 Apr 2020 15:31 UTC
Re: Review of SRFI 170 through 3.2 I/O Marc Nieper-Wißkirchen 23 Apr 2020 15:24 UTC
Separate high-level and low-level APIs Lassi Kortela 23 Apr 2020 15:38 UTC
Re: Separate high-level and low-level APIs Marc Nieper-Wißkirchen 23 Apr 2020 15:43 UTC
Re: Separate high-level and low-level APIs Lassi Kortela 23 Apr 2020 15:48 UTC
Re: Separate high-level and low-level APIs hga@xxxxxx 23 Apr 2020 16:19 UTC
Re: Separate high-level and low-level APIs Lassi Kortela 23 Apr 2020 16:42 UTC
Re: Review of SRFI 170 through 3.2 I/O hga@xxxxxx 23 Apr 2020 15:40 UTC
Re: Review of SRFI 170 through 3.2 I/O Marc Feeley 23 Apr 2020 11:33 UTC
Normalizing the current directory Lassi Kortela 23 Apr 2020 11:38 UTC
Re: Normalizing the current directory Marc Feeley 23 Apr 2020 11:55 UTC
Re: Normalizing the current directory Lassi Kortela 23 Apr 2020 12:09 UTC
Using paths that are searchable but not completely readable hga@xxxxxx 23 Apr 2020 12:29 UTC
Per-thread working directory and umask proposal John Cowan 23 Apr 2020 14:13 UTC
Re: Per-thread working directory and umask proposal Marc Feeley 23 Apr 2020 14:16 UTC
Re: Per-thread working directory and umask proposal John Cowan 23 Apr 2020 16:07 UTC
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen 23 Apr 2020 16:13 UTC
Re: Per-thread working directory and umask proposal Marc Feeley 23 Apr 2020 16:25 UTC
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen 23 Apr 2020 17:26 UTC
Re: Per-thread working directory and umask proposal John Cowan 23 Apr 2020 18:38 UTC
Re: Per-thread working directory and umask proposal Marc Feeley 23 Apr 2020 17:55 UTC
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen 23 Apr 2020 18:55 UTC
Re: Per-thread working directory and umask proposal John Cowan 23 Apr 2020 20:12 UTC
Re: Per-thread working directory and umask proposal Shiro Kawai 23 Apr 2020 22:17 UTC
Re: Per-thread working directory and umask proposal Lassi Kortela 24 Apr 2020 08:43 UTC
Re: Per-thread working directory and umask proposal Shiro Kawai 24 Apr 2020 11:27 UTC
Re: Per-thread working directory and umask proposal Lassi Kortela 24 Apr 2020 11:37 UTC
Re: Per-thread working directory and umask proposal Shiro Kawai 24 Apr 2020 12:22 UTC
Re: Per-thread working directory and umask proposal Marc Feeley 24 Apr 2020 12:28 UTC
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen 26 Apr 2020 09:19 UTC
Re: Per-thread working directory and umask proposal John Cowan 27 Apr 2020 22:45 UTC
Re: Per-thread working directory and umask proposal Shiro Kawai 27 Apr 2020 23:42 UTC
Re: Per-thread working directory and umask proposal John Cowan 28 Apr 2020 00:41 UTC
Re: Per-thread working directory and umask proposal Shiro Kawai 28 Apr 2020 00:56 UTC
os-working-directory Lassi Kortela 29 Apr 2020 09:23 UTC
Re: os-working-directory Duy Nguyen 29 Apr 2020 09:28 UTC
current-umask Lassi Kortela 29 Apr 2020 09:43 UTC
Windows Lassi Kortela 29 Apr 2020 09:47 UTC
Re: Windows Lassi Kortela 29 Apr 2020 09:49 UTC
Re: Windows John Cowan 29 Apr 2020 14:53 UTC
Re: current-umask hga@xxxxxx 29 Apr 2020 13:14 UTC
Re: current-umask Lassi Kortela 29 Apr 2020 13:25 UTC
Re: current-umask Marc Feeley 29 Apr 2020 13:31 UTC
Re: current-umask Marc Feeley 29 Apr 2020 13:45 UTC
Re: current-umask Lassi Kortela 29 Apr 2020 14:12 UTC
Re: current-umask hga@xxxxxx 29 Apr 2020 16:20 UTC
Re: current-umask Lassi Kortela 29 Apr 2020 16:44 UTC
Re: current-umask John Cowan 30 Apr 2020 04:02 UTC
Re: os-working-directory John Cowan 30 Apr 2020 02:49 UTC
Re: os-working-directory Lassi Kortela 30 Apr 2020 06:12 UTC
Re: os-working-directory Sebastien Marie 30 Apr 2020 07:19 UTC
Re: os-working-directory Sebastien Marie 30 Apr 2020 07:53 UTC
Should the SRFI mandate current-directory per thread? Lassi Kortela 30 Apr 2020 12:14 UTC
Re: Should the SRFI mandate current-directory per thread? Sebastien Marie 30 Apr 2020 17:00 UTC
Re: Per-thread working directory and umask proposal hga@xxxxxx 28 Apr 2020 01:03 UTC
Re: Per-thread working directory and umask proposal Marc Feeley 28 Apr 2020 01:41 UTC
Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen 30 Apr 2020 07:11 UTC
Re: Per-thread working directory and umask proposal Marc Feeley 30 Apr 2020 11:33 UTC

Re: Per-thread working directory and umask proposal Marc Nieper-Wißkirchen 30 Apr 2020 07:11 UTC

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