Early backtrace.

Early backtrace.

[Alan Mackenzie]

Hello, Emacs.

In the course of debugging a recent bug, I found myself needing to get a
Lisp backtrace.  This was early on in the bootstrap process, where the
standard backtrace.el cannot work, since it requires several files.el
which are only loaded later.

So I came up with the following, which has no Lisp dependencies.  That
is, absolutely none.  I have used it as the first Lisp file loaded,
immediately before byte-run.el.

So, how about including this file in Emacs, amending eval.c to use it if
backtrace.el isn't yet avaiable?  Comments and criticism are welcome.

lisp/emacs-lisp/early-debug.el:
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defalias 'early-backtrace
  #'(lambda ()
  "Print a trace of Lisp function calls currently active.
The output stream used is the value of `standard-output'.

This is a simplified version of the standard `backtrace'
function, intended for use in debugging the early parts
of the build process."
  (princ "\n")
  (mapbacktrace
   #'(lambda (evald func args _flags)
       (let ((args args))
	 (if evald
	     (progn
	       (princ "  ")
	       (prin1 func)
	       (princ " (")
	       (while args
		 (prin1 (car args))
		 (setq args (cdr args))
		 (if args
		     (princ " ")))
	       (princ ")\n"))
	   (while args
	     (princ "  ")
	     (prin1 (car args))
	     (princ "\n")
	     (setq args (cdr args)))))))))

