From: Arthur Miller <arthur.miller@live.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: Eli Zaretskii <eliz@gnu.org>,
Michael Albinus <michael.albinus@gmx.de>,
emacs-devel@gnu.org
Subject: Re: empty-directory predicate, native implementation
Date: Sun, 18 Oct 2020 00:06:08 +0200 [thread overview]
Message-ID: <VI1PR06MB4526E0ED4765480468BDED4596000@VI1PR06MB4526.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <d3fc6d5f-53d6-43be-b722-a24cffab9e7a@default> (Drew Adams's message of "Sat, 17 Oct 2020 14:18:19 -0700 (PDT)")
Drew Adams <drew.adams@oracle.com> writes:
>> > Sorry I'm coming to this late. It's a long thread,
>> > and I've only checked your patch, not the messages.
>> >
>> > I don't understand why we would do this. Is the
>> > real aim to be able to have an empty-directory
>> > predicate, i.e., to be able to see if there are
>> > no files in a directory?
>>
>> Yes.
>>
>> > If so, then why not do just that, without
>> > bothering (changing the signature of)
>> > `directory-files'?
>>
>> Because it is not possible to that efficiently with current elisp; how
>> would you do that directly? OS does not have such call, one have to
>> iterate through directories. At least I am not aware of such call. If
>> you know, please tell me, I would be happy to use it, at least for myself.
>>
>> Fastest I am aware of is to get a buffered list with SYS_getdents and then
>> check for first non-dot file. That changes complexity from linear in
>> number of files in directory to constant (3 files at max). It works only
>> on Linux kernel, and I don't know if there is nt version of such call,
>> or what there is on macs.
>>
>> I suggested such predicate, but to not re-iterate entire discussion, pls
>> check my first mail and followed 2 or 3 I think.
>
> I took a quick look at the first few messages etc.
>
> I see that Eli suggested not implementing an
> empty-directory predicate directly but instead
> adding a COUNT parameter to `directory-files' (Lisp).
>
> That's just what I questioned. If the aim is an
> empty-directory pred then why not code it in C, like
> we do `directory-files'? And instead of duplicating
> code, if that would be the case, extend the C code
> underlying `directory-files' to be usable also for
> such a predicate, stopping as soon as it finds one
> file.
>
> IOW, what you've done, but not expose the COUNT
> parameter to Lisp. If its real purpose is just to
> check for emptiness, then from Lisp I'd think we'd
> have a separate predicate for that, and we wouldn't
> change the signature of `directory-files'.
>
> UNLESS there really IS some use for a COUNT value > 1.
>
> That was my question. If there's some use case, in
> Lisp, for COUNT, i.e., for returning the "first" N
> files, then fine. But if not, I don't see why we
> would add COUNT to `directory-files' (Lisp), as
> opposed to just getting the emptiness check from C
> (perhaps by adding a COUNT there, but not changing
> the Lisp interface for `directory-files').
>
> Not a big deal. Just a question; just something
> that occurred to me when I saw this. I think a
> Lisp user is likely to ask herself the same thing:
> apart from passing 1 for COUNT, why would I ever
> use COUNT?
>
> And if it were agreed that there's no use case for
> COUNT > 1, but for some reason a separate predicate,
> `directory-empty-p' isn't wanted, then change COUNT
> to a Boolean parameter that just says you want an
> emptiness check.
>
> If COUNT > 1 has no utility then, if you have to add
> a parameter for Lisp, its name, doc, and behavior
> should at least be more indicative of its purpose, no?
>
> Don't get me wrong. I'm generally in favor of Lisp
> Boolean functions and such that return useful non-nil
> truth values. I _really_ like that. But here I don't
> see the usefulness of the non-nil return value, which
> means the thing will confuse and mislead sometimes.
>
>> > Is there really some use case for getting only
>> > the first N files in a directory? I can
>> > understand wanting to test whether a dir is
>> > empty. I can't see why someone would want the
>> > first N files (however "first" might be defined).
>>
>> Probably not; it is just a result of having count parameter.
>
> Should be the other way round, no? We should have
> a COUNT parameter only if it's useful. If we're
> adding it just for implementation purposes, then why
> not just do that under the covers in the C code?
>
> Anyway, I don't mean to belabor this. I've asked
> my question and clarified why I asked.
Yeah, sure; I completely buy your reasoning. When I think of, one user
case for COUNT is maybe if a user have some kind of limited structure to
fill and just wish to taken N number of files. I don't know if that is
very common in Elisp, it's not directly a system programming lang, so I
think it is an artifical example.
next prev parent reply other threads:[~2020-10-17 22:06 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-13 2:22 empty-directory predicate, native implementation Arthur Miller
2020-10-13 8:01 ` Michael Albinus
2020-10-13 11:42 ` Arthur Miller
2020-10-13 13:16 ` Michael Albinus
2020-10-13 18:32 ` Arthur Miller
2020-10-13 18:39 ` Michael Albinus
2020-10-13 23:20 ` Arthur Miller
2020-10-14 9:19 ` Michael Albinus
2020-10-14 13:53 ` Arthur Miller
2020-10-13 14:48 ` Eli Zaretskii
2020-10-13 18:43 ` Arthur Miller
2020-10-13 19:12 ` Eli Zaretskii
2020-10-13 19:59 ` Arthur Miller
2020-10-14 14:08 ` Eli Zaretskii
2020-10-14 14:43 ` Arthur Miller
2020-10-13 18:44 ` Michael Albinus
2020-10-13 19:14 ` Eli Zaretskii
2020-10-13 20:08 ` Arthur Miller
2020-10-14 1:52 ` Arthur Miller
2020-10-14 9:21 ` Michael Albinus
2020-10-14 13:56 ` Arthur Miller
2020-10-14 14:41 ` Michael Albinus
2020-10-14 15:07 ` Arthur Miller
2020-10-14 15:53 ` Michael Albinus
2020-10-14 16:12 ` Eli Zaretskii
2020-10-14 16:21 ` Michael Albinus
2020-10-14 16:29 ` Eli Zaretskii
2020-10-15 5:53 ` Arthur Miller
2020-10-15 9:12 ` Michael Albinus
2020-10-15 11:33 ` Arthur Miller
2020-10-15 12:21 ` Michael Albinus
2020-10-15 13:29 ` Arthur Miller
2020-10-15 14:01 ` Arthur Miller
2020-10-15 14:41 ` Michael Albinus
2020-10-15 15:22 ` Arthur Miller
2020-10-16 23:31 ` Arthur Miller
2020-10-17 8:13 ` Michael Albinus
2020-10-17 19:03 ` Arthur Miller
2020-10-17 20:03 ` Drew Adams
2020-10-17 20:27 ` Arthur Miller
2020-10-17 21:18 ` Drew Adams
2020-10-17 22:06 ` Arthur Miller [this message]
2020-10-17 21:02 ` Arthur Miller
2020-10-17 21:27 ` Drew Adams
2020-10-17 21:58 ` Arthur Miller
2020-10-18 12:06 ` Michael Albinus
2020-10-18 2:47 ` Eli Zaretskii
2020-10-18 11:52 ` Michael Albinus
2020-10-18 16:15 ` Drew Adams
2020-10-18 16:43 ` Michael Albinus
2020-10-18 20:15 ` Stefan Monnier
2020-10-18 21:25 ` Drew Adams
2020-10-19 0:03 ` Arthur Miller
2020-10-18 22:21 ` Arthur Miller
2020-10-19 8:04 ` Michael Albinus
2020-10-19 14:01 ` Arthur Miller
2020-10-19 14:50 ` Michael Albinus
[not found] ` <VI1PR06MB45266BE5DFC72AEB27567A6C961E0@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <87a6wixoim.fsf@gmx.de>
[not found] ` <VI1PR06MB4526280D5B81531D06E58BC1961D0@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <87wnzev6i3.fsf@gmx.de>
[not found] ` <VI1PR06MB45264E1CB34EECE86672581C96100@VI1PR06MB4526.eurprd06.prod.outlook.com>
2020-11-02 17:02 ` Michael Albinus
2020-11-03 15:20 ` Arthur Miller
2020-10-15 13:38 ` Stefan Monnier
2020-10-16 23:33 ` Arthur Miller
2020-10-14 14:49 ` Arthur Miller
[not found] <<VI1PR06MB4526ACBABDE795DDD49A5A5896040@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<83y2ka18t7.fsf@gnu.org>
[not found] ` <<87y2kaj799.fsf@gmx.de>
[not found] ` <<83blh60wgr.fsf@gnu.org>
[not found] ` <<VI1PR06MB452688C9C71D5463D9497A2A96050@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<87h7qxjh7g.fsf@gmx.de>
[not found] ` <<VI1PR06MB45269B3924B44A555428F00596050@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<878sc8kgy8.fsf@gmx.de>
[not found] ` <<VI1PR06MB4526FDD3D3EB4867AF837C8F96050@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<87imbcls71.fsf@gmx.de>
[not found] ` <<83eem0zt0b.fsf@gnu.org>
[not found] ` <<87k0vsrd6m.fsf@gmx.de>
[not found] ` <<83a6wozs7h.fsf@gnu.org>
[not found] ` <<VI1PR06MB45267C7D83E77C3F307FF34E96020@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<87sgafq2e2.fsf@gmx.de>
[not found] ` <<AM6PR06MB4518BCD25B93987390D7D6D596020@AM6PR06MB4518.eurprd06.prod.outlook.com>
[not found] ` <<87h7qvptm3.fsf@gmx.de>
[not found] ` <<VI1PR06MB452605D66CDE84BAA25A257696030@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<871rhxp8we.fsf@gmx.de>
[not found] ` <<VI1PR06MB45261F3309D31EC7DEDE4C8B96000@VI1PR06MB4526.eurprd06.prod.outlook.com>
[not found] ` <<237bd21b-96c7-4433-a5bc-34b64a9f4250@default>
[not found] ` <<83ft6cs10u.fsf@gnu.org>
2020-10-18 4:05 ` Drew Adams
-- strict thread matches above, loose matches on Subject: below --
2020-10-18 21:13 Drew Adams
2020-10-18 22:15 ` Stefan Monnier
2020-10-19 7:54 ` Michael Albinus
2020-10-19 0:24 ` Arthur Miller
2020-10-19 0:37 ` Drew Adams
2020-10-19 2:15 ` Arthur Miller
2020-10-19 7:51 ` Michael Albinus
2020-10-19 15:25 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=VI1PR06MB4526E0ED4765480468BDED4596000@VI1PR06MB4526.eurprd06.prod.outlook.com \
--to=arthur.miller@live.com \
--cc=drew.adams@oracle.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=michael.albinus@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.