[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61847: debug-early-backtrace only works some of the time.
From: |
Alan Mackenzie |
Subject: |
bug#61847: debug-early-backtrace only works some of the time. |
Date: |
Wed, 1 Mar 2023 16:46:52 +0000 |
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 <acm@muc.de>
> > > 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 () <random hex address>" 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).
bug#61847: debug-early-backtrace only works some of the time., Stefan Monnier, 2023/03/01