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

Previous Next

Full log

Message #41 received at 61847 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 61847 <at> debbugs.gnu.org
Subject: Re: bug#61847: debug-early-backtrace only works some of the time.
Date: Wed, 1 Mar 2023 15:22:29 +0000

Hello, Eli.

On Wed, Mar 01, 2023 at 14:16:11 +0200, Eli Zaretskii wrote:
> > 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?

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 () <random hex address>" 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).

Previous Next

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