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: Sun, 24 Dec 2023 14:13:26 +0000 Message-ID: References: <25989.50971.995591.385250@google.com> <87a5q0dc9m.fsf@localhost> <87edfbbyzm.fsf@localhost> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004f145e060d420e1e" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23362"; 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 Sun Dec 24 15:14:20 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 1rHPFB-0005gQ-HZ for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Dec 2023 15:14:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHPEj-0000ac-8l; Sun, 24 Dec 2023 09:13:49 -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 1rHPEd-0000aO-KO for emacs-devel@gnu.org; Sun, 24 Dec 2023 09:13:43 -0500 Original-Received: from mail-lj1-x22c.google.com ([2a00:1450:4864:20::22c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rHPEb-0006de-D9 for emacs-devel@gnu.org; Sun, 24 Dec 2023 09:13:43 -0500 Original-Received: by mail-lj1-x22c.google.com with SMTP id 38308e7fff4ca-2ccbaea0a6cso6682281fa.2 for ; Sun, 24 Dec 2023 06:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703427219; x=1704032019; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=46BNbOA16w75FeJGs7j3Z8hKd3CaG20zIbUCjlpOtCs=; b=W17Jq8LVqJeU8YDTSRJKn/fLhCZZc+xIe95W67tAOVyWULAa2IT09to0wzMUgSO11Q Nu/j1uC9YB/FAnko/Gr6GJJUOJ88iNBk8t+0c+COzYj46HV/MNlRFUKu4Jv7Ki1ubvXD /2+lLNB9VvPJXY28S+pycEBjdhuD08DkASfDOH4RzT/RTSd62Vy9CtF8ZJusiyRyd4JZ 6uJU0Vh+35huIF3xhWDjzQUzGKmTgKJVvboxIyG/mo/E3N6wSNQMGa5vEzwgC+3tV4km LaB0Vtqa9NAZYFdE1oyMdVg+BLWCAqnSYP79B5tXxc9rC1VRrhKUymJdEGxz8p4zTp8m tsHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703427219; x=1704032019; h=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=46BNbOA16w75FeJGs7j3Z8hKd3CaG20zIbUCjlpOtCs=; b=hl5V1NGYjvdoEoAQfBvQ+uXDOh5lNEYAyBvpzbeYa+Px1L3nIRs5SVAvtMpOrAUQtv rSiIgRUMr5O0Rt8aHJb7bOCHzM7iHFfEOt9Gw25hm4VYoIHIngks5OqwQIxrS8Epl/um q9bTAPjt1XkYHobCqjFO7qzfbwOM8VcT7vGd4IqmL2aeZpYmp7vY1hUVXTDDz0ySF8LV r2PBrvJ/fiPiNxStULhS1xkXG8uA+yxYpwrKitJY1eHBmgGJpYdNAo77A0PDWMMja/YN zFEAi0xYWU0uozz/ftWNwz+68WVKAyXpHQYXdyj2/Wi9qckZv+7hb28yrbhxgiOLTDx6 XGBQ== X-Gm-Message-State: AOJu0YzFbt08pnjbAShpztYwP41TTbeykCQQWjkvx7/vsNCUbEN/2t+J mSuWA60+tsDhMNC2HcM5zFVbfD83ibQqypZZFic= X-Google-Smtp-Source: AGHT+IG5vTvSFDR/awIaxgepEuR+PN6+T3SH+l/bOMexLqP/Rmi2X6uzmTds1LuNt3pCL+3tUduCoSGsz6iVcBhoVH0= X-Received: by 2002:a2e:150a:0:b0:2ca:1d5d:e944 with SMTP id s10-20020a2e150a000000b002ca1d5de944mr1418912ljd.106.1703427219328; Sun, 24 Dec 2023 06:13:39 -0800 (PST) In-Reply-To: <87edfbbyzm.fsf@localhost> Received-SPF: pass client-ip=2a00:1450:4864:20::22c; envelope-from=joaotavora@gmail.com; helo=mail-lj1-x22c.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, HTML_MESSAGE=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:314126 Archived-At: --0000000000004f145e060d420e1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 24, 2023, 11:47 Ihor Radchenko wrote: > Jo=C3=A3o T=C3=A1vora writes: > > >> May you elaborate? > >> > > > > I have already elaborated a while back, but on a tangent deep down in a > > thread and I'm on my phone right now. So maybe these links would give y= ou > > an idea of what it looks like. > > > > http://random-state.net/log/3390120648.html > > > https://www.reddit.com/r/Common_Lisp/comments/okvgf0/examples_of_callwith= _style_in_macros/ > > https://news.ycombinator.com/item?id=3D12476032 > > > > These are all common lisp related, but there are, I'm fairly sure, > numerous > > examples in Elisp, though not necessarily named "call-with". Let me kno= w > > what you understand of the examples before we continue. > > I do not think that your idea will work. > What you propose is compiling `org-assert-version' once. > Hmm? How can that be what I'm proposing if I didn't even know about this definition. Is it a form, a macro? What ultimate problem is it solving? What condition do you need to assert at Emacs master build-time, failing which something else will go wrong? I just provided ideas on how to solve a very common build-time pitfall in Lisp. A pitfall that can be solved by requiring a recompilation of everything, as seems to be the current way, or in other less brutal ways. Keep in mind something in the build system is causing builds to fail with cryptic messages even for people who don't use Org or rarely ever do. I've never touched any Org related files in my life, why should it blow up in my face? Of course happens to all package maintainers but usually there is a fix. There should be one here, too. > You may also want to elaborate yourself on an example of a macro that is > > emblematic of the expansion-site recompilation problem that, as I > contend, > > you fixed somewhat heavy-handedly and lead to these recurring irritatio= ns > > to many users. We can see if we can fix that example with with the > > technique I allude to. > > May you please try to explain what you mean in other words? I am not > sure what you are trying to convey in this paragraph. > Give me (us) an example of a defmacro form whose body is frequently changed and which requires the expanders of such a macro, which presumably live in other files, to be recompiled, even if said files haven't changed. --0000000000004f145e060d420e1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 24, 2023, 11:47 Ihor Radchenko <yantar92@posteo.net> wrote:
Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com> writes:

>> May you elaborate?
>>
>
> I have already elaborated a while back, but on a tangent deep down in = a
> thread and I'm on my phone right now. So maybe these links would g= ive you
> an idea of what it looks like.
>
> http://random-state.net/log/3390120648.html
> https://www.reddit.com/r/= Common_Lisp/comments/okvgf0/examples_of_callwith_style_in_macros/
> https://news.ycombinator.com/item?id=3D12476032
>
> These are all common lisp related, but there are, I'm fairly sure,= numerous
> examples in Elisp, though not necessarily named "call-with".= Let me know
> what you understand of the examples before we continue.

I do not think that your idea will work.
What you propose is compiling `org-assert-version' once.

Hmm? How can th= at be what I'm proposing if I didn't even know about this definitio= n. Is it a form, a macro?

What ultimate problem is it solving? What condition do you need to assert= at Emacs master build-time, failing which something else will go wrong?

I just provided ideas on h= ow to solve a very common build-time pitfall in Lisp. A pitfall that can be= solved by requiring a recompilation of everything, as seems to be the curr= ent way, or in other less brutal ways.

Keep in mind something in the build system is causing builds= to fail with cryptic messages even for people who don't use Org or rar= ely ever do. I've never touched any Org related files in my life, why s= hould it blow up in my face? Of course happens to all package maintainers b= ut usually there is a fix. There should be one here, too.

> You may also want to elaborate yourself on an example of a macro that = is
> emblematic of the expansion-site recompilation problem that, as I cont= end,
> you fixed somewhat heavy-handedly and lead to these recurring irritati= ons
> to many users. We can see if we can fix that example with with the
> technique I allude to.

May you please try to explain what you mean in other words? I am not
sure what you are trying to convey in this paragraph.

Give me (us) an exampl= e of a defmacro form whose body is frequently changed and which requires th= e expanders of such a macro, which presumably live in other files, to be re= compiled, even if said files haven't changed.

--0000000000004f145e060d420e1e--