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 23:11:15 +0000 Message-ID: References: <25989.50971.995591.385250@google.com> <87a5q0dc9m.fsf@localhost> <87edfbbyzm.fsf@localhost> <875y0n4px0.fsf@localhost> <87r0jb34hi.fsf@localhost> <878r5j31v0.fsf@localhost> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000acc2ad060d49911c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7681"; 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 00:12:29 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 1rHXe1-0001lX-46 for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Dec 2023 00:12:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHXd8-0001y1-4g; Sun, 24 Dec 2023 18:11:34 -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 1rHXd6-0001xr-ST for emacs-devel@gnu.org; Sun, 24 Dec 2023 18:11:32 -0500 Original-Received: from mail-lj1-x233.google.com ([2a00:1450:4864:20::233]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rHXd4-0007OH-W8 for emacs-devel@gnu.org; Sun, 24 Dec 2023 18:11:32 -0500 Original-Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2ccadec4b79so17173051fa.1 for ; Sun, 24 Dec 2023 15:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703459488; x=1704064288; 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=CmTBBTZdRMW/2shAB1nUMjqDFPWSJsiZnzP8cZkvdEI=; b=MkgI+CvxcU42KLUjJJpbaXpzuf+b1Q0aBmEFlVYlQFwgsPDIyekh0jpCmwzYwgucKv eVc3wI4FDCV/YZI5eiBZpcmoqV+4W1jWyqAA77j4Zhko7SAYxBnZIWVPEGeVkihytlFQ wq6v++88SBe3lfABthloq9Lj0j9G5rF5g2+3cBW9wPCLykemeXca+eJzWgCuv0GPDUm5 olmKyncQUF7rhBOSijv23YiJE0VY+tSp8OJNVAPQ18hqLcYRJuYEQhZKnWCFu5PRtynz ENI2+jwYm+36meWPJn2FbXPirm69diZmtKiVcbyBaeU96IkxRvZKA8g4lWpRFj7mR5Qj fw8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703459488; x=1704064288; 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=CmTBBTZdRMW/2shAB1nUMjqDFPWSJsiZnzP8cZkvdEI=; b=YEuJ1MtkfvWyFfSZy7g/JA9Rb/1Dv4XipJDM70e0fxLoGwbQkFvUIu4Pr76FOpn/Hz sbjcN28v+QIxqtaw1JMSzfg/DES6HfAsbu+HmHWWJsu9ebl+ia4kL1CU//aH/eDRoZ+D dwNSsxCchEzbCScqt9TBaLpBuVc2SmTCZFWT2YgcGnli7FuETIoTh2dYuXUmjBkAWtck Xm0JTLEFth824uf/4Rb6S/S0lDPCFkgoz6S86SRIwHCTn4p2zrwT4zQLTNOzsp+/utad DGdG9V8anI/5lZGexijR0Xb+sVujueHhlKU5KsTzLPW7PP8uID0qfhLsIUGKhRMVfthr tJvw== X-Gm-Message-State: AOJu0YwczG9iz5I4oaBXVUAj/uCvpM43XdBRHJdBn5NwZb0T4Wrgowl+ cA/rCW7jxCYaYU+puKrZ9Wu/ztUO25BlYj8GOnXWrmab X-Google-Smtp-Source: AGHT+IFy4PY+3SMXn+d4uL+veqfgtfs3X22Kv+DVzuewo0iA7r3uUElmr16C+7bRxsXwSmQs2tlr/rz9ZQgFqGIZg64= X-Received: by 2002:a2e:a4d1:0:b0:2cc:895c:5de5 with SMTP id p17-20020a2ea4d1000000b002cc895c5de5mr1968933ljm.83.1703459488054; Sun, 24 Dec 2023 15:11:28 -0800 (PST) In-Reply-To: <878r5j31v0.fsf@localhost> Received-SPF: pass client-ip=2a00:1450:4864:20::233; envelope-from=joaotavora@gmail.com; helo=mail-lj1-x233.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:314193 Archived-At: --000000000000acc2ad060d49911c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 24, 2023 at 6:10=E2=80=AFPM Ihor Radchenko wrote: > > Jo=C3=A3o T=C3=A1vora writes: > >> > [ Tangent: one thing I notice is that the expansion in ox-html.el i= s > >> > buggy. It evaluates the keyword arguments to the macros multiple times > >> > for no effect. The solution would be to change the macro calling > >> > convention to be: > >> > > >> > (cl-defmacro org-export-with-buffer-copy ((&key to-buffer drop-visibility > >> > drop-narrowing drop-contents > >> > drop-locals > >> > &allow-other-keys) &body body) > >> > ...) > >> > >> May you elaborate? > > > > Just expand the macro as in ox-html.el and see for yourself. > > Hmm... It actually looks like a problem with `cl-defmacro' rather than > with macro definition itself. No, Common Lisp's DEFMACRO works exactly like this. You need to understand how &rest works with &key and &allow-other-keys. It _also_ keeps the keys. That's just how it works. > >> > `(org-export--call-with-buffer-copy (lambda () ,@body) > >> > >> AFAIU, this technique will prevent compiler optimizations, won't it? > > > > What compiler optimizations are you talking about? The only > > price to pay is an extra funcall. "We can solve any problem by > > introducing an extra level of indirection." The function compiled, > > where presumably the complicated optimization-worthy logic lies > > is still compiled. > > Any use of (funcall 'symbol ...) means that compiler is not able to know > the function slot of 'symbol at compile time, because it may change. > Hence, any optimization that relies upon knowing both the context of the > funcall and the internals of 'symbol will become impossible. It's not even a symbol that is in question. And whatever this function-calling, it is more than probably dwarved by the cost of the remaining macro expansion. If you were making, say, a sequence processing library it would have to be measured. But here I'm 99.9% sure there's no efficiency downside. Just in allocation costs alone, your macro creates buffers, copies things, etc and then there's the expanded body. Just fixing the bug I've found will more than pay for it likely. > And this will not solve the problem when Org files are loaded in mixture > from Emacs built-in version and from some other version (ELPA, manually > installed Org mode, etc). That is a different problem with a different solution, and it only affects those who update Org from ELPA. There are many problems in the world, you can't expect a single solution to fix them all. That other problem, for example, has nothing to do with macro expansion site recompilation. I'm only targeting _that_ one for now, because that is what directly affects developers or anyone working with an Emacs from master. Jo=C3=A3o --000000000000acc2ad060d49911c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 24, 2023 at 6:10=E2=80=AFPM Ihor Radchenko &l= t;yantar92@posteo.net> wrote:
>
> Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.co= m> writes:

