From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: [GNU ELPA] New package: tam Date: Wed, 20 Sep 2023 12:14:57 -0400 Message-ID: References: <87a5tjyg83.fsf@posteo.net> <87led39zyn.fsf@posteo.net> <87pm2d8d2w.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11716"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Sep 20 18:16:41 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qizsX-0002pk-Fy for ged-emacs-devel@m.gmane-mx.org; Wed, 20 Sep 2023 18:16:41 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qizrR-0006Pc-0p; Wed, 20 Sep 2023 12:15:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qizrK-0006Oo-My for emacs-devel@gnu.org; Wed, 20 Sep 2023 12:15:30 -0400 Original-Received: from mail-lj1-x231.google.com ([2a00:1450:4864:20::231]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qizr9-0004gl-Bh for emacs-devel@gnu.org; Wed, 20 Sep 2023 12:15:25 -0400 Original-Received: by mail-lj1-x231.google.com with SMTP id 38308e7fff4ca-2c123eed8b2so11862561fa.0 for ; Wed, 20 Sep 2023 09:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695226511; x=1695831311; darn=gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JslNzlNRPq6HHyCBbsVue6KyhkxcWN9WLXXOCIRcPCY=; b=TQOOL4NoJp+jL4W4UAlkah2z91e3GoE/ERWt4uYgvpfM0E51ajGdu6wAcv1oCqQihr bU1gGzSiyzKYeLba1JkJ1R8RJ5dIeYRjw8wkgu3f7W23Y56tTuXliNmWWZYfDiXnkfa7 hK185OXdzyZxVtk8HluPr1rWUmtMiCWQ1RJ+4yOLrZzs/Py1RZwRzVhS9RRwW4skpTZf ocT4W60nygUxgzf5p+wisTdXJRdUMIXaFPz5+yQ4RxVfj2CPOBqI7dWiuE2/fyDcYlYL rcOL+Bh759zuidWKaHvWtX2KjJv6mamHziM+3v8bESsoHuTA09hEMeydTqwUPFn5ph2a 5C/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695226511; x=1695831311; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JslNzlNRPq6HHyCBbsVue6KyhkxcWN9WLXXOCIRcPCY=; b=oW6iFFg3NC5WqUVQdq6QnepUZKuHghZZL2a7Xr6hOARlYM8425xfdSzdLkCoXocbhr magQqqUfKGo0OE9hqLn7jMuQvlpBLxB71ZDyN/8WcqMJVeRE2iWAARyATdrrbHMUwfS/ 7QuBT8dzro6Ew1S3s9ZasxEwQJxCrmV50ml/aaEbBdq4OpbZJkJd820PtNfxOoNMfeyw CCSVyqcdZK4NpFFIJgZfm4OkbvYLRmk6aUBsXzQwEQKZikAeIuKT0P6ApEYe2hCEo9vx k3eB4fZIHccYOkr5Rg/VUTBnL6tpfO71qNfvHJRvgA3BDtgQeTqWh8iQ+TN9UXt15UuZ KG0w== X-Gm-Message-State: AOJu0YwFsJ7rNrzeOdss0pfwHFSPunKRkpoIqDEQ2Nr0jTfydyznnEnB oclMglhdfUwgC3F7IIe01UGOcmIXw1ATyIzul/A= X-Google-Smtp-Source: AGHT+IGkdPegp3EWll2PDlTRtnPkBnXRsgkvfotwNoRaOZPUccfv5fVz7BX65dtPBoWDobOj/s0RAw6pYsav7XZBH44= X-Received: by 2002:a2e:9c93:0:b0:2bd:e3e:1a23 with SMTP id x19-20020a2e9c93000000b002bd0e3e1a23mr2450146lji.45.1695226511067; Wed, 20 Sep 2023 09:15:11 -0700 (PDT) In-Reply-To: <87pm2d8d2w.fsf@posteo.net> Received-SPF: pass client-ip=2a00:1450:4864:20::231; envelope-from=owinebar@gmail.com; helo=mail-lj1-x231.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:310844 Archived-At: On Wed, Sep 20, 2023 at 4:26=E2=80=AFAM Philip Kaludercic 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. > >> I am the kind of person who thinks twice about installing a package wh= en > >> 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. > > 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. > 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 (<=3D 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. > 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. Lynn