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
Lassi Kortela
(22 Apr 2020 21:36 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
Lassi Kortela
(22 Apr 2020 21:43 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
John Cowan
(23 Apr 2020 03:38 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
hga@xxxxxx
(22 Apr 2020 23:58 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:54 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:44 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:07 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:44 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:41 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:39 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:10 UTC)
|
Using paths that are searchable but not completely readable
hga@xxxxxx
(23 Apr 2020 12:30 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:14 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
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:46 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:42 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:21 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:42 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
John Cowan
(23 Apr 2020 18:38 UTC)
|
>> * current-directory (per-thread parameter) >> * os-current-directory (procedure - 0 args = getter, 1 arg = setter) >> >> * current-umask (per-thread parameter) >> * os-[current-]umask (procedure - 0 args = getter, 1 arg = setter) > > This works for me, but while using argument count would keep the > number of procedures the same, we're already using "set-*" as a convention > for changing state. It's true that set-* is more obvious, but parameter objects (SRFI 39) work such that the setter is the same as the getter. Since there seems to be agreement that the current directory should be implementable as a thread-local parameter, using a unified getter/setter procedure would be consistent with that. > I don't see see any need to include "current" in the umask procedure > names, current is implied, pretty much implied for all procedures like > this. Yeah, current-umask is a bit wordy. It would just be consistent with the others. Perhaps the "current" is superfluous. > I'm not sure about changing working-directory to > current-directory, the underlying POSIX procedure wide call getcwd > uses both.... Using both could be better, but if not that, I'd prefer > keeping working-directory. My argument is that all the other process/thread state stuff is called "current". The working directory is the only one that is called a "working" anything. (Does this imply everything else is "lazy"? :) Current-working would be two words for the same thing. "Working" in Unix doesn't refer to any other concept and is just a synonym for "current" AFAIK. The only other thing I can think of is "working set" and that's about CPU caches IIRC. >> IMHO "umask" is a bit cryptic and not applicable outside Unix. Could it >> be "unix-mask" instead, or simply "file-mask", "file-mode-mask", >> "file-permission-mask" or something? What's the equivalent on Windows? > > Well, this is a *POSIX* API, and as you noted in other emails, there's > no real mapping of POSIX's very simple permissions bits model to Windows. True. > Plus we'd expect some number of users of this API to already know > "umask", and I don't think the u mapps to UNIX. True as well. "u" probably means "user": <https://unix.stackexchange.com/questions/583296/what-does-the-letter-u-mean-in-umask>. But "unix" would make sense since the concept is only applicable under Unix. Then again, John prefers "posix" instead of "unix". So it could be "posix-mask" as well. > The meaning of the > bits is also inverted compared to the masks in file-info:mode and > set-file-mode, a 1 in the umask means "no you can't" create a file > with that bit, a 1 in the modes means "yes I am" set. It's inverted precisely because it's a mask for those other ones :)