all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: monnier@iro.umontreal.ca, 61847@debbugs.gnu.org
Subject: bug#61847: debug-early-backtrace only works some of the time.
Date: Wed, 1 Mar 2023 15:22:29 +0000	[thread overview]
Message-ID: <Y/9ttdt5HC7jRhtK@ACM> (raw)
In-Reply-To: <83v8jkfz04.fsf@gnu.org>

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 <acm@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).





  reply	other threads:[~2023-03-01 15:22 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27 17:11 bug#61847: debug-early-backtrace only works some of the time Alan Mackenzie
2023-02-27 19:15 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-28  9:12   ` Alan Mackenzie
2023-02-28 12:16     ` Eli Zaretskii
2023-02-28 13:16       ` Alan Mackenzie
2023-02-28 14:22         ` Eli Zaretskii
2023-02-28 14:45           ` Alan Mackenzie
2023-02-28 17:36     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-02-28 19:52       ` Alan Mackenzie
2023-02-28 19:58         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-01 12:16         ` Eli Zaretskii
2023-03-01 15:22           ` Alan Mackenzie [this message]
2023-03-01 16:01             ` Eli Zaretskii
2023-03-01 16:46               ` Alan Mackenzie
2023-03-01 17:04                 ` Eli Zaretskii
2023-03-01 17:31                   ` Alan Mackenzie
2023-03-01 18:22                     ` Eli Zaretskii
2023-03-01 17:34             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-03-03 10:58               ` Alan Mackenzie
2023-03-01 13:32         ` Eli Zaretskii
2023-03-01 16:05           ` Alan Mackenzie
2023-03-01 16:53             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y/9ttdt5HC7jRhtK@ACM \
    --to=acm@muc.de \
    --cc=61847@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.