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:23:17 +0000 Message-ID: References: <25989.50971.995591.385250@google.com> <87a5q0dc9m.fsf@localhost> <87y1djc1c9.fsf@localhost> <87zfxzdbna.fsf@yahoo.com> <87plyv7oii.fsf@localhost> <8734vr4prv.fsf@localhost> <835y0nd4ut.fsf@gnu.org> <87zfxz35b4.fsf@localhost> <83v88nbgf3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d3dced060d49bc4c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21476"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Ihor Radchenko , Stefan Kangas , Po Lu , "T.V Raman" , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 25 00:24:45 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 1rHXps-0005S7-R5 for ged-emacs-devel@m.gmane-mx.org; Mon, 25 Dec 2023 00:24:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rHXoo-0004AT-HE; Sun, 24 Dec 2023 18:23:38 -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 1rHXon-0004AJ-6h for emacs-devel@gnu.org; Sun, 24 Dec 2023 18:23:37 -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 1rHXol-0000qT-C1; Sun, 24 Dec 2023 18:23:36 -0500 Original-Received: by mail-lj1-x230.google.com with SMTP id 38308e7fff4ca-2ccbf0169b5so4788241fa.2; Sun, 24 Dec 2023 15:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703460212; x=1704065012; 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=ZYtdeptnmK+dyKR5uMsuHFj9HAGG64yWcRHRaQ6oIcI=; b=e+Fik0R3xZLHcEYXH8Ek4Bcsv8N+/4pLIX0pjR98D7DdOnQF8Yk/Ug3CuT7NYzq032 HPXsE0oLpgJNGz2omiaDQF9paTco+AC4H4ziOx9wLvF79T3lXKeoDl36wN6FMRHeo5qj YTGfxvYf4TzGcHOMg2lEVVTJ49b8kXZFERtjI6/WtN5FeXTwKrLbQG3mcEpv2eQbgArC uE1A6XnW/wLBwVgxOBIDIEzsgrRDn/5eZ5vEq7he38YIaLyr5K3LRORGeZJrs7dTIXZY GiUYZlGIb8JEfyDGS6fgjRoTlOl65Cshgihdg/QS9C9UJwBVBjOxwR8t/zgL8qyfg+Qv gmlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703460212; x=1704065012; 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=ZYtdeptnmK+dyKR5uMsuHFj9HAGG64yWcRHRaQ6oIcI=; b=IQmIjFvpPQ5FXUSrdVkmgJd50DOsju5fp2Cw0PZXXYn3nTb+BL/yC55t55pbF372aO loMQzkE0W6ICYQXkO1iEToxcHTaUuKLVChwEnx+G97QKJrNd+FI67xXNt6EElnHKr7cW VB6O3GETJMHMamVX9icPGCc2R+xBxcB+V7/fwnddxj9LZa6vC82d0oWUn+09FguGPNbB cVnQfWro8riTXduVDOAX/o0Hr8rraLPsOPiXp9Fq7bWlqnbnWKgYDeJBlOl4+jSVKT/o X6MqGeIec6pMGUeHKKZlnt347jKAwJpIfETcmGzUjvQPgK0qbOQnuODSwR+fOAygHoqM 2wtQ== X-Gm-Message-State: AOJu0Yxs8VxIL+lmG2qRlUQUC+1pXTueB6O5J7oWZgj7HffOf589+N/3 r6FhoEfeimfgIZj53tTXBt0lRPF8HrDIkKa1b99uU+ft X-Google-Smtp-Source: AGHT+IFhDm2DFxbwCZnYWxhAW54GYSigr8d645SUfCTsy9q27B97ghAwGkE1/0qxq3x7tiVMGUNKRZVieL79yw9GZzw= X-Received: by 2002:a2e:8543:0:b0:2cc:8760:64db with SMTP id u3-20020a2e8543000000b002cc876064dbmr1191110ljj.96.1703460212037; Sun, 24 Dec 2023 15:23:32 -0800 (PST) In-Reply-To: <83v88nbgf3.fsf@gnu.org> 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, 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:314195 Archived-At: --000000000000d3dced060d49bc4c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 24, 2023, 18:32 Eli Zaretskii wrote: > > From: Ihor Radchenko > > Cc: stefankangas@gmail.com, luangruo@yahoo.com, raman@google.com, > > joaotavora@gmail.com, emacs-devel@gnu.org > > Date: Sun, 24 Dec 2023 16:59:11 +0000 > > > > Eli Zaretskii writes: > > > > > But such breakage happens at times anyway, when some macros change in > > > incompatible ways and files that have the old versions of those macro= s > > > compiled into them are not recompiled. It isn't anything new for > > > people who regularly update from Git and rebuild Emacs. > > > > The main problem is that with org-assert-version, "from time to time" > > becomes more frequent as the breakage is guaranteed every time a new > > version of Org is installed into Emacs tree. > > If org-assert-version is the source of breakage, then that's not the > breakage I was talking about. I was talking about breakage due to > changes in macros that were the motivation for you to introduce > org-assert-version in the first place. > > IOW, instead of _inducing_ a breakage via org-assert-version, you > should let stuff break by itself, when an incompatible change is made > in one of the macros which org-assert-version protects. > Exactly the point I was trying to make. org-assert-version shouldn't become part of the problem. The breakage due to incompatible changes can be tackled one by one, with certain programming techniques like the one I exemplified with real Org code, until they are eradicated or become very infrequent. I've used that technique tens if not hundreds of times. It's very effective for precisely this problem, which affects not only Emacs and Elisp but any large Lisp program. The efficiency argument levied against it only very rarely holds water. Jo=C3=A3o > --000000000000d3dced060d49bc4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Dec 24, 2023, 18:32 Eli Zaretskii <eliz@gnu.org> wrote:
> From: Ihor Radchenko <yantar92@posteo.net>= ;
> Cc: stefankangas@gmail.com, luangruo@yahoo.com, raman@google= .com,
>=C2=A0 joaotavora@gmail.com, emacs-devel@gnu.org
> Date: Sun, 24 Dec 2023 16:59:11 +0000
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > But such breakage happens at times anyway, when some macros chang= e in
> > incompatible ways and files that have the old versions of those m= acros
> > compiled into them are not recompiled.=C2=A0 It isn't anythin= g new for
> > people who regularly update from Git and rebuild Emacs.
>
> The main problem is that with org-assert-version, "from time to t= ime"
> becomes more frequent as the breakage is guaranteed every time a new > version of Org is installed into Emacs tree.

If org-assert-version is the source of breakage, then that's not the breakage I was talking about.=C2=A0 I was talking about breakage due to
changes in macros that were the motivation for you to introduce
org-assert-version in the first place.

IOW, instead of _inducing_ a breakage via org-assert-version, you
should let stuff break by itself, when an incompatible change is made
in one of the macros which org-assert-version protects.

Exactly the point I = was trying to make.

org-= assert-version shouldn't become part of the problem.

The breakage due to incompatible changes c= an be tackled one by one, with certain programming techniques like the one = I exemplified with real Org code, until they are eradicated or become very = infrequent.

I've use= d that technique tens if not hundreds of times. It's very effective for= precisely this problem, which affects not only Emacs and Elisp but any lar= ge Lisp program. The efficiency argument levied against it only very rarely= holds water.

Jo=C3=A3o<= /div>
--000000000000d3dced060d49bc4c--