From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Permanently fix org versioning breakage during builds? Date: Mon, 25 Dec 2023 18:42:47 +0100 Message-ID: References: <25989.50971.995591.385250@google.com> <87a5q0dc9m.fsf@localhost> <87edfbbyzm.fsf@localhost> <875y0n4px0.fsf@localhost> <87r0jb34hi.fsf@localhost> <878r5j31v0.fsf@localhost> <87edfao035.fsf@localhost> 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="10654"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "T.V Raman" , emacs-devel To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 25 18:43:48 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 1rHozT-0002ci-Vm for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Dec 2023 18:43:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHoyl-0003DC-RA; Mon, 25 Dec 2023 12:43:03 -0500 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 1rHoyk-0003BR-O1 for emacs-devel@gnu.org; Mon, 25 Dec 2023 12:43:02 -0500 Original-Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rHoyi-00038D-VI for emacs-devel@gnu.org; Mon, 25 Dec 2023 12:43:02 -0500 Original-Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2ccce3bc472so1905561fa.1 for ; Mon, 25 Dec 2023 09:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703526179; x=1704130979; 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=ljkXb+5nmarAaxQPfomxD/PZspfEvlUksTQp68dYxFI=; b=fQwnUE5ZnHlaooOKt1zkw+qtqtI/DZg6DEtLa6pNXzOKlq2ypLGCDTKxph17n3QJnc u2hXU79+S5SG/c1Qpl9gEBSD13BtjxD8YMDk4HqhQvGc5ajisPA6KWmCOSlCfqP8e49A KSnevEElcV1ASpWX2vg8dyOlp1w+bX95mU632rAIzVm5b96QHegIJGjIs59/prU34B2n 6NBFWHJOnHtq00+2dIACKAK3pssFZXTo5DwP8ODfsc0KmlOYr4PMJkhWX9GwlVYXqIvh ZoWtyt5MeUu+VcD3y5vDREmKisNa1PX5+UXat6uQx1idKJbaLFDC36WmGEB64jQhkbo9 /T+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703526179; x=1704130979; 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=ljkXb+5nmarAaxQPfomxD/PZspfEvlUksTQp68dYxFI=; b=QBKAFbDC82qVne70KPk2ZmR2UGUCdihA5m7QMY9LE/CPooW60n55/QZhGTPwAUM1le J/OFWHLP34o/t3NDLQlrrCygclF4xq2XMkn7OlwlSC6vk9iwwZlETlZ8tkxh9pUZUac8 oVOEt+9DABOAJ22yq0enSFgfSES8g2EYrd2l9GCz40DBXf1xEQ7cUmOmmuF8vwqKPM2m zGZLoGSCCrQ8jSb7hIfj+pB2ojFlT8wMKXsaTCFVpoFkLYEUYH4qExL3l6W4VIfR/l// HLIWaohi3fdAAadbEqhSt7ae17sLzK/l+51IBfALoyQv1rtgLX0TAeeNikqHI6/QdCQa hkNw== X-Gm-Message-State: AOJu0YxAyB1vhPvoIamyKuFvjfvJt5QJ2QI7Zub6J4t/4eEXz1OExeCh GQ5GPOu3qefKYnLONYe51SNIgXRbBNP3TUIZ3S4= X-Google-Smtp-Source: AGHT+IGHu4GqGIN/hpRyyyc24wnTmVtdbK4IK/bsWDC53Di2xAd8IMWf3AeWVRxLSU2oaF2G1pUozvK6Jby3r8/aUDc= X-Received: by 2002:a2e:9907:0:b0:2cc:7174:48fb with SMTP id v7-20020a2e9907000000b002cc717448fbmr2359710lji.40.1703526178781; Mon, 25 Dec 2023 09:42:58 -0800 (PST) In-Reply-To: <87edfao035.fsf@localhost> Received-SPF: pass client-ip=2a00:1450:4864:20::230; envelope-from=joaotavora@gmail.com; helo=mail-lj1-x230.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, T_SCC_BODY_TEXT_LINE=-0.01 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:314212 Archived-At: On Mon, Dec 25, 2023, 13:55 Ihor Radchenko wrote: > I doubt that you are right about 99.9%, because I know that we have some > macros (like `org-with-wide-buffer') that are utilized in > performance-critical code - org-element-cache. You want to bet on it? You really do believe the cost of an indirect funcal= l outweighs multiple buffer allocations, plust whatever &rest body does? (require 'cl-lib) (defmacro joaot/progn (&rest body) `(progn ,@body)) (defmacro joaot/funcall (&rest body) `(joaot/with-funcall (lambda () ,@body))) (defun joaot/with-funcall (fn) (funcall fn)) (when nil (benchmark-run-compiled 100000 (joaot/progn (cons nil nil))) ;;(0.03082571 2 0.026723563000004447) ;;(0.030770479000000003 2 0.02662909699999716) ;;(0.030249778 2 0.02616808300000173) ;;(0.025063519000000003 2 0.021807326999997656) ;;(0.022791136 2 0.020065053000003275) (benchmark-run-compiled 100000 (joaot/funcall (cons nil nil))) ;;(0.028634259999999998 2 0.02006373300000064) ;;(0.028718769 2 0.020229722999999922) ;;(0.02806812 2 0.020030715000004307) ;;(0.025772916 2 0.017697210000001462) ;;(0.026947274 2 0.018522359999998628) (benchmark-run-compiled 100000 (joaot/progn (with-temp-buffer))) ;;(1.4586596770000002 179 1.2495902690000023) ;;(1.434278908 179 1.228926580999996) ;;(1.444412169 179 1.2385162100000002) ;;(1.445273846 179 1.2392989229999998) ;;(1.464507893 179 1.2581699959999995) (benchmark-run-compiled 100000 (joaot/funcall (with-temp-buffer))) ;;(1.4344190810000002 179 1.223486917999999) ;;(1.418460156 179 1.211255973) ;;(1.449469906 179 1.232802902000003) ;;(1.419341703 179 1.2082177509999994) ;;(1.517436337 179 1.2952383430000012) The time is completely dominated by allocation and garbage collection. A single cons allocation per macroexpansion is enough to make the difference unmeasurable. In fact, to be able to measure it, you'll have to make body completely empty and run it tens of milions of iterations to be able to measure anything perceivable in the tenths of a second. > And it is not the only concern why I do not feel that your suggestion is > a good idea: > > - The problem with stale macros is not just Org mode's problem - it is > the problem with Elisp compiler machinery. A very hard one that is > non-trivial to solve. It doesn't have a solution! It's just what macros give you: syntax manipulation in exchange for late binding. You must add functions back to regain Lisp's late binding and deal with Lisp's build systems which don't usually let you specify dependencies between files. > - The rest of Emacs just leaves the problem with macros as is and the > only reason why Org mode touched it is that it was simply a side > effect of how org-assert-version is implemented - it is first and > foremost aiming at handling the issue with multiple Org mode versions > being loaded at the same time, while the side effect of detecting > stale macros was a bonus. > > - Even if I solve the problem with macros using the technique you > proposed, the problem with mixed versions still has to be handled. I've already explained that is a different other for people who use ELPA & git to track bleeding edge. It has another solution. It's very confusin= g to see you reject a solution to a given real problem just because it doesn't solve another completely different one. > - Further, fixing the stale macro problem means rewriting all the > existing, and, more importantly, future Org mode macros - an extra > maintenance burden which I am very hesitant to take. So you'd rather bother everyone else with broken builds... And what maintenance burden. It's much easier to write macros like this. No hygiene concerns, no awkward ',foo' everywhere. > - And that maintenance burden also comes with an additional downside of > potential performance degradation. This bullet is a repeat / filler. Fallacious argument with no data. I've g= iven you hard data. Read it. > So, all-in-all, I do not see the idea with wrapped macros as something > practical for Org mode. I tried my best. Repeatedly in this argument you have made erroneous statements and logically fallacies. And when I correct them, you just came back whit some more. I have handed you a solution on a plate to fix a real problem, and you drag your feet so it can stay "your solution". Can't beat hubris. Good luck. Jo=C3=A3o