Quick question about SRFI-170 directory-files hga@xxxxxx 29 Jul 2019 15:46 UTC
(missing)
(missing)
Re: Quick question about SRFI-170 directory-files hga@xxxxxx 29 Jul 2019 17:08 UTC
Re: Quick question about SRFI-170 directory-files Lassi Kortela 29 Jul 2019 17:42 UTC
Re: Quick question about SRFI-170 directory-files Lassi Kortela 29 Jul 2019 17:51 UTC
Re: Quick question about SRFI-170 directory-files Lassi Kortela 29 Jul 2019 18:02 UTC
Re: Quick question about SRFI-170 directory-files Lassi Kortela 29 Jul 2019 18:15 UTC
Put directory-fold in the SRFI? hga@xxxxxx 29 Jul 2019 18:45 UTC
Re: Put directory-fold in the SRFI? John Cowan 29 Jul 2019 19:38 UTC
Re: Quick question about SRFI-170 directory-files John Cowan 29 Jul 2019 20:26 UTC
Re: Quick question about SRFI-170 directory-files Marc Feeley 29 Jul 2019 18:28 UTC
Re: Quick question about SRFI-170 directory-files Lassi Kortela 29 Jul 2019 18:31 UTC
Re: Quick question about SRFI-170 directory-files Marc Feeley 29 Jul 2019 18:46 UTC
Re: Quick question about SRFI-170 directory-files Lassi Kortela 29 Jul 2019 18:57 UTC
Re: Quick question about SRFI-170 directory-files Marc Feeley 29 Jul 2019 19:04 UTC
Re: Quick question about SRFI-170 directory-files hga@xxxxxx 29 Jul 2019 18:32 UTC
Re: Quick question about SRFI-170 directory-files Lassi Kortela 29 Jul 2019 18:51 UTC
Re: Quick question about SRFI-170 directory-files hga@xxxxxx 29 Jul 2019 19:16 UTC
Re: Quick question about SRFI-170 directory-files John Cowan 30 Jul 2019 18:52 UTC
Re: Quick question about SRFI-170 directory-files hga@xxxxxx 30 Jul 2019 19:58 UTC
Re: Quick question about SRFI-170 directory-files John Cowan 30 Jul 2019 20:44 UTC
Outstanding issue: directory-files in the context of huge directories hga@xxxxxx 03 Sep 2019 21:03 UTC
(missing)
Fwd: Outstanding issue: directory-files in the context of huge directories John Cowan 04 Sep 2019 12:20 UTC
Re: Outstanding issue: directory-files in the context of huge directories Marc Feeley 04 Sep 2019 12:31 UTC
Re: Outstanding issue: directory-files in the context of huge directories John Cowan 04 Sep 2019 13:56 UTC
Re: Outstanding issue: directory-files in the context of huge directories Marc Feeley 04 Sep 2019 14:08 UTC
make-directory-files-generator hga@xxxxxx 06 Sep 2019 16:21 UTC
Re: make-directory-files-generator hga@xxxxxx 06 Sep 2019 17:24 UTC
(missing)
Re: make-directory-files-generator hga@xxxxxx 06 Sep 2019 21:56 UTC
Re: Outstanding issue: directory-files in the context of huge directories Lassi Kortela 04 Sep 2019 11:46 UTC
Re: Outstanding issue: directory-files in the context of huge directories Lassi Kortela 04 Sep 2019 11:52 UTC
Re: Outstanding issue: directory-files in the context of huge directories hga@xxxxxx 04 Sep 2019 12:13 UTC
Re: Outstanding issue: directory-files in the context of huge directories Lassi Kortela 04 Sep 2019 12:26 UTC
Re: Outstanding issue: directory-files in the context of huge directories John Cowan 04 Sep 2019 12:30 UTC
Re: Quick question about SRFI-170 directory-files Lassi Kortela 29 Jul 2019 18:06 UTC

Re: Quick question about SRFI-170 directory-files hga@xxxxxx 29 Jul 2019 19:16 UTC

> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Monday, July 29, 2019 1:51 PM

> [...]

>> But one reason this comes up is that the raw POSIX open/read/closedir
>> syscalls *do* return dot and dot-dot, and I just made a LGTM (I hope)
>> change to the SRFI to have those functions be simple wrappers that
>> don't filter them out.  Lots of other interfaces keep them by default,
>> like Emacs dired mode.

> Simple wrappers are a noble goal, but this is an exception. I've been
> dealing with this problem for a decade in countless jobs and languages
> and including dot and dot-dot in the listing just slips in bugs.

This is a *strong* argument.  My philosophy, which is reflected in
the ordering of procedures in the SRFI, is to provide a convenient,
minimal foot-gun procedure like directory-files (and maybe we'll add
directory-fold) first, and below that raw wrappers.  In part because
I'm lazy and also want to minimize the work other SRFI implementors
will have to do, in part because UNIX programmers at this system level
are used to it (and for now I'm much more that than a Scheme
programmer, until this month not having programmed it in anger since
the early 1980s).

> I view them as similar to the EINTR thing - there's just no use case
> for manual dot-dot handling or EINTR and they lead to bugs.

EINTR is an artifact of squeezing Multics, which ran on full-fledged
36 bit asynchronous logic mainframes, into tiny DEC minicomputers where
user programs and the kernel all had to coexist.  Even 2.x BSD on split
I and D PDP-11s had to use overlays to support TCP/IP.

A bit like how IBM's political decision to eschew virtual memory
(which they called Dynamic Address Translation) was perhaps the
biggest *technical* factor in the OS/360 5 man millennia debacle.
Every module had a very fixed memory budget, and every module team
worked as hard as they could to make other modules responsible for
the memory they used.

> [...]

>>> But interactive use is so different that I wouldn't make that a priority
>>> for a general-purpose OS SRFI like this.

>> On the other hand, we want to make using the SRFI from the REPL as
>> convenient as possible.

> I think we're hitting the same problem that has plagued the Unix command
> line since its inception: interactive use is fundamentally different
> from script use. For example, "rename" overwriting the target file is
> find in a script, but generally not on the command line. Similarly, for
> interactive use, a (ls) procedure to list the current directory would be
> simpler.

Point, but the REPL, and the development workflows it encourages are
still one of the main advantages of LISPs.

> [...]

>> Since [dir [dotfiles?]] is dead simple, and we want to keep the SRFI
>> conforming to scsh as much as is reasonable, I'd like to keep the current
>> signature

> It's not dead simple when you ask "why filter out dotfiles specifically
> and not something else?"

Another good point, this makes the API more complicated to describe.
Although, I submit, not very complicated.

> [...]

- Harold