From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#61847: debug-early-backtrace only works some of the time. Date: Tue, 28 Feb 2023 14:45:42 +0000 Message-ID: References: <83fsaqgf2v.fsf@gnu.org> <837cw1hntl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34840"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 28 15:46:59 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pX1Fp-0008ol-WC for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 28 Feb 2023 15:46:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pX1FS-00028W-Ss; Tue, 28 Feb 2023 09:46:35 -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 1pX1Ez-00026X-HW for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2023 09:46:09 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pX1Ew-0000HE-TO for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2023 09:46:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pX1Ew-0001gk-Be for bug-gnu-emacs@gnu.org; Tue, 28 Feb 2023 09:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Feb 2023 14:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61847 X-GNU-PR-Package: emacs Original-Received: via spool by 61847-submit@debbugs.gnu.org id=B61847.16775955516460 (code B ref 61847); Tue, 28 Feb 2023 14:46:02 +0000 Original-Received: (at 61847) by debbugs.gnu.org; 28 Feb 2023 14:45:51 +0000 Original-Received: from localhost ([127.0.0.1]:50042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX1Ek-0001g8-Ma for submit@debbugs.gnu.org; Tue, 28 Feb 2023 09:45:51 -0500 Original-Received: from mx3.muc.de ([193.149.48.5]:21923) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX1Ej-0001ft-CJ for 61847@debbugs.gnu.org; Tue, 28 Feb 2023 09:45:50 -0500 Original-Received: (qmail 30057 invoked by uid 3782); 28 Feb 2023 15:45:43 +0100 Original-Received: from acm.muc.de (pd953a9ed.dip0.t-ipconnect.de [217.83.169.237]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 28 Feb 2023 15:45:42 +0100 Original-Received: (qmail 22048 invoked by uid 1000); 28 Feb 2023 14:45:42 -0000 Content-Disposition: inline In-Reply-To: <837cw1hntl.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:256972 Archived-At: Hello, Eli. On Tue, Feb 28, 2023 at 16:22:30 +0200, Eli Zaretskii wrote: > > Date: Tue, 28 Feb 2023 13:16:42 +0000 > > Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org > > From: Alan Mackenzie > > > It isn't clear to me why you consider code that uses prin1 to be "rock > > > solid by design". Please elaborate. > > I meant that the specific piece of code which was the original code > > (which happened to use prin1) was rock solid, not any other use of prin1. > > The original code didn't depend on any other lisp being loaded. Given > > how much can go wrong with loading Lisp in the early bootstrap in a > > version of Emacs being debugged, and which did go wrong in the bug > > scenario, I say we're better off not trying to use cl-prin1 at this > > stage. > If you think that the original code is solid because no Lisp is > loaded, then all it takes to break that is that someone rewrites prin1 > in Lisp. That seems unlikely, since the C code needs some way of outputting information before the Lisp even exists. > Which happened with quite a few primitives in recent years, and so it > can happen with prin1 as well. And if that does happen with prin1, > who will remember that this particular piece of code cannot stand > loading Lisp and will subtly break if that happens? I will remember it. It would break, not at all subtly. But you seem to be arguing that because something can't be 100% perfect, it shouldn't be improved. > So if this feature needs some precautions when loading Lisp, we had > better introduced those precautions now, and tested them with Stefan's > code which uses cl-prin1 to make sure it works. Why? The code doesn't need cl-prin1, that's just a source of errors, such as the one that happened. I've asked Stefan why cl-prin1's output is somehow more readable than straight prin1. > That way we will have a more future-proof feature. Not at all. The original debug-early was as future-proof as it's possible to get, and that was by deliberate design. The current buggy version, because of all the complexities of loading Lisp, is much less dependable. Even if some workaround is found, it will still be less dependable. Why do we want to use cl-prin1 here at all? It doesn't appear to have any advantages to offset its lack of dependability in early bootstrap. -- Alan Mackenzie (Nuremberg, Germany).