(defalias 'early-debug
  #'(lambda (&rest args)
  "Print a trace of Lisp function calls currently active.
The output stream used is the value of `standard-output'.

There should be two ARGS, the symbol `error' and a cons of
the error symbol and its data.

This is a simplified version of `debug', intended for use
in debugging the early parts of the build process."
  (princ "\nError: ")
  (prin1 (car (car (cdr args))))	; The error symbol.
  (princ " ")
  (prin1 (cdr (car (cdr args))))	; The error data.
  (early-backtrace)))

(setq debugger #'early-debug)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Early backtrace.

[Stefan Monnier]

> So I came up with the following, which has no Lisp dependencies.  That
> is, absolutely none.  I have used it as the first Lisp file loaded,
> immediately before byte-run.el.

I have a similar hack here for the same reason ;-)
So a +1 from me (tho I'd recommend using the `debugger-` namespace
rather than `early-`).

> So, how about including this file in Emacs, amending eval.c to use it if
> backtrace.el isn't yet avaiable?  Comments and criticism are welcome.

I don't see any need for a change to `eval.c`.  Just put the

    (setq debugger #'early-debug)

and

    (setq debugger #'debug)

at the appropriate places inside `loadup.el`.


        Stefan

Re: Early backtrace.

[Alan Mackenzie]

Hello, Stefan.

On Mon, Jan 10, 2022 at 16:54:16 -0500, Stefan Monnier wrote:
> > So I came up with the following, which has no Lisp dependencies.  That
> > is, absolutely none.  I have used it as the first Lisp file loaded,
> > immediately before byte-run.el.

> I have a similar hack here for the same reason ;-)
> So a +1 from me (tho I'd recommend using the `debugger-` namespace
> rather than `early-`).

Thanks!  Maybe `debug-early' and `backtrace-early' would do for the two
functions?  There isn't really a debugger- prefix that early in the
bootstrap.

> > So, how about including this file in Emacs, amending eval.c to use it if
> > backtrace.el isn't yet avaiable?  Comments and criticism are welcome.

> I don't see any need for a change to `eval.c`.  Just put the

>     (setq debugger #'early-debug)

> and

>     (setq debugger #'debug)

> at the appropriate places inside `loadup.el`.

No, inside signal_or_quit, Vdebugger gets bound to Qdebug, so as to
bypass the setting made in ERT.  Also it is filtered out by checking for
not being in dump or bootstrap.  Instead, we should check Ffboundp
(Qdebug) || Ffboundp (Qdebug_early).  Not difficult to do.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Early backtrace.

[Stefan Monnier]

>> I have a similar hack here for the same reason ;-)
>> So a +1 from me (tho I'd recommend using the `debugger-` namespace
>> rather than `early-`).
>
> Thanks!  Maybe `debug-early' and `backtrace-early' would do for the two
> functions?  There isn't really a debugger- prefix that early in the
> bootstrap.

Namespace prefixes don't need to be created before we use them.
The point is just that `debugger-` is already used by definitions (in
`debug.el`) so we can reuse that space instead of messing up pristine
real estate.

> No, inside signal_or_quit, Vdebugger gets bound to Qdebug, so as to
> bypass the setting made in ERT.  Also it is filtered out by checking for
> not being in dump or bootstrap.  Instead, we should check Ffboundp
> (Qdebug) || Ffboundp (Qdebug_early).  Not difficult to do.

Oh, god, I didn't know (or forgot) about that horror.
We should throw it out: your code should make it obsolete.
E.g. we can take your new code as the default value of `debugger` and
only replace it with `#'debugger` when an interactive frame
is available.


        Stefan

[PATCH]: Re: Early backtrace.

[Alan Mackenzie]

Hello, everybody.

On Tue, Jan 11, 2022 at 09:47:34 -0500, Stefan Monnier wrote:
> >> I have a similar hack here for the same reason ;-)
> >> So a +1 from me (tho I'd recommend using the `debugger-` namespace
> >> rather than `early-`).

> > Thanks!  Maybe `debug-early' and `backtrace-early' would do for the two
> > functions?  There isn't really a debugger- prefix that early in the
> > bootstrap.

> Namespace prefixes don't need to be created before we use them.
> The point is just that `debugger-` is already used by definitions (in
> `debug.el`) so we can reuse that space instead of messing up pristine
> real estate.

OK, I've called it debug-early.

> > No, inside signal_or_quit, Vdebugger gets bound to Qdebug, so as to
> > bypass the setting made in ERT.  Also it is filtered out by checking for
> > not being in dump or bootstrap.  Instead, we should check Ffboundp
> > (Qdebug) || Ffboundp (Qdebug_early).  Not difficult to do.

> Oh, god, I didn't know (or forgot) about that horror.
> We should throw it out: your code should make it obsolete.
> E.g. we can take your new code as the default value of `debugger` and
> only replace it with `#'debugger` when an interactive frame
> is available.

debug-early.el installs itself as the debugger when it loads.  I've made
debug-early the dump routine used in batch mode.

I now have a patch ready.  It permits a Lisp backtrace to be created
early in the bootstrapping process.

It also fixes a bug in signal_or_quit (eval.c) where previously there
was:

      specbind (Vdebugger, Qdebug);

, which had the effect of binding the contents of Vdebugger (namely
Qdebug) to itself.  Correct would have been:

      specbind (Qdebugger, Qdebug);

, binding the symbol Qdebugger to Qdebug.

The patch loads lisp/emacs-lisp/debug-early.el as the first loaded by
loadup.el, and creates debug-early.el.

Are there any objections to me committing this to master?



diff --git a/lisp/loadup.el b/lisp/loadup.el
index 1be73a2090..81172c584d 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -128,6 +128,7 @@
 (set-buffer "*scratch*")
 (setq buffer-undo-list t)
 
+(load "emacs-lisp/debug-early")
 (load "emacs-lisp/byte-run")
 (load "emacs-lisp/backquote")
 (load "subr")
diff --git a/src/eval.c b/src/eval.c
index 6a8c759c1d..034f8bf6e4 100644
--- a/src/eval.c
+++ b/src/eval.c
@@ -1893,18 +1893,19 @@ signal_or_quit (Lisp_Object error_symbol, Lisp_Object data, bool keyboard_quit)
     }
 
   /* If we're in batch mode, print a backtrace unconditionally to help
-     with debugging.  Make sure to use `debug' unconditionally to not
-     interfere with ERT or other packages that install custom
-     debuggers.  Don't try to call the debugger while dumping or
-     bootstrapping, it wouldn't work anyway.  */
+     with debugging.  Make sure to use `debug-early' unconditionally
+     to not interfere with ERT or other packages that install custom
+     debuggers.  */
   if (!debugger_called && !NILP (error_symbol)
       && (NILP (clause) || EQ (h->tag_or_ch, Qerror))
       && noninteractive && backtrace_on_error_noninteractive
-      && !will_dump_p () && !will_bootstrap_p ()
-      && NILP (Vinhibit_debugger))
+      && NILP (Vinhibit_debugger)
+      && !NILP (Ffboundp (Qdebug_early)))
     {
+      max_ensure_room (&max_lisp_eval_depth, lisp_eval_depth, 100);
+      max_ensure_room (&max_specpdl_size, SPECPDL_INDEX (), 200);
       ptrdiff_t count = SPECPDL_INDEX ();
-      specbind (Vdebugger, Qdebug);
+      specbind (Qdebugger, Qdebug_early);
       call_debugger (list2 (Qerror, Fcons (error_symbol, data)));
       unbind_to (count, Qnil);
     }
@@ -4421,6 +4422,7 @@ syms_of_eval (void)
   DEFSYM (Qclosure, "closure");
   DEFSYM (QCdocumentation, ":documentation");
   DEFSYM (Qdebug, "debug");
+  DEFSYM (Qdebug_early, "debug-early");
 
   DEFVAR_LISP ("inhibit-debugger", Vinhibit_debugger,
 	       doc: /* Non-nil means never enter the debugger.
@@ -4467,6 +4469,7 @@ syms_of_eval (void)
 	       doc: /* Non-nil means display call stack frames as lists. */);
   debugger_stack_frame_as_list = 0;
 
+  DEFSYM (Qdebugger, "debugger");
   DEFVAR_LISP ("debugger", Vdebugger,
 	       doc: /* Function to call to invoke debugger.
 If due to frame exit, args are `exit' and the value being returned;


