GNU bug report logs - #61847
debug-early-backtrace only works some of the time.

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Mackenzie <acm <at> muc.de>
Cc: monnier <at> iro.umontreal.ca, 61847 <at> debbugs.gnu.org
Subject: bug#61847: debug-early-backtrace only works some of the time.
Date: Wed, 01 Mar 2023 14:16:11 +0200

> Cc: 61847 <at> debbugs.gnu.org
> Date: Tue, 28 Feb 2023 19:52:33 +0000
> From: Alan Mackenzie <acm <at> muc.de>
> 
> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.