From: Drew Adams <drew.adams@oracle.com>
To: Arthur Miller <arthur.miller@live.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: Sat, 17 Oct 2020 14:18:19 -0700 (PDT) [thread overview]
Message-ID: <d3fc6d5f-53d6-43be-b722-a24cffab9e7a@default> (raw)
In-Reply-To: <VI1PR06MB45269D5A56CE7FEC5FDCFC1796000@VI1PR06MB4526.eurprd06.prod.outlook.com>
> > 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.
next prev parent reply other threads:[~2020-10-17 21:18 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 [this message]
2020-10-17 22:06 ` Arthur Miller
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d3fc6d5f-53d6-43be-b722-a24cffab9e7a@default \
--to=drew.adams@oracle.com \
--cc=arthur.miller@live.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).