Email list hosting service & mailing list manager

(Previous discussion continued)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 15:55 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 15:59 UTC)
open-file and fd->*port Lassi Kortela (10 Sep 2020 16:05 UTC)
Re: open-file and fd->*port Duy Nguyen (10 Sep 2020 16:15 UTC)
Re: open-file and fd->*port Shiro Kawai (10 Sep 2020 17:33 UTC)
Re: open-file and fd->*port Duy Nguyen (10 Sep 2020 17:40 UTC)
Re: open-file and fd->*port John Cowan (10 Sep 2020 18:18 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 16:29 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 16:33 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 16:42 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 16:57 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 17:08 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 17:21 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 17:34 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 17:37 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 17:36 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 17:50 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 18:10 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 18:40 UTC)
Re: Remove file descriptors completely from srfi-170? Duy Nguyen (10 Sep 2020 18:48 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 18:52 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 19:01 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 19:12 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 19:07 UTC)
Re: Remove file descriptors completely from srfi-170? Lassi Kortela (10 Sep 2020 19:16 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 19:23 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 19:28 UTC)
Re: Remove file descriptors completely from srfi-170? Shiro Kawai (10 Sep 2020 19:57 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (10 Sep 2020 20:02 UTC)
Re: Remove file descriptors completely from srfi-170? Shiro Kawai (10 Sep 2020 20:13 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 20:19 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (10 Sep 2020 20:49 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (11 Sep 2020 13:19 UTC)
Re: Remove file descriptors completely from srfi-170? hga@xxxxxx (11 Sep 2020 14:03 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (11 Sep 2020 14:56 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (11 Sep 2020 15:31 UTC)
Re: Remove file descriptors completely from srfi-170? John Cowan (10 Sep 2020 20:18 UTC)
Re: Remove file descriptors completely from srfi-170? Marc Nieper-Wißkirchen (11 Sep 2020 13:49 UTC)
R7RS scope & yearly editions Lassi Kortela (11 Sep 2020 14:10 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 14:22 UTC)
Re: R7RS scope & yearly editions Lassi Kortela (11 Sep 2020 14:26 UTC)
Re: R7RS scope & yearly editions hga@xxxxxx (11 Sep 2020 14:30 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 14:47 UTC)
Re: R7RS scope & yearly editions & language interop Lassi Kortela (11 Sep 2020 15:20 UTC)
Re: R7RS scope & yearly editions & language interop Marc Nieper-Wißkirchen (11 Sep 2020 15:28 UTC)
Re: R7RS scope & yearly editions & language interop John Cowan (11 Sep 2020 17:11 UTC)
Language interop Lassi Kortela (11 Sep 2020 17:55 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 18:04 UTC)
Re: Language interop Lassi Kortela (11 Sep 2020 18:14 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 18:28 UTC)
Re: Language interop hga@xxxxxx (11 Sep 2020 18:50 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:28 UTC)
Re: Language interop hga@xxxxxx (11 Sep 2020 21:00 UTC)
Re: Language interop Marc Nieper-Wißkirchen (12 Sep 2020 07:26 UTC)
Re: Language interop Lassi Kortela (11 Sep 2020 19:17 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:38 UTC)
Re: Language interop John Cowan (11 Sep 2020 20:50 UTC)
Re: Language interop hga@xxxxxx (11 Sep 2020 18:30 UTC)
Re: Language interop John Cowan (11 Sep 2020 19:45 UTC)
Re: Language interop Marc Nieper-Wißkirchen (11 Sep 2020 20:15 UTC)
Re: Language interop John Cowan (11 Sep 2020 19:42 UTC)
Re: R7RS scope & yearly editions hga@xxxxxx (11 Sep 2020 15:34 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 15:56 UTC)
Interlisp and structural code editing Lassi Kortela (11 Sep 2020 17:45 UTC)
Re: Interlisp and structural code editing John Cowan (11 Sep 2020 20:16 UTC)
Re: R7RS scope & yearly editions John Cowan (11 Sep 2020 16:57 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 17:23 UTC)
Re: R7RS scope & yearly editions John Cowan (11 Sep 2020 20:31 UTC)
Re: R7RS scope & yearly editions Arthur A. Gleckler (12 Sep 2020 17:39 UTC)
Re: R7RS scope & yearly editions John Cowan (11 Sep 2020 16:39 UTC)
Re: R7RS scope & yearly editions Marc Nieper-Wißkirchen (11 Sep 2020 17:01 UTC)
Re: R7RS scope & yearly editions Lassi Kortela (11 Sep 2020 17:15 UTC)

Re: open-file and fd->*port Duy Nguyen 10 Sep 2020 16:15 UTC

On Thu, Sep 10, 2020 at 11:05 PM Lassi Kortela <xxxxxx@lassi.io> wrote:
>
> >>> Why not combine open-file and
> >>> fd->*port in one? All other procedures either take pathname or a port.
> >>
> >> POSIX open() takes a whole bunch of flags which are relevant when
> >> opening a pathname and don't have much to do with converting an
> >> already-existing fd to a Scheme port.
> >> <https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html>
> >
> > So the new open-file also takes a bunch of flags and returns a port.
> > Since there's no way for you to get hold of an fd in the first place
> > (unless you count on special numbers 0, 1 and 2), converting an
> > already-existing fd to a Scheme port is a moot point.
>
> A child process using a known fd number (e.g. 3) from its parent (or
> from its predecessor before execve()) is a good convention for IPC.
> Hence it ought to be a useful feature to open a known fd as a Scheme port.

Yes. We can deal with that when we flesh out process management SRFI.
Until we know exactly the interface we have it may be premature to
introduce fd-based API.

> If some C API outside SRFI 170 returns an fd, being able to turn that
> into a Scheme port is also good.

I'm not concerned about FFI. If they can provide FFI, they can provide
wrappers to make a port out of it (and deal with fd management
themselves).

> If open-file takes an integer (giving the fd) how would it interpret its
> flags argument?

open-file (as the combination of an existing open-file and fd->*port)
just does not take a number, only paths.
--
Duy