> >> > [=C2=A0 Tangent: one thing I notice is that the expansio= n in ox-html.el is
> >> > buggy.=C2=A0 It evaluates the keyword arguments to the m= acros multiple times
> >> > for no effect.=C2=A0 The solution would be to change the= macro calling
> >> > convention to be:
> >> >
> >> > (cl-defmacro org-export-with-buffer-copy ((&key to-b= uffer drop-visibility
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0drop-narrowing drop-contents
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0drop-locals
> >> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0&allow-other-keys) &body body)
> >> >=C2=A0 =C2=A0...)
> >>
> >> May you elaborate?
> >
> > Just expand the macro as in ox-html.el and see for yourself.
>
> Hmm... It actually looks like a problem with `cl-defmacro' rather = than
> with macro definition itself.

No, Common Lisp's DEFMACRO works exactly like this. You need to underst= and how &rest works with &key and &allow-other-keys. It _also_ = keeps the keys. That's just how it works.

> >> >=C2=A0 =C2=A0`(org-export--call-with-buffer-copy (lambda = () ,@body)
> >>
> >> AFAIU, this technique will prevent compiler optimizations, wo= n't it?
> >
> > What compiler optimizations are you talking about?=C2=A0 The only=
> > price to pay is an extra funcall.=C2=A0 "We can solve any pr= oblem by
> > introducing an extra level of indirection."=C2=A0 The functi= on compiled,
> > where presumably the complicated optimization-worthy logic lies > > is still compiled.
>
> Any use of (funcall 'symbol ...) means that compiler is not able t= o know
> the function slot of 'symbol at compile time, because it may chang= e.
> Hence, any optimization that relies upon knowing both the context of t= he
> funcall and the internals of 'symbol will become impossible.

It's not even a symbol that is = in question. And whatever this function-calling, it is more than probably d= warved by the cost of the remaining macro expansion. If you were making, sa= y, a sequence processing library it would have to be measured. But here I&#= 39;m 99.9% sure there's no efficiency downside. Just in allocation cost= s alone, your macro creates buffers, copies things, etc and then there'= s the expanded body. Just fixing the bug I've found will more than pay = for it likely.

> And this will not solve the problem when Org files are loaded in mixtu= re
> from Emacs built-in version and from some other version (ELPA, manuall= y
> installed Org mode, etc).

That is a different= problem with a different solution, and it only affects those who update Or= g from ELPA. There are many problems in the world, you can't expect a s= ingle solution to fix them all. That other problem, for example, has nothin= g to do with macro expansion site recompilation. I'm only targeting _th= at_ one for now, because that is what directly affects developers or anyone= working with an Emacs from master.

Jo=C3=A3o
--000000000000acc2ad060d49911c--