;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

;;; debug-early.el --- Dump a Lisp backtrace without frills  -*- lexical-binding: t; -*-

;; Copyright (C) 2022 Free Software Foundation, Inc.

;; Author: Alan Mackenzie <acm@muc.de>
;; Maintainer: emacs-devel@gnu.org
;; Keywords: internal, backtrace, bootstrap.
;; Package: emacs

;; This file is part of GNU Emacs.

;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; GNU Emacs is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:

;; This file dumps a backtrace on stderr when an error is thrown.
;; It has no dependencies on any Lisp libraries and is thus suitable
;; for generating backtraces in the early parts of bootstrapping.  It
;; is also good for generating backtraces in batch mode in general.

(defalias 'debug-early-backtrace
  #'(lambda ()
  "Print a trace of Lisp function calls currently active.
The output stream used is the value of `standard-output'.

This is a simplified version of the standard `backtrace'
function, intended for use in debugging the early parts
of the build process."
  (princ "\n")
  (mapbacktrace
   #'(lambda (evald func args _flags)
       (let ((args args))
	 (if evald
	     (progn
	       (princ "  ")
	       (prin1 func)
	       (princ " (")
	       (while args
		 (prin1 (car args))
		 (setq args (cdr args))
		 (if args
		     (princ " ")))
	       (princ ")\n"))
	   (while args
	     (princ "  ")
	     (prin1 (car args))
	     (princ "\n")
	     (setq args (cdr args)))))))))

(defalias 'debug-early
  #'(lambda (&rest args)
  "Print a trace of Lisp function calls currently active.
The output stream used is the value of `standard-output'.

There should be two ARGS, the symbol `error' and a cons of
the error symbol and its data.

This is a simplified version of `debug', intended for use
in debugging the early parts of the build process."
  (princ "\nError: ")
  (prin1 (car (car (cdr args))))	; The error symbol.
  (princ " ")
  (prin1 (cdr (car (cdr args))))	; The error data.
  (debug-early-backtrace)))

(setq debugger #'debug-early)

;;; debug-early.el ends here.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH]: Re: Early backtrace.

[Stefan Monnier]

Alan Mackenzie [2022-01-30 11:07:32] wrote:

>> Namespace prefixes don't need to be created before we use them.
>> The point is just that `debugger-` is already used by definitions (in
>> `debug.el`) so we can reuse that space instead of messing up pristine
>> real estate.
> OK, I've called it debug-early.

Deal!

> Are there any objections to me committing this to master?

See my comments below.

>    /* If we're in batch mode, print a backtrace unconditionally to help
> -     with debugging.  Make sure to use `debug' unconditionally to not
> -     interfere with ERT or other packages that install custom
> -     debuggers.  Don't try to call the debugger while dumping or
> -     bootstrapping, it wouldn't work anyway.  */
> +     with debugging.  Make sure to use `debug-early' unconditionally
> +     to not interfere with ERT or other packages that install custom
> +     debuggers.  */

This is not your fault, but I notice that this comment doesn't explain
how we distinguish the case where we want to print a backtrace from the
case where we want to call ERT's "debugger", both of which can occur in
batch mode.

> (defalias 'debug-early-backtrace
>   #'(lambda ()
>   "Print a trace of Lisp function calls currently active.
> The output stream used is the value of `standard-output'.
>
> This is a simplified version of the standard `backtrace'
> function, intended for use in debugging the early parts
> of the build process."
>   (princ "\n")
>   (mapbacktrace
>    #'(lambda (evald func args _flags)
>        (let ((args args))
> 	 (if evald
> 	     (progn
> 	       (princ "  ")
> 	       (prin1 func)
> 	       (princ " (")
> 	       (while args
> 		 (prin1 (car args))
> 		 (setq args (cdr args))
> 		 (if args
> 		     (princ " ")))
> 	       (princ ")\n"))
> 	   (while args
> 	     (princ "  ")
> 	     (prin1 (car args))
> 	     (princ "\n")
> 	     (setq args (cdr args)))))))))
>
> (defalias 'debug-early
>   #'(lambda (&rest args)
>   "Print a trace of Lisp function calls currently active.
> The output stream used is the value of `standard-output'.
>
> There should be two ARGS, the symbol `error' and a cons of
> the error symbol and its data.
>
> This is a simplified version of `debug', intended for use
> in debugging the early parts of the build process."
>   (princ "\nError: ")
>   (prin1 (car (car (cdr args))))	; The error symbol.
>   (princ " ")
>   (prin1 (cdr (car (cdr args))))	; The error data.
>   (debug-early-backtrace)))

