Re: The poor quality of Emacs's backtraces

[Alan Mackenzie <acm@muc.de>]

Hello, Mattias.

On Wed, Jul 19, 2023 at 12:33:51 +0200, Mattias Engdegård wrote:
> 17 juli 2023 kl. 21.02 skrev Alan Mackenzie <acm@muc.de>:

> > Well, I've committed the code (see below).  Please actually measure it
> > and point out where it is actually slow,

> That is your obligation, not ours. You cannot demand that other people
> accept your assertion that it is fast or have to prove otherwise.
> Measuring performance properly is actual work.

You've distorted my point by inappropriate snipping of the context.

> > And please don't exaggerate the "ease" with which it was written.

> I'm sure it was most taxing work.

> > I don't agree, at least not at the moment.  The function object, all
> > three varieties, is big enough to hold all the information it needs
> > to hold.  Should it need to become marginally bigger, so be it.

> It's apparently not big enough since you had to enlarge it.

You've misunderstood the English usage, here.  "is big enough to hold
all the information ...." is talking about the design principle.  We
don't decide how big a function object should be, then see how much
information we can pack into this.

> Now please remember that the current closure problem is not your
> fault: it's an unsatisfactory set of data structures that we would
> like to clean up. But it is what we have to work with for the time
> being, and it's unclear when we will be able to do something about it
> (it's a considerably bigger task).

What closure problem?  Has this been expounded in a post on emacs-devel?
(A reference would be appreciated if so).  Who is the "we" in this
context?  Why do you think it will be such a big task to fix it?

> > These are all things that can be changed later.  The main danger is doing
> > nothing but talk, talk, talk, ....

> This kind of argument is unhelpful. Implying that there is an urgency
> and that we therefore should accept your solution without delay does
> not go down well. Nor does attempts to brush away valid criticism as
> things that can be changed later.

> There is no crisis, and rushing through changes will be of benefit to
> nobody in the long run.

Note that nobody in this thread has countered my argument with "I find
the Emacs backtrace perfectly satisfactory, and don't think any change
is needed.".

> > That "faulting operation" is merely one
> > of the things I want.  I would not be satisfied by just that.  The
> > identity of the code referred to by each backtrace line is also
> > essential.

> There is a difference between what you personally want, and what you
> reasonably can expect to impose upon others.

I get the feeling I am being enticed into a fight with you.  You've
replied to things in my posts, giving them meanings and nuances that
they weren't intended to carry in the first place, partly by selective
snipping of the context.

I don't want to play this game with you.  I've produced working code,
you have given no sign that you've actually tried it, or looked at it,
yet you don't seem short of disparagement for it.

> > Whatever we do will involve "maintenance costs".

> You misunderstand. I'm talking about adding a feature which we cannot
> easily undo or even change once it's in place. Whenever we do that, we
> will have to be certain that it's the right one.

That involves looking at it and trying it out.

This will be my last post in this arm of the thread.

-- 
Alan Mackenzie (Nuremberg, Germany).