From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Permanently fix org versioning breakage during builds? Date: Mon, 25 Dec 2023 18:24:42 +0000 Message-ID: <87r0jam979.fsf@localhost> 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="34665"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "T.V Raman" , emacs-devel To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 25 19:22: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 1rHpav-0008lD-Ep for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Dec 2023 19:22:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHpaC-0000yQ-4Z; Mon, 25 Dec 2023 13:21:44 -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 1rHpa9-0000yC-4L for emacs-devel@gnu.org; Mon, 25 Dec 2023 13:21:41 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rHpa6-0000XV-Mq for emacs-devel@gnu.org; Mon, 25 Dec 2023 13:21:40 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 25AEB240101 for ; Mon, 25 Dec 2023 19:21:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703528496; bh=pUBtIk/EdveLNAaWGTU8Ex2WYoa1MxDgsOnOvHWjpFU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version: Content-Transfer-Encoding:From; b=n0/mWJta3pboFhEelCKAHg/R4A3V0KCTfKOcPvGyCG9lRzo1KVsvtcWB5bcseVcBv C/qfTbxtQNP08ZtyYQZzF+3HfQ3fBeDweE4vsB1JlJNRL1Lg1SIyLplmJk4SDm+W/n vzg33hy44bgdiY6Vbid7NGgcjEgOVgfnA9g54hI1GobeozbaxS3/CR2OERueCvK1xN EVq2byelbiTt3vyALC5SinnkhLWlzFXfZvVNR7HOtKDaoxLChKN8lbLajYbCbuKSI9 +xMgJZVqmRi9H7UAdp3zKcCworYUBelLJU4bDDdCTkWpT3nBcO4sOlEnGwoXFQdZoJ SkTLnPvZbYIlw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4SzR7M1sSBz9rxF; Mon, 25 Dec 2023 19:21:35 +0100 (CET) In-Reply-To: Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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:314213 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > (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. I now tried to change `org-with-wide-buffer' to use funcall and I now agree with you that performance degradation is not visible. >> - 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. By "non-trivial to solve" I meant that solving it would require introducing 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 confus= ing > to see you reject a solution to a given real problem just because it > doesn't solve another completely different one. That's not what I meant. What I meant is that Org mode solving stale macro problem in Org code will not fix broken Emacs builds - they can still be broken because of other macros elsewhere in Emacs tree. And Emacs maintainers told me that there is no plan to address stale macros issue in Emacs tree - users are expected to run make bootstrap or similar commands in case of breakage. So, unless there is some _additional_ benefit for Org mode, I see no point spending my time to solve stale macro problem just in Org mode. Such additional benefit could be solving the mixed version problem, but, unfortunately, mixed version problem is not about macros. >> - 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... If Emacs maintainers say that it is ok, I do not see why I should try to solve it just for Org mode. > And what maintenance burden. It's much easier to write macros > like this. No hygiene concerns, no awkward ',foo' everywhere. What you described is not how Elisp manual suggest to write macros and not what people usually submit in patches. If I decide to follow your suggestion, we will need to maintain an extra rule about macro style - I (and other Org mode maintainers) will have to watch for this yet another extra thing. Hence maintenance burden. >> - 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= given > you hard data. Read it. I agree that this argument is incorrect. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at