I'm curious: why did you split this into two functions?

> (setq debugger #'debug-early)

Could we make `debug-early` the default/initial value of `debugger` in
the C code, so that reloading `debug-early.el` can be done safely?


        Stefan

Re: [PATCH]: Re: Early backtrace.

[Philipp Stephani]

Am So., 30. Jan. 2022 um 12:08 Uhr schrieb Alan Mackenzie <acm@muc.de>:
>
> It also fixes a bug in signal_or_quit (eval.c) where previously there
> was:
>
>       specbind (Vdebugger, Qdebug);
>
> , which had the effect of binding the contents of Vdebugger (namely
> Qdebug) to itself.  Correct would have been:
>
>       specbind (Qdebugger, Qdebug);
>
> , binding the symbol Qdebugger to Qdebug.
>
>

Good find, thanks. Independent of the rest of the patch, should we
install this one-character fix on the release branch?
Maybe that would even make commit
07edc28bdbfeeaeb1008b4fe21bfda586feae562 unnecessary? (Haven't
checked, though.)

Re: [PATCH]: Re: Early backtrace.

[Eli Zaretskii]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Mon, 31 Jan 2022 10:30:35 +0100
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
>  Emacs developers <emacs-devel@gnu.org>
> 
> Am So., 30. Jan. 2022 um 12:08 Uhr schrieb Alan Mackenzie <acm@muc.de>:
> >
> > It also fixes a bug in signal_or_quit (eval.c) where previously there
> > was:
> >
> >       specbind (Vdebugger, Qdebug);
> >
> > , which had the effect of binding the contents of Vdebugger (namely
> > Qdebug) to itself.  Correct would have been:
> >
> >       specbind (Qdebugger, Qdebug);
> >
> > , binding the symbol Qdebugger to Qdebug.
> >
> >
> 
> Good find, thanks. Independent of the rest of the patch, should we
> install this one-character fix on the release branch?

Yes, please.

> Maybe that would even make commit
> 07edc28bdbfeeaeb1008b4fe21bfda586feae562 unnecessary? (Haven't
> checked, though.)

I wouldn't touch that part, as it cannot possibly do any harm.

Re: [PATCH]: Re: Early backtrace.

[Stefan Monnier]

>>    /* If we're in batch mode, print a backtrace unconditionally to help
>> -     with debugging.  Make sure to use `debug' unconditionally to not
>> -     interfere with ERT or other packages that install custom
>> -     debuggers.  Don't try to call the debugger while dumping or
>> -     bootstrapping, it wouldn't work anyway.  */
>> +     with debugging.  Make sure to use `debug-early' unconditionally
>> +     to not interfere with ERT or other packages that install custom
>> +     debuggers.  */
>
> This is not your fault, but I notice that this comment doesn't explain
> how we distinguish the case where we want to print a backtrace from the
> case where we want to call ERT's "debugger", both of which can occur in
> batch mode.

Eli helped me figure out that I was confused here.
So just disregard this comment of mine.
Sorry,


        Stefan

Re: [PATCH]: Re: Early backtrace.

[Alan Mackenzie]

Hello, Eli.

On Mon, Jan 31, 2022 at 14:42:24 +0200, Eli Zaretskii wrote:
> > From: Philipp Stephani <p.stephani2@gmail.com>
> > Date: Mon, 31 Jan 2022 10:30:35 +0100
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
> >  Emacs developers <emacs-devel@gnu.org>

> > Am So., 30. Jan. 2022 um 12:08 Uhr schrieb Alan Mackenzie <acm@muc.de>:

> > > It also fixes a bug in signal_or_quit (eval.c) where previously there
> > > was:

> > >       specbind (Vdebugger, Qdebug);

> > > , which had the effect of binding the contents of Vdebugger (namely
> > > Qdebug) to itself.  Correct would have been:

> > >       specbind (Qdebugger, Qdebug);

> > > , binding the symbol Qdebugger to Qdebug.



> > Good find, thanks. Independent of the rest of the patch, should we
> > install this one-character fix on the release branch?

> Yes, please.

OK, I'll do that, but it's slightly more than one character to change.
A DEFSYM for Qdebugger is also needed in syms_of_eval.

> > Maybe that would even make commit
> > 07edc28bdbfeeaeb1008b4fe21bfda586feae562 unnecessary? (Haven't
> > checked, though.)

> I wouldn't touch that part, as it cannot possibly do any harm.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH]: Re: Early backtrace.

[Alan Mackenzie]

Hello, Eli.

On Mon, Jan 31, 2022 at 16:54:09 +0000, Alan Mackenzie wrote:
> On Mon, Jan 31, 2022 at 14:42:24 +0200, Eli Zaretskii wrote:
> > > From: Philipp Stephani <p.stephani2@gmail.com>
> > > Date: Mon, 31 Jan 2022 10:30:35 +0100
> > > Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
> > >  Emacs developers <emacs-devel@gnu.org>

> > > Good find, thanks. Independent of the rest of the patch, should we
> > > install this one-character fix on the release branch?

> > Yes, please.

> OK, I'll do that, but it's slightly more than one character to change.
> A DEFSYM for Qdebugger is also needed in syms_of_eval.

DONE.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH]: Re: Early backtrace.

[Alan Mackenzie]

Hello, Stefan.

On Sun, Jan 30, 2022 at 11:31:30 -0500, Stefan Monnier wrote:
> Alan Mackenzie [2022-01-30 11:07:32] wrote:

[ .... ]

> > Are there any objections to me committing this to master?

> See my comments below.

[ .... dealt with by your subsequent post .... ]

> > (defalias 'debug-early-backtrace
> >   #'(lambda ()
> >   "Print a trace of Lisp function calls currently active.
> > The output stream used is the value of `standard-output'.

> > This is a simplified version of the standard `backtrace'
> > function, intended for use in debugging the early parts
> > of the build process."
> >   (princ "\n")
> >   (mapbacktrace
> >    #'(lambda (evald func args _flags)
> >        (let ((args args))
> > 	 (if evald
> > 	     (progn
> > 	       (princ "  ")
> > 	       (prin1 func)
> > 	       (princ " (")
> > 	       (while args
> > 		 (prin1 (car args))
> > 		 (setq args (cdr args))
> > 		 (if args
> > 		     (princ " ")))
> > 	       (princ ")\n"))
> > 	   (while args
> > 	     (princ "  ")
> > 	     (prin1 (car args))
> > 	     (princ "\n")
> > 	     (setq args (cdr args)))))))))

> > (defalias 'debug-early
> >   #'(lambda (&rest args)
> >   "Print a trace of Lisp function calls currently active.
> > The output stream used is the value of `standard-output'.

> > There should be two ARGS, the symbol `error' and a cons of
> > the error symbol and its data.

> > This is a simplified version of `debug', intended for use
> > in debugging the early parts of the build process."
> >   (princ "\nError: ")
> >   (prin1 (car (car (cdr args))))	; The error symbol.
> >   (princ " ")
> >   (prin1 (cdr (car (cdr args))))	; The error data.
> >   (debug-early-backtrace)))

> I'm curious: why did you split this into two functions?

Since debug-early-backtrace is potentially useful in its own right, just
as backtrace is.

> > (setq debugger #'debug-early)

> Could we make `debug-early` the default/initial value of `debugger` in
> the C code, so that reloading `debug-early.el` can be done safely?

I'm not sure what you're asking here.  Do you mean set Vdebugger to
debug-early in syms_of_eval?  How would that make reloading
debug-early.el safe?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH]: Re: Early backtrace.

[Stefan Monnier]

>> Could we make `debug-early` the default/initial value of `debugger` in
>> the C code, so that reloading `debug-early.el` can be done safely?
>
> I'm not sure what you're asking here.  Do you mean set Vdebugger to
> debug-early in syms_of_eval?

Yes.

> How would that make reloading debug-early.el safe?

Because then `debug-early.el` wouldn't have a `setq` at top-level so you
could reload it in a normal Emacs session without having the unfortunate
side-effect of setting `debugger` back to `debug-early`.

IOW it would make `debug-early.el` better follow the convention that
loading an ELisp file should have "no" effect.


        Stefan

Re: [PATCH]: Re: Early backtrace.

[Alan Mackenzie]

Hello, Stefan.

On Tue, Feb 01, 2022 at 22:36:39 -0500, Stefan Monnier wrote:
> >> Could we make `debug-early` the default/initial value of `debugger` in
> >> the C code, so that reloading `debug-early.el` can be done safely?

