From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 27 12:12:19 2023 Received: (at submit) by debbugs.gnu.org; 27 Feb 2023 17:12:19 +0000 Received: from localhost ([127.0.0.1]:48686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWh2w-0006Ob-Rt for submit@debbugs.gnu.org; Mon, 27 Feb 2023 12:12:19 -0500 Received: from lists.gnu.org ([209.51.188.17]:36400) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWh2q-0006OM-JH for submit@debbugs.gnu.org; Mon, 27 Feb 2023 12:12:16 -0500 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 1pWh2q-0008SX-Bp for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2023 12:12:12 -0500 Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pWh2o-0004xc-8b for bug-gnu-emacs@gnu.org; Mon, 27 Feb 2023 12:12:12 -0500 Received: (qmail 76316 invoked by uid 3782); 27 Feb 2023 18:11:51 +0100 Received: from acm.muc.de (pd953acb4.dip0.t-ipconnect.de [217.83.172.180]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 27 Feb 2023 18:11:51 +0100 Received: (qmail 25386 invoked by uid 1000); 27 Feb 2023 17:11:51 -0000 Date: Mon, 27 Feb 2023 17:11:51 +0000 To: bug-gnu-emacs@gnu.org Subject: debug-early-backtrace only works some of the time. Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit Cc: Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hello, Emacs. In the master branch: Sometimes, instead of outputting a backtrace, debug-early throws an error, like the second line of: Error: cl-assertion-failed ((stringp typename)) Symbol's function definition is void: cl-defgeneric .. To reproduce this failure, apply the following patch to src/eval.c, then attempt a make bootstrap: diff --git a/src/eval.c b/src/eval.c index d42f7ffe894..8a88f5894b1 100644 --- a/src/eval.c +++ b/src/eval.c @@ -542,13 +542,13 @@ DEFUN ("function", Ffunction, Sfunction, 1, UNEVALLED, 0, && (EQ (QCdocumentation, XCAR (tmp)))) { /* Handle the special (:documentation
) to build the docstring dynamically. */ - Lisp_Object docstring = eval_sub (Fcar (XCDR (tmp))); - if (SYMBOLP (docstring) && !NILP (docstring)) - /* Hack for OClosures: Allow the docstring to be a symbol - * (the OClosure's type). */ - docstring = Fsymbol_name (docstring); - CHECK_STRING (docstring); - cdr = Fcons (XCAR (cdr), Fcons (docstring, XCDR (XCDR (cdr)))); + /* Lisp_Object docstring = eval_sub (Fcar (XCDR (tmp))); */ + /* if (SYMBOLP (docstring) && !NILP (docstring)) */ + /* /\* Hack for OClosures: Allow the docstring to be a symbol */ + /* * (the OClosure's type). *\/ */ + /* docstring = Fsymbol_name (docstring); */ + /* CHECK_STRING (docstring); */ + /* cdr = Fcons (XCAR (cdr), Fcons (docstring, XCDR (XCDR (cdr)))); */ } if (NILP (Vinternal_make_interpreted_closure_function)) return Fcons (Qclosure, Fcons (Vinternal_interpreter_environment, cdr)); .. The cause of the problem was patch commit 08108a856a544a80d11b1e9e437fe6c45e25adec Author: Stefan Monnier Date: Fri Apr 29 22:18:09 2022 -0400 debug-early: Print bytecode in a more manageable way * lisp/emacs-lisp/debug-early.el (debug-early-backtrace): Escape newlines to and bytecodes to make backtraces slightly more readable. Use `cl-prin1` when available. , which made debug-early.el dependent on arbitrarily nested Lisp code, in violation of its explicitly stated design goal to have _no_ dependence on Lisp code. Some of this Lisp simply fails to load. It's not clear why the patch was applied. I propose fixing the bug by restoring the code to having no such dependencies with the following patch: diff --git a/lisp/emacs-lisp/debug-early.el b/lisp/emacs-lisp/debug-early.el index 395498f2206..723269f3ea0 100644 --- a/lisp/emacs-lisp/debug-early.el +++ b/lisp/emacs-lisp/debug-early.el @@ -44,28 +44,21 @@ 'debug-early-backtrace (princ "\n") (let ((print-escape-newlines t) (print-escape-control-characters t) - (print-escape-nonascii t) - (prin1 (if (and (fboundp 'cl-prin1) - ;; If we're being called while - ;; bootstrapping, we won't be able to load - ;; cl-print. - (require 'cl-print nil t)) - #'cl-prin1 - #'prin1))) + (print-escape-nonascii t)) (mapbacktrace #'(lambda (evald func args _flags) (let ((args args)) (if evald (progn (princ " ") - (funcall prin1 func) + (prin1 func) (princ "(")) (progn (princ " (") (setq args (cons func args)))) (if args (while (progn - (funcall prin1 (car args)) + (prin1 (car args)) (setq args (cdr args))) (princ " "))) (princ ")\n"))))))) .. Any objections to applying this patch? -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 27 14:15:33 2023 Received: (at 61847) by debbugs.gnu.org; 27 Feb 2023 19:15:33 +0000 Received: from localhost ([127.0.0.1]:48847 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWiyD-0006Fa-Ec for submit@debbugs.gnu.org; Mon, 27 Feb 2023 14:15:33 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:59560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWiyB-0006FK-AP for 61847@debbugs.gnu.org; Mon, 27 Feb 2023 14:15:32 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 823D31000C4; Mon, 27 Feb 2023 14:15:25 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A9D1910002A; Mon, 27 Feb 2023 14:15:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677525323; bh=U4pS5s62WzXYVF7o5sLMDHf8oFxwbklrmzj8IcUXVAk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MsNyoKYAomV0xDf/Y1AfVAMZ7j/Ee19CsXedZnNGJsXrMUVdRvwOnw1grwEypBiie 27dMVfm43o0jhkUJByAJha1nUgTGp2CDeJ5p5D7GmA41zuWIjNxABRqpsJC1klxyio Fii05L48m28qKyNy8snipspL6KyCBwI7LQqJx3aE2Hs9eB3D7HocZe3pSCKYZJ36fR ZxSr65hnhXTbvPRh7YXVx8Uu/EFHzcu7KoxUSfBl0L47jo1ziJU2nj4kUlPuH37I9o ETsRjqFfK10CZAVn7o7MZmhMqKQrNCUzyllW1MjdvmRWsZEp6B5X4Gmm7GhmdAfE0r s3hLCkNz54iYg== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 62660121C5C; Mon, 27 Feb 2023 14:15:23 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: debug-early-backtrace only works some of the time. In-Reply-To: (Alan Mackenzie's message of "Mon, 27 Feb 2023 17:11:51 +0000") Message-ID: References: Date: Mon, 27 Feb 2023 14:15:22 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.055 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847 Cc: 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > The cause of the problem was patch > > commit 08108a856a544a80d11b1e9e437fe6c45e25adec > Author: Stefan Monnier > Date: Fri Apr 29 22:18:09 2022 -0400 > > debug-early: Print bytecode in a more manageable way > > * lisp/emacs-lisp/debug-early.el (debug-early-backtrace): > Escape newlines to and bytecodes to make backtraces slightly more > readable. Use `cl-prin1` when available. > > , which made debug-early.el dependent on arbitrarily nested Lisp code, in > violation of its explicitly stated design goal to have _no_ dependence on > Lisp code. Some of this Lisp simply fails to load. Indeed (fboundp 'cl-prin1) was too optimistic a test since it just checks whether we're before loading `loaddef.el` or after it, but `cl-prin1` uses more (preloaded) features such as those provided by `cl-generic` which is only loaded later. > It's not clear why the patch was applied. To get more readable backtraces when used after bootstrapping (as well as in the later phases of bootstrapping). > I propose fixing the bug by restoring the code to having no such > dependencies with the following patch: How 'bout the patch below instead. Maybe we should instead try and check whether we're after the bootstrap (not sure what would be the corresponding test). Stefan diff --git a/lisp/emacs-lisp/debug-early.el b/lisp/emacs-lisp/debug-early.el index 395498f2206..65770a9c1d9 100644 --- a/lisp/emacs-lisp/debug-early.el +++ b/lisp/emacs-lisp/debug-early.el @@ -46,10 +46,13 @@ 'debug-early-backtrace (print-escape-control-characters t) (print-escape-nonascii t) (prin1 (if (and (fboundp 'cl-prin1) + (fboundp 'cl-defmethod) ;; If we're being called while ;; bootstrapping, we won't be able to load ;; cl-print. - (require 'cl-print nil t)) + (condition-case nil + (require 'cl-print nil t) + (error nil))) #'cl-prin1 #'prin1))) (mapbacktrace From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 28 04:12:20 2023 Received: (at 61847) by debbugs.gnu.org; 28 Feb 2023 09:12:20 +0000 Received: from localhost ([127.0.0.1]:49690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWw20-0006Tb-Cw for submit@debbugs.gnu.org; Tue, 28 Feb 2023 04:12:20 -0500 Received: from mx3.muc.de ([193.149.48.5]:11796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWw1w-0006TK-Iv for 61847@debbugs.gnu.org; Tue, 28 Feb 2023 04:12:19 -0500 Received: (qmail 97450 invoked by uid 3782); 28 Feb 2023 10:12:09 +0100 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 10:12:09 +0100 Received: (qmail 4467 invoked by uid 1000); 28 Feb 2023 09:12:09 -0000 Date: Tue, 28 Feb 2023 09:12:08 +0000 To: Stefan Monnier Subject: Re: debug-early-backtrace only works some of the time. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61847 Cc: 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Mon, Feb 27, 2023 at 14:15:22 -0500, Stefan Monnier wrote: > > The cause of the problem was patch > > commit 08108a856a544a80d11b1e9e437fe6c45e25adec > > Author: Stefan Monnier > > Date: Fri Apr 29 22:18:09 2022 -0400 > > debug-early: Print bytecode in a more manageable way > > * lisp/emacs-lisp/debug-early.el (debug-early-backtrace): > > Escape newlines to and bytecodes to make backtraces slightly more > > readable. Use `cl-prin1` when available. > > , which made debug-early.el dependent on arbitrarily nested Lisp code, in > > violation of its explicitly stated design goal to have _no_ dependence on > > Lisp code. Some of this Lisp simply fails to load. > Indeed (fboundp 'cl-prin1) was too optimistic a test since it just > checks whether we're before loading `loaddef.el` or after it, but > `cl-prin1` uses more (preloaded) features such as those provided by > `cl-generic` which is only loaded later. It violates the design goal of having no Lisp dependencies. It was those dependencies which broke the rock solid dependability of the original code. > > It's not clear why the patch was applied. > To get more readable backtraces when used after bootstrapping (as well as > in the later phases of bootstrapping). More readable? Just how is a backtrace produced using cl-prin1 more readable than one using prin1? They both look pretty much the same. But cl-prin1 only outputs partial information for some things, such as compiled functions, so it is not a good choice. debug-early-backtrace should produce _complete_ backtraces. > > I propose fixing the bug by restoring the code to having no such > > dependencies with the following patch: > How 'bout the patch below instead. > Maybe we should instead try and check whether we're after the bootstrap > (not sure what would be the corresponding test). It might work. It might work now, and fail in future releases of Emacs should the loading mechanism get changed. The original code using prin1 was rock solid, by design. What if there was some bug in the loading mechanism, or a bug in cl-print.el which prevented it loading cleanly, yet without triggering the condition-case you suggest below? Again, what's so readable about cl-prin1's output that makes it worth the compromise in debug-early-backtrace's design? And how will the contition-case you suggest help? (require 'cl-print nil t) returns non-nil in the pertinent circumstances. Putting a condition-case around that isn't going to change this. Have you actually tried out your patch? What happened when you did? > Stefan > diff --git a/lisp/emacs-lisp/debug-early.el b/lisp/emacs-lisp/debug-early.el > index 395498f2206..65770a9c1d9 100644 > --- a/lisp/emacs-lisp/debug-early.el > +++ b/lisp/emacs-lisp/debug-early.el > @@ -46,10 +46,13 @@ 'debug-early-backtrace > (print-escape-control-characters t) > (print-escape-nonascii t) > (prin1 (if (and (fboundp 'cl-prin1) > + (fboundp 'cl-defmethod) > ;; If we're being called while > ;; bootstrapping, we won't be able to load > ;; cl-print. > - (require 'cl-print nil t)) > + (condition-case nil > + (require 'cl-print nil t) > + (error nil))) > #'cl-prin1 > #'prin1))) > (mapbacktrace -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 28 07:16:36 2023 Received: (at 61847) by debbugs.gnu.org; 28 Feb 2023 12:16:36 +0000 Received: from localhost ([127.0.0.1]:49860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWyuK-0003VD-Dc for submit@debbugs.gnu.org; Tue, 28 Feb 2023 07:16:36 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWyuJ-0003Ul-1K for 61847@debbugs.gnu.org; Tue, 28 Feb 2023 07:16:35 -0500 Received: from fencepost.gnu.org ([209.51.188.10]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pWyuD-0006wg-KH; Tue, 28 Feb 2023 07:16:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Gpz3rP+GhxkZ7QKh0wTizbdf2EgoRQzskR+hyCf2KRM=; b=kGavzBVEFxG2 liQsC3cEgvjLO4PKs3YMtMLmmkIZha6YmXPi+cA2utAplcALX1MsgpmbLpX6A9F3+RhOLYxX2yMGH QtCEsebGHdD5eWt2R65e+crN1FuUDpiJ6Ygg9yTJSYPV/Zwo/CVEL2zUt7rWoOpQHAfV7jfPjWmwL c6dbmt0tYxR9VVjqjNdaSqm2hL+XqJVFF+DE5suezPdKG3GQuiQJLN53asomumnv8gEEIlZ4QaT3D CV2Zklyi7SoT5DzKZZKAYdaJk/80q4zmXczjHz43r5BXpJZlNEDOeKYwxUdV4SbK2VP4Tkqq+ipVk 58egrOORDKEc+jpWsYxn+Q==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pWyuD-0004su-3B; Tue, 28 Feb 2023 07:16:29 -0500 Date: Tue, 28 Feb 2023 14:16:40 +0200 Message-Id: <83fsaqgf2v.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Tue, 28 Feb 2023 09:12:08 +0000) Subject: Re: bug#61847: debug-early-backtrace only works some of the time. References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 61847@debbugs.gnu.org > Date: Tue, 28 Feb 2023 09:12:08 +0000 > From: Alan Mackenzie > > > How 'bout the patch below instead. > > Maybe we should instead try and check whether we're after the bootstrap > > (not sure what would be the corresponding test). > > It might work. It might work now, and fail in future releases of Emacs > should the loading mechanism get changed. The original code using prin1 > was rock solid, by design. It isn't clear to me why you consider code that uses prin1 to be "rock solid by design". Please elaborate. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 28 08:16:50 2023 Received: (at 61847) by debbugs.gnu.org; 28 Feb 2023 13:16:51 +0000 Received: from localhost ([127.0.0.1]:49921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWzqc-0007c4-KG for submit@debbugs.gnu.org; Tue, 28 Feb 2023 08:16:50 -0500 Received: from mx3.muc.de ([193.149.48.5]:19057) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pWzqb-0007bq-7F for 61847@debbugs.gnu.org; Tue, 28 Feb 2023 08:16:49 -0500 Received: (qmail 97862 invoked by uid 3782); 28 Feb 2023 14:16:43 +0100 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 14:16:42 +0100 Received: (qmail 21978 invoked by uid 1000); 28 Feb 2023 13:16:42 -0000 Date: Tue, 28 Feb 2023 13:16:42 +0000 To: Eli Zaretskii Subject: Re: bug#61847: debug-early-backtrace only works some of the time. Message-ID: References: <83fsaqgf2v.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83fsaqgf2v.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Tue, Feb 28, 2023 at 14:16:40 +0200, Eli Zaretskii wrote: > > Cc: 61847@debbugs.gnu.org > > Date: Tue, 28 Feb 2023 09:12:08 +0000 > > From: Alan Mackenzie > > > How 'bout the patch below instead. > > > Maybe we should instead try and check whether we're after the bootstrap > > > (not sure what would be the corresponding test). > > It might work. It might work now, and fail in future releases of Emacs > > should the loading mechanism get changed. The original code using prin1 > > was rock solid, by design. > 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. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 28 09:23:21 2023 Received: (at 61847) by debbugs.gnu.org; 28 Feb 2023 14:23:21 +0000 Received: from localhost ([127.0.0.1]:49990 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX0sy-00015M-Tt for submit@debbugs.gnu.org; Tue, 28 Feb 2023 09:23:21 -0500 Received: from eggs.gnu.org ([209.51.188.92]:33274) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX0sw-000159-Qf for 61847@debbugs.gnu.org; Tue, 28 Feb 2023 09:23:19 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pX0sq-0003V3-7E; Tue, 28 Feb 2023 09:23:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2aI3JD7NsbJgxBxxHXmbQ9xX/YICP/J66Jq0j/g9dc4=; b=inQJi1mFSO5d VT5PdGJrX2UoaixI8PTZXKlCzDtpovtXnAU+NVIDeuHPUb7soNy2VCJ7q9WbAssHO+LYrTTVG6nfa K8qFZ/eRWbpNVDrhE8zdeDyA/+MYW/HYKAypUUxE5P/OpizDcifU/snv5X5eb25tNJRLcvuVXfwev Y5/YJIZgfNjbhUJplpVopPguixsGNjuHA7ESFyu5drseGLFFfGJiJyEt76J4Nxoxk7hvA4dW4StUL SDJXcASF0BWohfsUAWfEcB6BgzGzxwjnIzhFAcdnbHBn2oJZD9lQVXgOFdwetp6YWYHKdGRR5pBbe xxGAtGr2cgrh2OiYk+QEAg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pX0s1-0001cO-Mx; Tue, 28 Feb 2023 09:22:36 -0500 Date: Tue, 28 Feb 2023 16:22:30 +0200 Message-Id: <837cw1hntl.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Tue, 28 Feb 2023 13:16:42 +0000) Subject: Re: bug#61847: debug-early-backtrace only works some of the time. References: <83fsaqgf2v.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. 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? 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. That way we will have a more future-proof feature. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 28 09:45:51 2023 Received: (at 61847) by debbugs.gnu.org; 28 Feb 2023 14:45:51 +0000 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 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 Received: (qmail 30057 invoked by uid 3782); 28 Feb 2023 15:45:43 +0100 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 Received: (qmail 22048 invoked by uid 1000); 28 Feb 2023 14:45:42 -0000 Date: Tue, 28 Feb 2023 14:45:42 +0000 To: Eli Zaretskii Subject: Re: bug#61847: debug-early-backtrace only works some of the time. Message-ID: References: <83fsaqgf2v.fsf@gnu.org> <837cw1hntl.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <837cw1hntl.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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). From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 28 12:36:53 2023 Received: (at 61847) by debbugs.gnu.org; 28 Feb 2023 17:36:54 +0000 Received: from localhost ([127.0.0.1]:51933 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX3uH-0006qG-IU for submit@debbugs.gnu.org; Tue, 28 Feb 2023 12:36:53 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:6727) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX3uF-0006q2-LG for 61847@debbugs.gnu.org; Tue, 28 Feb 2023 12:36:52 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0762A1000BF; Tue, 28 Feb 2023 12:36:44 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0CF101000BD; Tue, 28 Feb 2023 12:36:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677605795; bh=73uAuzf7Q4RlvuRIQfY/ea7AYO248Zo80cTVPesVYIU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=OE3Q1uk9Nl2H/18hFqcS8R06F84FogQb6bFOPONmPefU1CsGWSYZqCcB1byoZ9DbO inXT8CYO1dBzkPLzt1q9EEvwMNCMTG/EjIjzIYIIdkz9ozf1i2ew/u8KRTBpaRhQ0I 1d0fxBsR9dG/2I/MNKClwb4WH/MqL93b9Ti5WUtP0xVDJ+di/xAo0cBzbCsvYWKUoY m3v5vEDWRUcUFJxJ1vi0E4Mb06Ek9yaBpXLdXHlUYVRpAY6SM2K8ZnwAw77hhVRHnQ K9oduwera6/u5CYHWKdfbOA0+zEOOZG/k7TGH5x2t12udKziQJjfNTykMnv6A1AGp5 AfxcMZ6KvDasQ== Received: from ceviche (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DB4A11231C3; Tue, 28 Feb 2023 12:36:34 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: debug-early-backtrace only works some of the time. In-Reply-To: (Alan Mackenzie's message of "Tue, 28 Feb 2023 09:12:08 +0000") Message-ID: References: Date: Tue, 28 Feb 2023 12:36:32 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.051 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847 Cc: 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> To get more readable backtraces when used after bootstrapping (as well as >> in the later phases of bootstrapping). > > More readable? Just how is a backtrace produced using cl-prin1 more > readable than one using prin1? They both look pretty much the same. But > cl-prin1 only outputs partial information for some things, such as > compiled functions, so it is not a good choice. debug-early-backtrace > should produce _complete_ backtraces. The output for compiled functions is the main one which I think is more readable (among those that occur often in backtraces), so let's just agree to disagree on this one. > And how will the contition-case you suggest help? (require 'cl-print nil > t) returns non-nil in the pertinent circumstances. The `noerror` argument of `require` doesn't silence the errors that happen while loading the file, instead it prevents signaling an error when the file is not found. > Putting a condition-case around that isn't going to change this. I'm hoping it will. > Have you actually tried out your patch? No. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 28 14:52:44 2023 Received: (at 61847) by debbugs.gnu.org; 28 Feb 2023 19:52:44 +0000 Received: from localhost ([127.0.0.1]:52044 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX61j-0002BZ-M8 for submit@debbugs.gnu.org; Tue, 28 Feb 2023 14:52:43 -0500 Received: from mx3.muc.de ([193.149.48.5]:31293) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX61h-0002BJ-Rg for 61847@debbugs.gnu.org; Tue, 28 Feb 2023 14:52:42 -0500 Received: (qmail 11631 invoked by uid 3782); 28 Feb 2023 20:52:34 +0100 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 20:52:34 +0100 Received: (qmail 22030 invoked by uid 1000); 28 Feb 2023 19:52:33 -0000 Date: Tue, 28 Feb 2023 19:52:33 +0000 To: Stefan Monnier Subject: Re: debug-early-backtrace only works some of the time. Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61847 Cc: 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Tue, Feb 28, 2023 at 12:36:32 -0500, Stefan Monnier wrote: > >> To get more readable backtraces when used after bootstrapping (as well as > >> in the later phases of bootstrapping). > > More readable? Just how is a backtrace produced using cl-prin1 more > > readable than one using prin1? They both look pretty much the same. But > > cl-prin1 only outputs partial information for some things, such as > > compiled functions, so it is not a good choice. debug-early-backtrace > > should produce _complete_ backtraces. > The output for compiled functions is the main one which I think is more > readable (among those that occur often in backtraces), so let's just > agree to disagree on this one. No. The point is too important not to resolve. I think you're objectively wrong here. The purpose of a backtrace is not to enter a beauty contest. Rather it's to provide the programmer with as much information as reasonably possible to solve a bug. The lack of output for compiled functions with cl-prin1 condemns it. All that appears is "#f(compiled-function)" together with an empty pair of parentheses and a meaningless hex address. What use is any of that in debugging a batch mode bug? prin1 by contrast prints the actual contents of the function - its byte code string and its constant vector, among other things. It may not be as "readable", but it is infinitely more useful to the person trying to debug a bug. > > And how will the contition-case you suggest help? (require 'cl-print nil > > t) returns non-nil in the pertinent circumstances. > The `noerror` argument of `require` doesn't silence the errors that > happen while loading the file, instead it prevents signaling an error > when the file is not found. Whether that error is silenced or not is wholly unimportant. The only important thing here is to get a backtrace, and your patch will not help do that. Mine does help - I've tested it. > > Putting a condition-case around that isn't going to change this. > I'm hoping it will. How can it possibly help get that backtrace? > > Have you actually tried out your patch? > No. Please do so, and report. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 28 14:58:42 2023 Received: (at 61847) by debbugs.gnu.org; 28 Feb 2023 19:58:42 +0000 Received: from localhost ([127.0.0.1]:52057 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX67V-0002LM-P7 for submit@debbugs.gnu.org; Tue, 28 Feb 2023 14:58:42 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13851) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pX67U-0002LA-EN for 61847@debbugs.gnu.org; Tue, 28 Feb 2023 14:58:41 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 97BF91000BF; Tue, 28 Feb 2023 14:58:34 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DB9B51000BD; Tue, 28 Feb 2023 14:58:32 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677614312; bh=qSo+ywNDl4THv40oWDInuespMo7H5TwAoMTXyaKg++w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lxAcGiHD6SDZ4unaDvG/1kwa9jI81hcAl1eIK+Z9GX3HxJdzXFwoIIU6Bzn/E+CBs jRD+mLI8dxswSQt8zQyA93Qgsu8NvodD5bcu1F386jYgbpSfrlHcCYrAYwl+HcykVs 3HmjWH4x5ylg00zvuJfwx1D+zou/IJUGdNHEDJoMd3CK3QDV13XueZf06XBY7SufnK pEK8aYVUe+0l4nb7yb0m3n6aHIsXBsdQbhMpEXZ7OVVMCtrzRpdVbQ8GHpKmbHr4N9 oJ/oUCcJopRS+yllWbCxD79do1QbxtZcIHeNHD/sr+jQZefwS2HDCONRxWCmLHi70u Diq6RbiYFkGZg== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B0BDD120855; Tue, 28 Feb 2023 14:58:32 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: debug-early-backtrace only works some of the time. In-Reply-To: (Alan Mackenzie's message of "Tue, 28 Feb 2023 19:52:33 +0000") Message-ID: References: Date: Tue, 28 Feb 2023 14:58:31 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.050 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847 Cc: 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> The output for compiled functions is the main one which I think is more >> readable (among those that occur often in backtraces), so let's just >> agree to disagree on this one. > > No. The point is too important not to resolve. > > I think you're objectively wrong here. The purpose of a backtrace is > not to enter a beauty contest. Rather it's to provide the programmer > with as much information as reasonably possible to solve a bug. > > The lack of output for compiled functions with cl-prin1 condemns it. All > that appears is "#f(compiled-function)" together with an empty pair of > parentheses and a meaningless hex address. What use is any of that in > debugging a batch mode bug? > > prin1 by contrast prints the actual contents of the function - its byte > code string and its constant vector, among other things. It may not be > as "readable", but it is infinitely more useful to the person trying to > debug a bug. I'm not sure what you're expecting from me. Obviously, I'm aware of what you describe. I just don't reach the same conclusion. >> > And how will the contition-case you suggest help? (require 'cl-print nil >> > t) returns non-nil in the pertinent circumstances. >> The `noerror` argument of `require` doesn't silence the errors that >> happen while loading the file, instead it prevents signaling an error >> when the file is not found. > Whether that error is silenced or not is wholly unimportant. The only > important thing here is to get a backtrace, The silencing of the error should help to get a backtrace since it should let the code fall back to using `prin1`. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 07:16:07 2023 Received: (at 61847) by debbugs.gnu.org; 1 Mar 2023 12:16:07 +0000 Received: from localhost ([127.0.0.1]:52913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXLNP-0005jQ-AT for submit@debbugs.gnu.org; Wed, 01 Mar 2023 07:16:07 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38254) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXLNN-0005ih-1o for 61847@debbugs.gnu.org; Wed, 01 Mar 2023 07:16:05 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXLNG-0005mu-Lv; Wed, 01 Mar 2023 07:15:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WlvQxD8fDZPgk5GwchHOJJ4CoKQ+hyc3da2WCVifA7g=; b=RGUejH25sT8L 75pK2aUNlWkSbAMGubdbW0Uk89BkI9QZPORz+50RpsX0svPVfyNM47w/EpxeFPFfFYS4TyKrlkexB VO+NptJlrJa+kP6r2NQMF1faIs3oPrFEqVjNAmLZXPn0XzyAAN3Ff1mpEeK26KPLS6/NtuM019Kpm rO1UioIX+CityVCAwqGdpGQGpwgM7D8dvkuO3XlvhEcnQa9s9LDnSeT+65GfyAmoVyVdPNi/1sXmw IzYBVxcWSwrzluKoLOyL9n5QtdCfHs6vUKhHxDAzFuGVgZ2Y+P5ndG15cREs7dPlZSK6eRUr8RjLz Y6t+try1/9i9iy2pxHCGZQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXLNF-0004uV-N5; Wed, 01 Mar 2023 07:15:58 -0500 Date: Wed, 01 Mar 2023 14:16:11 +0200 Message-Id: <83v8jkfz04.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Tue, 28 Feb 2023 19:52:33 +0000) Subject: Re: bug#61847: debug-early-backtrace only works some of the time. References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 61847@debbugs.gnu.org > Date: Tue, 28 Feb 2023 19:52:33 +0000 > From: Alan Mackenzie > > The lack of output for compiled functions with cl-prin1 condemns it. All > that appears is "#f(compiled-function)" together with an empty pair of > parentheses and a meaningless hex address. What use is any of that in > debugging a batch mode bug? And what use is the meaningless stream of raw bytes that prin1 produces? > prin1 by contrast prints the actual contents of the function - its byte > code string and its constant vector, among other things. And with some of the bytes interpreted by the terminal, it is _really_ useful. To say nothing of attempting to post it in a bug report, where it can ruin the entire email message. I think you should re-evaluate your preferences, and base them on real advantages and disadvantages, not on imaginary ones. If we want our backtraces to be more informative, not less, we should move farther away of "dumb" output functions that just spill the guts and towards more humanly-readable formatted description of the called functions. IOW, make cl-prin1 smarter and teach it doing _more_ and do it _better_, not less and worse. For example, how about a more detailed, but human-readable description of bytecode? From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 08:33:14 2023 Received: (at 61847) by debbugs.gnu.org; 1 Mar 2023 13:33:14 +0000 Received: from localhost ([127.0.0.1]:53027 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXMa2-0001kV-3D for submit@debbugs.gnu.org; Wed, 01 Mar 2023 08:33:14 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49938) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXMa1-0001kH-5u for 61847@debbugs.gnu.org; Wed, 01 Mar 2023 08:33:13 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXMZs-0004wn-Ee; Wed, 01 Mar 2023 08:33:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WUDyM5lQJ3toqEt8qrPEpApx4WxLRVEPEHNnqX5hjK0=; b=jOukuNQirXOO kVhQu0+hhcVhYWcOgu1wLxQ1yASLUnfhVy952pvFrFS8YKhyMpeNvXOTUk+2bVneHNMiScQ54gCky /tDwAHv21rsk1lC7zR8nCXSPyAhZKOe4UmQNtGXgzkY6a0POYKAQJeN/oEWTqg10Y/qcIXSeN8BFH 48LHoN0xr+icvnWCfdhGnBRJzUZDtj29fZS6qOVWZsFYXjYL9lJUEkFmT4mFFU/hMSxhfYgt8Cfvj LAjFgnD5ND9ovBdu5eIxaJ+xxtxIghptjZCoOJCAPCawSsS8cuTaG4/fhWxlIi7+9+8UmJBefdAR9 5ppau4rh3vsqVuPQWwFLfg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXMZC-0008BJ-EO; Wed, 01 Mar 2023 08:32:47 -0500 Date: Wed, 01 Mar 2023 15:32:35 +0200 Message-Id: <83lekgfvgs.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Tue, 28 Feb 2023 19:52:33 +0000) Subject: Re: bug#61847: debug-early-backtrace only works some of the time. References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 61847@debbugs.gnu.org > Date: Tue, 28 Feb 2023 19:52:33 +0000 > From: Alan Mackenzie > > The purpose of a backtrace is not to enter a beauty contest. Rather > it's to provide the programmer with as much information as > reasonably possible to solve a bug. Information that is humanly-readable and understandable, yes. Not just any information. Showing raw bytes of the bytecode is not very useful information, IMNSHO. Or at least we could make it much more useful, if we really want that part to be presented to the programmer. > prin1 by contrast prints the actual contents of the function - its byte > code string and its constant vector, among other things. It may not be > as "readable", but it is infinitely more useful to the person trying to > debug a bug. 1 is "infinitely more" than zero, but it is still just 1. Not 1`00 and not 1000. IOW, just because relatively you get an "infinite" improvement, the net improvement is still very small, and there's no reason to stop there. So your argument against cl-prin1, if taken to its logical conclusion, should be rephrased as "let's improve cl-prin1", not "let's go back to the infinitely useless prin1". From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 10:22:38 2023 Received: (at 61847) by debbugs.gnu.org; 1 Mar 2023 15:22:38 +0000 Received: from localhost ([127.0.0.1]:54581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXOHt-0005U4-Vm for submit@debbugs.gnu.org; Wed, 01 Mar 2023 10:22:38 -0500 Received: from mx3.muc.de ([193.149.48.5]:11124) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXOHr-0005Tq-R8 for 61847@debbugs.gnu.org; Wed, 01 Mar 2023 10:22:36 -0500 Received: (qmail 41771 invoked by uid 3782); 1 Mar 2023 16:22:30 +0100 Received: from acm.muc.de (pd953ac29.dip0.t-ipconnect.de [217.83.172.41]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 01 Mar 2023 16:22:29 +0100 Received: (qmail 25611 invoked by uid 1000); 1 Mar 2023 15:22:29 -0000 Date: Wed, 1 Mar 2023 15:22:29 +0000 To: Eli Zaretskii Subject: Re: bug#61847: debug-early-backtrace only works some of the time. Message-ID: References: <83v8jkfz04.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83v8jkfz04.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Wed, Mar 01, 2023 at 14:16:11 +0200, Eli Zaretskii wrote: > > Cc: 61847@debbugs.gnu.org > > Date: Tue, 28 Feb 2023 19:52:33 +0000 > > From: Alan Mackenzie > > The lack of output for compiled functions with cl-prin1 condemns it. All > > that appears is "#f(compiled-function)" together with an empty pair of > > parentheses and a meaningless hex address. What use is any of that in > > debugging a batch mode bug? > And what use is the meaningless stream of raw bytes that prin1 > produces? If that were indeed what was produced, none at all. Because debug-early-backtrace binds print-escape-control-characters to t, what actually gets produced is a mixture of ascii characters and octal escaped representations, just like you see when an .elc file is visited in Emacs. > > prin1 by contrast prints the actual contents of the function - its byte > > code string and its constant vector, among other things. > And with some of the bytes interpreted by the terminal, it is _really_ > useful. To say nothing of attempting to post it in a bug report, > where it can ruin the entire email message. See above. > I think you should re-evaluate your preferences, and base them on real > advantages and disadvantages, not on imaginary ones. What makes you think I'm not doing this already? I wrote debug-early last year because I _needed_ it. I've a lot of experience using it, and the way it prints (or rather used to print) a compiled function is/was useful. You can see how many arguments it takes. You can see the byte code string, hence enabling you to compare it visually with the contents of a .elc file, should such already exist. You can see the constant vector. You get an idea of how big the function is. All these things are helpful when you want to find out which particular lambda form is in the backtrace. Again, I'm talking from experience, not imagined benefits. > If we want our backtraces to be more informative, not less, we should > move farther away of "dumb" output functions that just spill the guts > and towards more humanly-readable formatted description of the called > functions. A wholesome long term goal I fully agree with. For the here and now, outputting "#f(compiled-function () " and nothing else is not a step in that direction. > IOW, make cl-prin1 smarter and teach it doing _more_ and do it > _better_, not less and worse. For example, how about a more detailed, > but human-readable description of bytecode? You mean a disassembly? That's an idea, but it would be very bulky in a backtrace, and hinder the visual comparison with the putatively same byte code in a .elc buffer in Emacs. A backtrace I got the other evening was already 126 MB big. Besides, the idea of debug-early is to generate a backtrace before all the fancy Lisp facilities are available. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 11:01:21 2023 Received: (at 61847) by debbugs.gnu.org; 1 Mar 2023 16:01:21 +0000 Received: from localhost ([127.0.0.1]:54721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXOtM-0000jP-T7 for submit@debbugs.gnu.org; Wed, 01 Mar 2023 11:01:21 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58038) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXOtL-0000jB-2g for 61847@debbugs.gnu.org; Wed, 01 Mar 2023 11:01:19 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXOtF-00022e-8d; Wed, 01 Mar 2023 11:01:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wFOCaMS3KGQj/3FRZJ2hz1HxRLOr3LDggxvdxesW5gQ=; b=JoOkDhxtgxT2 jDWTOqATRCDkxfoCvsqZ1ebc6avlVqFl0KLKEzwIWGApfDfcTaLumlJcslgQbJ47LO2ww3c/OKGo3 6e53wE1Zoecbaj1T7i1HBVobJKXbkEFvzaIof9I8QbEVammGm3Ue8B5wdk67undAz5cIYshbePWZk sAV9oF0B6SOyM7U2grQQV1J679ii6398DYA7nNEfp2NGZpN9qzbKUM3kK9Tmsc6co7epG8gE6Eahf T+HE8i7+uCbMZXA7g6uUCnxPVBA7rbcufQK91Fk4UF7ibinzj/FAB5Do+7MWbZeyFKRRVgF5ZKdkr vmzSXXxU6B9Pe6ARRPrCTQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXOtE-00071A-4R; Wed, 01 Mar 2023 11:01:12 -0500 Date: Wed, 01 Mar 2023 18:01:24 +0200 Message-Id: <83edq8fokr.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Wed, 1 Mar 2023 15:22:29 +0000) Subject: Re: bug#61847: debug-early-backtrace only works some of the time. References: <83v8jkfz04.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 1 Mar 2023 15:22:29 +0000 > Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org > From: Alan Mackenzie > > > And what use is the meaningless stream of raw bytes that prin1 > > produces? > > If that were indeed what was produced, none at all. Because > debug-early-backtrace binds print-escape-control-characters to t, what > actually gets produced is a mixture of ascii characters and octal > escaped representations, just like you see when an .elc file is visited > in Emacs. Escaping raw bytes doesn't make them more comprehensible. > > I think you should re-evaluate your preferences, and base them on real > > advantages and disadvantages, not on imaginary ones. > > What makes you think I'm not doing this already? I wrote debug-early > last year because I _needed_ it. I've a lot of experience using it, and > the way it prints (or rather used to print) a compiled function is/was > useful. For you, maybe. Not for me. For me it's a nuisance. A useless waste of screen estate. > You can see how many arguments it takes. That information exists elsewhere. > You can see the byte code string, hence enabling you to compare it > visually with the contents of a .elc file, should such already > exist. Let's be serious, okay? > > If we want our backtraces to be more informative, not less, we should > > move farther away of "dumb" output functions that just spill the guts > > and towards more humanly-readable formatted description of the called > > functions. > > A wholesome long term goal I fully agree with. For the here and now, > outputting "#f(compiled-function () " and nothing > else is not a step in that direction. But using cl-prin1 _is_ a step in the right direction, because it allows us to extend the feature. And that is why I said that if loading Lisp breaks something in debug-early, we should solve this _now_, not fall back on prin1, which by its very nature cannot be extended so easily. > Besides, the idea of debug-early is to generate a backtrace before all > the fancy Lisp facilities are available. Some fancy Lisp facilities are already available anyway. And I see no reason for this requirement in this case. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 11:06:06 2023 Received: (at 61847) by debbugs.gnu.org; 1 Mar 2023 16:06:06 +0000 Received: from localhost ([127.0.0.1]:54728 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXOxy-0000qS-3X for submit@debbugs.gnu.org; Wed, 01 Mar 2023 11:06:06 -0500 Received: from mx3.muc.de ([193.149.48.5]:12532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXOxw-0000pv-Jx for 61847@debbugs.gnu.org; Wed, 01 Mar 2023 11:06:05 -0500 Received: (qmail 21460 invoked by uid 3782); 1 Mar 2023 17:05:58 +0100 Received: from acm.muc.de (pd953ac29.dip0.t-ipconnect.de [217.83.172.41]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 01 Mar 2023 17:05:58 +0100 Received: (qmail 25626 invoked by uid 1000); 1 Mar 2023 16:05:58 -0000 Date: Wed, 1 Mar 2023 16:05:58 +0000 To: Eli Zaretskii , g@acm.muc.de Subject: Re: bug#61847: debug-early-backtrace only works some of the time. Message-ID: References: <83lekgfvgs.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83lekgfvgs.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Wed, Mar 01, 2023 at 15:32:35 +0200, Eli Zaretskii wrote: > > Cc: 61847@debbugs.gnu.org > > Date: Tue, 28 Feb 2023 19:52:33 +0000 > > From: Alan Mackenzie > > The purpose of a backtrace is not to enter a beauty contest. Rather > > it's to provide the programmer with as much information as > > reasonably possible to solve a bug. > Information that is humanly-readable and understandable, yes. Not > just any information. Showing raw bytes of the bytecode is not very > useful information, IMNSHO. In my experience, it is useful. cl-prin1 outputs essentially no information at all about compiled functions. That is not useful. > Or at least we could make it much more useful, if we really want that > part to be presented to the programmer. Debugging used to be done with core dumps. debug-early-backtrace's output using prin1 is more useful than that. And yes, we do want to present it to the programmer. > > prin1 by contrast prints the actual contents of the function - its byte > > code string and its constant vector, among other things. It may not be > > as "readable", but it is infinitely more useful to the person trying to > > debug a bug. > 1 is "infinitely more" than zero, but it is still just 1. Not 1`00 > and not 1000. debug-early, using prin1, generates useful output for debugging problems in early bootstrap. Using cl-prin1, the output is less useful. > IOW, just because relatively you get an "infinite" improvement, the > net improvement is still very small, and there's no reason to stop > there. The improvement is significant. For what it's worth, I think debugging in Emacs, at whatever level, is currently too hard, too uncertain, and too laborious. I've been working to try and improve this for quite a long time. > So your argument against cl-prin1, if taken to its logical conclusion, > should be rephrased as "let's improve cl-prin1", not "let's go back to > the infinitely useless prin1". My main argument against cl-prin1 is that it's Lisp, and loading Lisp in early bootstrap is an uncertain, difficult process, as this bug shows. The guiding design principle in debug-early.el was to use _NO_ Lisp at all, other than debug-early.el itself. This was for the sake of the solidity which temacs has, in comparison with the unprocessed Lisp source files. prin1 is _far_ from "infinitely useless". I've used it to good effect. cl-prin1 is not useful for printing compiled functions. How about this suggestion: to fix the bug right now, we put prin1 back in, as it was in the original debug-early.el. When cl-prin1 has improved sufficiently, we then consider putting it back into debug-early.el? -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 11:47:01 2023 Received: (at 61847) by debbugs.gnu.org; 1 Mar 2023 16:47:01 +0000 Received: from localhost ([127.0.0.1]:54774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXPbZ-0001tR-C3 for submit@debbugs.gnu.org; Wed, 01 Mar 2023 11:47:01 -0500 Received: from mx3.muc.de ([193.149.48.5]:13801) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXPbX-0001tC-Ad for 61847@debbugs.gnu.org; Wed, 01 Mar 2023 11:47:00 -0500 Received: (qmail 83783 invoked by uid 3782); 1 Mar 2023 17:46:53 +0100 Received: from acm.muc.de (pd953ac29.dip0.t-ipconnect.de [217.83.172.41]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 01 Mar 2023 17:46:53 +0100 Received: (qmail 27124 invoked by uid 1000); 1 Mar 2023 16:46:52 -0000 Date: Wed, 1 Mar 2023 16:46:52 +0000 To: Eli Zaretskii Subject: Re: bug#61847: debug-early-backtrace only works some of the time. Message-ID: References: <83v8jkfz04.fsf@gnu.org> <83edq8fokr.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83edq8fokr.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Wed, Mar 01, 2023 at 18:01:24 +0200, Eli Zaretskii wrote: > > Date: Wed, 1 Mar 2023 15:22:29 +0000 > > Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org > > From: Alan Mackenzie > > > And what use is the meaningless stream of raw bytes that prin1 > > > produces? > > If that were indeed what was produced, none at all. Because > > debug-early-backtrace binds print-escape-control-characters to t, what > > actually gets produced is a mixture of ascii characters and octal > > escaped representations, just like you see when an .elc file is visited > > in Emacs. > Escaping raw bytes doesn't make them more comprehensible. It does, if they contain control characters which would otherwise corrupt the screen. > > > I think you should re-evaluate your preferences, and base them on real > > > advantages and disadvantages, not on imaginary ones. > > What makes you think I'm not doing this already? I wrote debug-early > > last year because I _needed_ it. I've a lot of experience using it, and > > the way it prints (or rather used to print) a compiled function is/was > > useful. > For you, maybe. Not for me. For me it's a nuisance. A useless waste > of screen estate. Yes, for me, and lots of other people too. Byte code is very compact, and we're talking about a very few lines of screen "wasted". > > You can see how many arguments it takes. > That information exists elsewhere. You're misunderstanding the situation. You see a lambda form represented in a backtrace, you don't know which lambda form it is. There are over 8,000 of them in Emacs. Knowing the number of arguments helps identify _which_ lambda form it is. > > You can see the byte code string, hence enabling you to compare it > > visually with the contents of a .elc file, should such already > > exist. > Let's be serious, okay? I'm being perfectly serious. I've done this. It enabled me to be sure that I'd identified the lambda form in question, removing the doubt. > > > If we want our backtraces to be more informative, not less, we > > > should move farther away of "dumb" output functions that just spill > > > the guts and towards more humanly-readable formatted description of > > > the called functions. > > A wholesome long term goal I fully agree with. For the here and now, > > outputting "#f(compiled-function () " and nothing > > else is not a step in that direction. > But using cl-prin1 _is_ a step in the right direction, because it > allows us to extend the feature. Well then, let's get cl-prin1 up to the state where it is better than bare prin1. As I keep saying cl-prin1 is useless for printing compiled lambda forms at the moment. > And that is why I said that if loading Lisp breaks something in > debug-early, we should solve this _now_, not fall back on prin1, which > by its very nature cannot be extended so easily. That it cannot be extended easily is not a disadvantage. It means there is always a dependable debug-early-backtrace. The attempt to load cl-prin1 into debug-early is precisely what caused this bug. > > Besides, the idea of debug-early is to generate a backtrace before all > > the fancy Lisp facilities are available. > Some fancy Lisp facilities are already available anyway. And I see no > reason for this requirement in this case. In a situation where Emacs does not bootstrap, instead crashing during the loading or compiling of the Lisp files, we need a debugging tool which isn't dependent upon those Lisp files. That is what debug-early.el is intended to be. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 11:53:11 2023 Received: (at 61847) by debbugs.gnu.org; 1 Mar 2023 16:53:11 +0000 Received: from localhost ([127.0.0.1]:54779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXPhX-00026y-CS for submit@debbugs.gnu.org; Wed, 01 Mar 2023 11:53:11 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58682) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXPhV-00026l-0F for 61847@debbugs.gnu.org; Wed, 01 Mar 2023 11:53:10 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXPhN-0006jo-SM; Wed, 01 Mar 2023 11:53:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mM7sHgr6T5HDN9DF4AMrJmOuAX6IdD4TCIxmtysqJ4c=; b=UvaFtSF/sKjb eco6xbNP3doGuZZo/RM/adK1QtHkHSqm3VTJvGt/3giIssdPCftX/r8WIxfoFyknwi4F7qO9QpG6r 8kQiGj87wC21w6B9NIFJ3JShVMm8oYAkPQ5p6gINCzHmlv4JlJS6q/MagfDPLYjlIi0Uor/3h9SO4 bJ/DlKpB3EQq+JXGMCHXkzOHYhkEqQMYeM7Vuxt4cPrbUQmlbjUxQePFHisEu2tq3aK7N1Esys5IT 9rP1MLlLt4gYCp2e7y2WS1MVq8KuWGMKHX++AsVHoEvfyfHOY7CUV6K2aUfZVtNXT1r6B+Xreyk+W OG8jX/b9d4kPLoLJ2QTkMA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXPhN-0001I0-2r; Wed, 01 Mar 2023 11:53:01 -0500 Date: Wed, 01 Mar 2023 18:53:13 +0200 Message-Id: <83cz5sfm6e.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Wed, 1 Mar 2023 16:05:58 +0000) Subject: Re: bug#61847: debug-early-backtrace only works some of the time. References: <83lekgfvgs.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847 Cc: g@acm.muc.de, monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 1 Mar 2023 16:05:58 +0000 > Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org > From: Alan Mackenzie > > My main argument against cl-prin1 is that it's Lisp, and loading Lisp in > early bootstrap is an uncertain, difficult process, as this bug shows. My main point, which I evidently fail to drive home, is that we must do that anyway, if we want these backtraces to show a reasonably readable information. > prin1 is _far_ from "infinitely useless". I've used it to good effect. Yes, and when I was younger, I used MSDOS to good effect. > cl-prin1 is not useful for printing compiled functions. Then let's make it useful! That's the right direction, not falling back to prin1. > How about this suggestion: to fix the bug right now, we put prin1 back > in, as it was in the original debug-early.el. When cl-prin1 has > improved sufficiently, we then consider putting it back into > debug-early.el? No. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 12:04:28 2023 Received: (at 61847) by debbugs.gnu.org; 1 Mar 2023 17:04:28 +0000 Received: from localhost ([127.0.0.1]:54802 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXPsR-0002Pw-MU for submit@debbugs.gnu.org; Wed, 01 Mar 2023 12:04:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXPsQ-0002Pj-Ad for 61847@debbugs.gnu.org; Wed, 01 Mar 2023 12:04:26 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXPsJ-0000qj-QU; Wed, 01 Mar 2023 12:04:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=FFLpHqGjAo3NtEiKQ8VGE1ayqa59rDRSr9B1/GMKzJA=; b=f9c3Kbg563bS VoUIF/ICIKR5tBZidg00Lyf49SLWD3hJGgUu5vCBFiKYMUAot1R7uWbodTZxn15NU8quxQ+pJl31+ 8rZCxHlD+wsVoCO4lOdtKPFauYtXvCqjnE/8Ztm6za6JC9O1LakVMKD3YzgD/oO9Q4F2M4L5uoliH azGPUoPEGQs1v/Yfu9QXgz4qJa70FOZQM9HZWDnLZTBq1CN7BHqVGMTKLkIrA6h6LyLChNs2WdieU 45sVOQxvpoIHKdyLqc+LVB9YLkP4IJdxH0lE/lZ4phIo2R5MyrVZn2nKHGIpLaHNG2flZ0/LP4ZMP SRTeqhwT7R69KnfTTWUr/A==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXPsI-0006n9-TR; Wed, 01 Mar 2023 12:04:19 -0500 Date: Wed, 01 Mar 2023 19:04:32 +0200 Message-Id: <838rggflnj.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Wed, 1 Mar 2023 16:46:52 +0000) Subject: Re: bug#61847: debug-early-backtrace only works some of the time. References: <83v8jkfz04.fsf@gnu.org> <83edq8fokr.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 1 Mar 2023 16:46:52 +0000 > Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org > From: Alan Mackenzie > > > Some fancy Lisp facilities are already available anyway. And I see no > > reason for this requirement in this case. > > In a situation where Emacs does not bootstrap, instead crashing during > the loading or compiling of the Lisp files, we need a debugging tool > which isn't dependent upon those Lisp files. That is what debug-early.el > is intended to be. You are saying that only Lisp code can crash and make debugging harder? Have you never seen crashes inside prin1? Any code that prints arbitrary objects can crash. That fact is not a useful argument for or against a particular alternative for such printing. Anyway, I don't see any point in continuing this argument. It is clear that we disagree here, and the nature of the disagreement is also very clear. From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 12:31:33 2023 Received: (at 61847) by debbugs.gnu.org; 1 Mar 2023 17:31:33 +0000 Received: from localhost ([127.0.0.1]:54816 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXQIf-000345-3b for submit@debbugs.gnu.org; Wed, 01 Mar 2023 12:31:33 -0500 Received: from mx3.muc.de ([193.149.48.5]:15183) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXQId-00033m-GM for 61847@debbugs.gnu.org; Wed, 01 Mar 2023 12:31:32 -0500 Received: (qmail 56005 invoked by uid 3782); 1 Mar 2023 18:31:24 +0100 Received: from acm.muc.de (pd953ac29.dip0.t-ipconnect.de [217.83.172.41]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 01 Mar 2023 18:31:23 +0100 Received: (qmail 3891 invoked by uid 1000); 1 Mar 2023 17:31:23 -0000 Date: Wed, 1 Mar 2023 17:31:23 +0000 To: Eli Zaretskii Subject: Re: bug#61847: debug-early-backtrace only works some of the time. Message-ID: References: <83v8jkfz04.fsf@gnu.org> <83edq8fokr.fsf@gnu.org> <838rggflnj.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <838rggflnj.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Eli. On Wed, Mar 01, 2023 at 19:04:32 +0200, Eli Zaretskii wrote: > > Date: Wed, 1 Mar 2023 16:46:52 +0000 > > Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org > > From: Alan Mackenzie > > > Some fancy Lisp facilities are already available anyway. And I see no > > > reason for this requirement in this case. > > In a situation where Emacs does not bootstrap, instead crashing during > > the loading or compiling of the Lisp files, we need a debugging tool > > which isn't dependent upon those Lisp files. That is what debug-early.el > > is intended to be. > You are saying that only Lisp code can crash and make debugging > harder? Have you never seen crashes inside prin1? Of course not. I'm saying that Lisp code, in early bootstrap, DOES crash, and for that we need a suitable tool, namely debug-early.el. For other sorts of crashes we use other tools. And no, I've never seen a crash inside prin1. That function was debugged long before I started hacking on Emacs. > Any code that prints arbitrary objects can crash. That fact is not a > useful argument for or against a particular alternative for such > printing. > Anyway, I don't see any point in continuing this argument. It is > clear that we disagree here, and the nature of the disagreement is > also very clear. Alright, but we still have a bug to fix. I think (but I'm not sure) that you agree that cl-prin1 in its current state isn't currently adequate for debug-early.el. You have rejected my proposed fix. So what alternative do you propose? -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 12:34:15 2023 Received: (at 61847-done) by debbugs.gnu.org; 1 Mar 2023 17:34:15 +0000 Received: from localhost ([127.0.0.1]:54827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXQLG-00038h-UH for submit@debbugs.gnu.org; Wed, 01 Mar 2023 12:34:15 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:33443) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXQLF-00038T-0r for 61847-done@debbugs.gnu.org; Wed, 01 Mar 2023 12:34:13 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9171344103D; Wed, 1 Mar 2023 12:34:07 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 37EDE440F0E; Wed, 1 Mar 2023 12:34:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677692046; bh=8p1CblQsGM/MqhVrAosL97YHXpLXUN98ev5t0NeH8gE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NMUbkFLtDgAsRWBnsE+jx2Ag9EY4LO9LUT7jUjxR7QebUNDlqWM3OATrmJNnQ5uca u4h4LEOtekwDlEudwLsIyw1UeJGdmyHFA5LMi9+NKZJnaRXWrFguOgn6CFrStteu50 A+7MlfxqzN2YndR0cQczmeOLtVunOlMV4BqfUNbO/AQyC9qJkLQiTQS9yJ/HczYfRf Q7KH/AQjeXK+TJ4scZcD4UAoVEYWmr/WA/GadCodvLcYfsXgXLSTaGATiRHwTlHTLQ BGsoyxkMyAsbD1Fu1C+G5Xcd/H0hlRViZ4kTs8gm9SKeh8oSuMYlMVqFF5mBmoGa4d X18loCGP+2Rrw== Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D19621231AF; Wed, 1 Mar 2023 12:34:05 -0500 (EST) From: Stefan Monnier To: Alan Mackenzie Subject: Re: bug#61847: debug-early-backtrace only works some of the time. In-Reply-To: (Alan Mackenzie's message of "Wed, 1 Mar 2023 15:22:29 +0000") Message-ID: References: <83v8jkfz04.fsf@gnu.org> Date: Wed, 01 Mar 2023 12:34:04 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.124 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847-done Cc: Eli Zaretskii , 61847-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > the way it prints (or rather used to print) a compiled function is/was > useful. You can see how many arguments it takes. Hmm... `prin1` will print for example #[256 ...] where 256 is where it tells "how many arguments it takes". In contrast, `cl-prin1` will print #f(compiled-function (&optional arg) ...) So in both cases "you can see how many arguments it takes" (and I'll let you guess which one I find more readable). FWIW, I just tried the `condition-case` wrapper and it fixes the problem for the test case you showed. So I just pushed my patch to `emacs-29` (which additionally checks for the presence of `cl-defmethod`, which also fixes the problem: one is never too sure). I'll let you (plural) decide whether to keep using `cl-prin1` or not, but now this is not directly related to fixing this bug any more. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 01 13:22:51 2023 Received: (at 61847) by debbugs.gnu.org; 1 Mar 2023 18:22:51 +0000 Received: from localhost ([127.0.0.1]:54890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXR6I-0004PM-OQ for submit@debbugs.gnu.org; Wed, 01 Mar 2023 13:22:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pXR6G-0004P9-IY for 61847@debbugs.gnu.org; Wed, 01 Mar 2023 13:22:49 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXR69-0006Rq-Ts; Wed, 01 Mar 2023 13:22:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=tqPW/IVCCgYFGpsNt3fL86cUcGYC8Qjr8RdltrLc/ao=; b=puwy8x+vAnuv iZJk6vRxxH/xng9ffuEiZyF81m+EI93dXopqVOvCDjLP+l3nmGc2AfIj2fsy7K3fe1tNu0/cwTcVD A5OxGf+fGqcc8e+34YgIEu2IUdyLOWFtNjoYlwND4j/2CKufIjOQSQE3Bej69v/VoYcupjiQ1ceHy wPzP12pGkzPgKaClPcsYAqtmBc3vQrfUg8JNbHAytCmOnSbo5ommZHL9WJNNcENt95bZMlDsReHHB pxHT4E2XHIbSRjksAEDlEHbLsyzUHutishehFj03U/mf5UrNxcs4vHVy6WRE2DamsZPMFZ00k0z4n 4hBoKbjWghBjXLZ/SfnLhA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pXR69-0006s7-4K; Wed, 01 Mar 2023 13:22:41 -0500 Date: Wed, 01 Mar 2023 20:22:55 +0200 Message-Id: <837cw0fi0w.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Wed, 1 Mar 2023 17:31:23 +0000) Subject: Re: bug#61847: debug-early-backtrace only works some of the time. References: <83v8jkfz04.fsf@gnu.org> <83edq8fokr.fsf@gnu.org> <838rggflnj.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 61847 Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 1 Mar 2023 17:31:23 +0000 > Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org > From: Alan Mackenzie > > You have rejected my proposed fix. So what alternative do you propose? To start from what Stefan suggested, and improve/fix that if needed. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 03 05:59:02 2023 Received: (at 61847-done) by debbugs.gnu.org; 3 Mar 2023 10:59:02 +0000 Received: from localhost ([127.0.0.1]:59758 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pY37u-0007hW-Ax for submit@debbugs.gnu.org; Fri, 03 Mar 2023 05:59:02 -0500 Received: from mx3.muc.de ([193.149.48.5]:31418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pY37s-0007hD-VK for 61847-done@debbugs.gnu.org; Fri, 03 Mar 2023 05:59:01 -0500 Received: (qmail 29154 invoked by uid 3782); 3 Mar 2023 11:58:54 +0100 Received: from acm.muc.de (pd953ac79.dip0.t-ipconnect.de [217.83.172.121]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 03 Mar 2023 11:58:54 +0100 Received: (qmail 11108 invoked by uid 1000); 3 Mar 2023 10:58:52 -0000 Date: Fri, 3 Mar 2023 10:58:52 +0000 To: Stefan Monnier Subject: Re: bug#61847: debug-early-backtrace only works some of the time. Message-ID: References: <83v8jkfz04.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 61847-done Cc: Eli Zaretskii , 61847-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Stefan. On Wed, Mar 01, 2023 at 12:34:04 -0500, Stefan Monnier wrote: > > the way it prints (or rather used to print) a compiled function is/was > > useful. You can see how many arguments it takes. > Hmm... > `prin1` will print for example #[256 ...] where 256 is where it tells > "how many arguments it takes". > In contrast, `cl-prin1` will print #f(compiled-function (&optional arg) ...) > So in both cases "you can see how many arguments it takes" (and I'll > let you guess which one I find more readable). I find them both equally readable, having practised reading dumped functions. But I accept most people won't. > FWIW, I just tried the `condition-case` wrapper and it fixes the problem > for the test case you showed. So I just pushed my patch to > `emacs-29` (which additionally checks for the presence of > `cl-defmethod`, which also fixes the problem: one is never too sure). One is never too sure, which was one of the points of the original design. > I'll let you (plural) decide whether to keep using `cl-prin1` or not, > but now this is not directly related to fixing this bug any more. You could have reminded me of the variable cl-print-compiled, which at least allows you to dump the constant vector. I propose extending this variable thusly: diff --git a/lisp/emacs-lisp/cl-print.el b/lisp/emacs-lisp/cl-print.el index 61586526ca1..74dad303a27 100644 --- a/lisp/emacs-lisp/cl-print.el +++ b/lisp/emacs-lisp/cl-print.el @@ -165,6 +165,7 @@ 'help-byte-code (defvar cl-print-compiled nil "Control how to print byte-compiled functions. Acceptable values include: +- `full' to print out the full contents of the function using `prin1'. - `static' to print the vector of constants. - `disassemble' to print the disassembly of the code. - nil to skip printing any details about the code.") > Stefan -- Alan Mackenzie (Nuremberg, Germany). From unknown Mon Aug 18 17:56:05 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 31 Mar 2023 11:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator