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 18:32 UTC

A quick reply to a couple of points; as of yet I have no strong
feelings or thoughts about the other points you're bringing up:

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

> Thanks for keeping us in the loop (and sorry for being the resident
> nitpicker).

You're welcome, and we're going to be living with this SRFI for a long
time even as it probably gets updated and superseded, we need to get
it as right as is reasonable.  And I have that tendency too, which
implementing another version of it reinforces.

> - I would always leave out dot and dot-dot from the
> [directory-files] results (the two directory entries that reference
> the current directory and the parent directory, respectively)....

That's the plan for directory-files, especially since if we're maybe
filtering out other dot files we might as well do dot and dot-dot.

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.

>[...]

>> Actually was thinking /[dir [dotfiles?]]/, not thinking that listing the
>> current working directory is going to be super common, and a user can
>> just put (working-directory) for /dir/ since we helpfully supply it.
>> But I have no strong feelings against discriminating on type, besides it
>> making the implementation significantly more complicated, since /[foo
>> [bar]]/ is dead simple with Chibi Scheme's let-optionals ... which
>> originally came from scsh....

>If listing the current directory by default is from scsh, it's probably
>for interactive use. When writing a script, I agree that it's not really
>a useful shortcut, and can confuse more than help.

It is, and I just found out its signature is [dir [dotfiles?]],
handing it only a non-string errors ... well, in the 0.7 version,
maybe that was one of the many changes made to the API.  I think there's
more examples of this, which I'm going to review the SRFI for.

>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.

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, modulo your points about it returning "too many" directory
entries.  Which can happen, people have abused UNIX file systems a lot,
requiring it to be very good at handling a ridiculous number of files in
any directory.  Usenet back in the day was the canonical example, typical
implementations stored the complete set of a topic's currently retained
postings in a single directory, one file per posting.

- Harold