> > I'm not sure what you're asking here.  Do you mean set Vdebugger to
> > debug-early in syms_of_eval?

> Yes.

OK, I've done this.

> > How would that make reloading debug-early.el safe?

> Because then `debug-early.el` wouldn't have a `setq` at top-level so you
> could reload it in a normal Emacs session without having the unfortunate
> side-effect of setting `debugger` back to `debug-early`.

> IOW it would make `debug-early.el` better follow the convention that
> loading an ELisp file should have "no" effect.

OK.  I've now committed this change.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH]: Re: Early backtrace.

[Stefan Monnier]

> OK.  I've now committed this change.

Yay!


        Stefan

Re: [PATCH]: Re: Early backtrace.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Wed, 02 Feb 2022 15:59:14 -0500
> 
> > OK.  I've now committed this change.
> 
> Yay!

How about adding to debug-early.el some minimal documentation, which
would explain how to use this facility for debugging bootstrap
problems and batch-mode problems in general?  The doc strings you,
Alan, provided don't describe the context and the intended use in any
level of useful detail.

Re: [PATCH]: Re: Early backtrace.

[Alan Mackenzie]

Hello, Eli.

On Thu, Feb 03, 2022 at 10:38:08 +0200, Eli Zaretskii wrote:
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: emacs-devel@gnu.org
> > Date: Wed, 02 Feb 2022 15:59:14 -0500

> > > OK.  I've now committed this change.

> > Yay!

> How about adding to debug-early.el some minimal documentation, which
> would explain how to use this facility for debugging bootstrap
> problems and batch-mode problems in general?  The doc strings you,
> Alan, provided don't describe the context and the intended use in any
> level of useful detail.

I'm not sure entirely what's needed here, probably because I've been
working a lot at this level for quite a long time.

Still, I've tried to imporve the level of detail, and come up with this.
Comments and criticism are welcome, as always:



