From: Philip Kaludercic <philipk@posteo.net>
To: Lynn Winebarger <owinebar@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: [GNU ELPA] New package: tam
Date: Thu, 21 Sep 2023 16:38:00 +0000 [thread overview]
Message-ID: <878r8zwkgn.fsf@posteo.net> (raw)
In-Reply-To: <CAM=F=bA-uF2_KQyYC4FMwo3PfBtNJvyHLWguE6tJTzNTtm=uvw@mail.gmail.com> (Lynn Winebarger's message of "Wed, 20 Sep 2023 12:14:57 -0400")
Lynn Winebarger <owinebar@gmail.com> writes:
> On Wed, Sep 20, 2023 at 4:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
>> Re your last change in [0], why use records directly instead of having
>> the code being generated via cl-defstruct? The commit messages doesn't
>> really explain your reasoning to me.
>
> The library is supposed to provide alloc/free functions that run in
> O(1) time to the extent that is possible for emacs-lisp code, for use
> in process sentinels and similar situations. I took a look at the
> byte-code generated for those two functions when using the
> cl-defstruct definitions, and the accessors and setters were not
> inlined. Aside from the unknown complexity of invoking those
> functions, every call has a risk of overflowing the current stack and
> requiring an additional stack segment be allocated.
>
> I rewrote the code so the only appearances of the call operator in the
> byte-code of those functions is for error signaling. I also provide
> an inlining version of each operation so library clients can avoid
> call instructions in their code.
From what I understand this situation was resolved in the other
subthread, right?
>> >> I am the kind of person who thinks twice about installing a package when
>> >> it has dependencies. But if you prefer to use a package available on
>> >> ELPA, then that is of course OK as well.
>
> BTW, there's something ironic about this, since you actually appear to
> review most packages on GNU/NonGNU ELPA - how many users would be more
> familiar with the packages that might be installed from those
> archives?
> At any rate, it does not depend on any packages, or even cl-lib, now -
> though I have to revise the header to say so.
I don't know if this is ironic or not, I just don't like having too many
packages installed in general? As I said, this is my personal taste and
I am not forcing this onto anyone.
>>
>> The question was supposed to be more general, sorry for the confusion.
>> I wanted to know if there was a reason you were using setf even when
>> setq would be enough, but it really doesn't matter either way since setf
>> on a symbol expands directly to setq.
>
> If I had setf on a symbol, it was a typo. They are all gone now,
> since they did not get optimized out.
OK.
>> No, it uses nreverse:
>>
>> --8<---------------cut here---------------start------------->8---
>> (macroexpand-all '(cl-loop for i to 10 collect i))
>> (let* ((i 0) (--cl-var-- nil))
>> (while (<= i 10)
>> (setq --cl-var-- (cons i --cl-var--))
>> (setq i (+ i 1)))
>> (nreverse --cl-var--))
>> --8<---------------cut here---------------end--------------->8---
> Blech, I replaced it with a simple function.
Another idea could be using mapcan, but usually requires calling a
lambda expression -- at which point we have firmly reached the territory
of micro-optimisation, and it makes no sense to progress any further
without some substantial, empirical measurements and good technical
explanations behind the observations.
>> These kinds of arguments lead to leftpad like situations, where people
>> defer any slightly complicated functionality to a library. The last
>> thing I want to see when installing a package is that it drags along
>> dozens or even hundreds of recursive dependants, causing me to loose an
>> overview of what I have installed and what is being installed. Every
>> dependency a package brings with it (especially packages like dash &
>> co.) is an argument against using it, imo.
>
> I don't think the leftpad situation (which I had to look up) can
> happen on GNU ELPA. Even if, despite the FSF's precautions, something
> had to be removed, I'm sure there would be plenty of warning.
The point isn't so much that something gets removed (as you say, ELPA
plays the middle-man here by mirroring the repository contents), but
rather that a downstream bug or even a malicious change in a deep
dependency can cause much more harm, even if the inherent utility,
ie. need for the package in the first place was not that significant in
the first place.
> Lynn
next prev parent reply other threads:[~2023-09-21 16:38 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-18 2:28 [GNU ELPA] New package: tam Lynn Winebarger
2023-09-18 9:37 ` Philip Kaludercic
2023-09-18 16:22 ` Lynn Winebarger
2023-09-18 17:02 ` Philip Kaludercic
2023-09-19 15:38 ` Lynn Winebarger
2023-09-20 8:26 ` Philip Kaludercic
2023-09-20 16:14 ` Lynn Winebarger
2023-09-20 17:30 ` Stefan Monnier via Emacs development discussions.
2023-09-21 4:21 ` Lynn Winebarger
2023-09-21 13:59 ` Stefan Monnier
2023-09-22 3:01 ` Lynn Winebarger
2023-09-22 3:23 ` Stefan Monnier
2023-09-21 16:38 ` Philip Kaludercic [this message]
2023-09-18 19:26 ` Adam Porter
2023-09-19 15:48 ` Lynn Winebarger
2023-09-19 16:29 ` Adam Porter
2023-09-21 20:26 ` Richard Stallman
2023-09-22 19:45 ` Adam Porter
2023-09-20 16:06 ` Stefan Monnier
2023-09-20 16:44 ` Lynn Winebarger
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=878r8zwkgn.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=emacs-devel@gnu.org \
--cc=owinebar@gmail.com \
/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).