diff --git a/lisp/emacs-lisp/debug-early.el b/lisp/emacs-lisp/debug-early.el
index 718000bfa4..aeb8e8f1b2 100644
--- a/lisp/emacs-lisp/debug-early.el
+++ b/lisp/emacs-lisp/debug-early.el
@@ -60,14 +60,20 @@ 'debug-early-backtrace
 
 (defalias 'debug-early
   #'(lambda (&rest args)
-  "Print a trace of Lisp function calls currently active.
+  "Print an error message with a backtrace of active Lisp function calls.
 The output stream used is the value of `standard-output'.
 
-There should be two ARGS, the symbol `error' and a cons of
-the error symbol and its data.
+There should be two ARGS: the symbol `error' (which is ignored)
+and a cons of the error symbol and the error data.
+
+This is a simplified version of `debug', intended to produce
+diagnostics to help in debugging the early parts of the build
+process.  It is typically called by the Emacs core when an error
+is signaled.
 
-This is a simplified version of `debug', intended for use
-in debugging the early parts of the build process."
+`debug-early' is the default value of the symbol `debugger'
+before enough Lisp has been loaded to support `debug' itself, and
+in batch mode."
   (princ "\nError: ")
   (prin1 (car (car (cdr args))))	; The error symbol.
   (princ " ")


-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH]: Re: Early backtrace.

[Eli Zaretskii]

> Date: Thu, 3 Feb 2022 21:35:26 +0000
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > How about adding to debug-early.el some minimal documentation, which
> > would explain how to use this facility for debugging bootstrap
> > problems and batch-mode problems in general?  The doc strings you,
> > Alan, provided don't describe the context and the intended use in any
> > level of useful detail.
> 
> I'm not sure entirely what's needed here, probably because I've been
> working a lot at this level for quite a long time.

It might be a misunderstanding on my part, caused by your particular
choice of words:

>  (defalias 'debug-early
>    #'(lambda (&rest args)
> -  "Print a trace of Lisp function calls currently active.
> +  "Print an error message with a backtrace of active Lisp function calls.
>  The output stream used is the value of `standard-output'.
>  
> -There should be two ARGS, the symbol `error' and a cons of
> -the error symbol and its data.
> +There should be two ARGS: the symbol `error' (which is ignored)
> +and a cons of the error symbol and the error data.

What do you mean by "should be" here?  Is that something the user
should arrange for, or does this already happen?  If the latter, why
"should"?

> +This is a simplified version of `debug', intended to produce
> +diagnostics to help in debugging the early parts of the build
> +process.  It is typically called by the Emacs core when an error
> +is signaled.

"Typically" means it is, or can be, also called in other cases?  What
are those?

> -This is a simplified version of `debug', intended for use
> -in debugging the early parts of the build process."
> +`debug-early' is the default value of the symbol `debugger'
> +before enough Lisp has been loaded to support `debug' itself, and
> +in batch mode."

When you say "intended for use" and "intended to produce", it sounds
like users should do something to benefit from this "intended use".
If, instead, you mean that this feature is activated automatically in
some circumstances, then I suggest to reword this to describe the
feature from that perspective: when it is activated and what it
provides when activated.

Bottom line, I still miss some higher-level overview of this feature,
which should probably go into the Commentary section of the file.

Thanks.

Re: [PATCH]: Re: Early backtrace.

[Stefan Monnier]

> How about adding to debug-early.el some minimal documentation, which
> would explain how to use this facility for debugging bootstrap
> problems and batch-mode problems in general?

AFAIK there is nothing for the user to do to "use this facility".
It's already automatically used when the normal debugger can't be used.


        Stefan

Re: [PATCH]: Re: Early backtrace.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: acm@muc.de,  emacs-devel@gnu.org
> Date: Fri, 04 Feb 2022 08:31:25 -0500
> 
> > How about adding to debug-early.el some minimal documentation, which
> > would explain how to use this facility for debugging bootstrap
> > problems and batch-mode problems in general?
> 
> AFAIK there is nothing for the user to do to "use this facility".
> It's already automatically used when the normal debugger can't be used.

That's not explained there, either.  Including what exactly hides
behind "when the normal debugger can't be used" part.

Re: [PATCH]: Re: Early backtrace.

[Alan Mackenzie]

Hello, Eli.

On Fri, Feb 04, 2022 at 09:24:35 +0200, Eli Zaretskii wrote:
> > Date: Thu, 3 Feb 2022 21:35:26 +0000
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > How about adding to debug-early.el some minimal documentation, which
> > > would explain how to use this facility for debugging bootstrap
> > > problems and batch-mode problems in general?  The doc strings you,
> > > Alan, provided don't describe the context and the intended use in any
> > > level of useful detail.

> > I'm not sure entirely what's needed here, probably because I've been
> > working a lot at this level for quite a long time.

> It might be a misunderstanding on my part, caused by your particular
> choice of words:

I've revised those words a fair bit.

> >  (defalias 'debug-early
> >    #'(lambda (&rest args)
> > -  "Print a trace of Lisp function calls currently active.
> > +  "Print an error message with a backtrace of active Lisp function calls.
> >  The output stream used is the value of `standard-output'.

> > -There should be two ARGS, the symbol `error' and a cons of
> > -the error symbol and its data.
> > +There should be two ARGS: the symbol `error' (which is ignored)
> > +and a cons of the error symbol and the error data.

> What do you mean by "should be" here?  Is that something the user
> should arrange for, or does this already happen?  If the latter, why
> "should"?

The "should" has now gone.

> > +This is a simplified version of `debug', intended to produce
> > +diagnostics to help in debugging the early parts of the build
> > +process.  It is typically called by the Emacs core when an error
> > +is signaled.

> "Typically" means it is, or can be, also called in other cases?  What
> are those?

"Typically" remains in the doc string for debug-early-backtrace.  This
function can be called at any time, but is particularly useful before
backtrace.el can be loaded.  "Typically" implies the user wouldn't need
it at other times, but isn't prevented from using it then.

I've taken "typically" out of the doc string for debug-early.

> > -This is a simplified version of `debug', intended for use
> > -in debugging the early parts of the build process."
> > +`debug-early' is the default value of the symbol `debugger'
> > +before enough Lisp has been loaded to support `debug' itself, and
> > +in batch mode."

> When you say "intended for use" and "intended to produce", it sounds
> like users should do something to benefit from this "intended use".
> If, instead, you mean that this feature is activated automatically in
> some circumstances, then I suggest to reword this to describe the
> feature from that perspective: when it is activated and what it
> provides when activated.

I've replaced that bit by "The Emacs core calls this function after an
error has been signaled ...."

> Bottom line, I still miss some higher-level overview of this feature,
> which should probably go into the Commentary section of the file.

I've put a bit more into the Commentary section.  Here's the current
state of the patch:



diff --git a/lisp/emacs-lisp/debug-early.el b/lisp/emacs-lisp/debug-early.el
index 718000bfa4..e557643e46 100644
--- a/lisp/emacs-lisp/debug-early.el
+++ b/lisp/emacs-lisp/debug-early.el
@@ -24,10 +24,12 @@
 
 ;;; Commentary:
 
-;; This file dumps a backtrace on stderr when an error is thrown.
-;; It has no dependencies on any Lisp libraries and is thus suitable
-;; for generating backtraces in the early parts of bootstrapping.  It
-;; is also good for generating backtraces in batch mode in general.
+;; This file dumps a backtrace on stderr when an error is thrown.  It
+;; has no dependencies on any Lisp libraries and is thus used for
+;; generating backtraces for bugs in the early parts of bootstrapping.
+;; It is also always used in batch model.  It was introduced in Emacs
+;; 29, before which there was no backtrace available during early
+;; bootstrap.
 
 (defalias 'debug-early-backtrace
   #'(lambda ()
@@ -60,14 +62,22 @@ 'debug-early-backtrace
 
 (defalias 'debug-early
   #'(lambda (&rest args)
-  "Print a trace of Lisp function calls currently active.
+  "Print an error message with a backtrace of active Lisp function calls.
 The output stream used is the value of `standard-output'.
 
-There should be two ARGS, the symbol `error' and a cons of
-the error symbol and its data.
+The Emacs core calls this function after an error has been
+signaled, and supplies two ARGS.  These are the symbol
+`error' (which is ignored) and a cons of the error symbol and the
+error data.
+
+`debug-early' is a simplified version of `debug', and is
+available during the early parts of the build process.  It is
+superseded by `debug' after enough Lisp has been loaded to
+support the latter, except in batch mode which always uses
+`debug-early'.
 
-This is a simplified version of `debug', intended for use
-in debugging the early parts of the build process."
+(In versions of Emacs prior to Emacs 29, no backtrace was
+available before `debug' was usable.)"
   (princ "\nError: ")
   (prin1 (car (car (cdr args))))	; The error symbol.
   (princ " ")


> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: [PATCH]: Re: Early backtrace.

[Eli Zaretskii]

> Date: Fri, 4 Feb 2022 21:01:27 +0000
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> I've put a bit more into the Commentary section.  Here's the current
> state of the patch:

Thanks, LGTM.

Re: [PATCH]: Re: Early backtrace.

[Alan Mackenzie]

Hello, Eli.

On Sat, Feb 05, 2022 at 09:12:06 +0200, Eli Zaretskii wrote:
> > Date: Fri, 4 Feb 2022 21:01:27 +0000
> > Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > I've put a bit more into the Commentary section.  Here's the current
> > state of the patch:

> Thanks, LGTM.

Thank you.  I've committed it to master.

-- 
Alan Mackenzie (Nuremberg, Germany).