emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The poor quality of Emacs's backtraces


From: Mattias Engdegård
Subject: Re: The poor quality of Emacs's backtraces
Date: Wed, 19 Jul 2023 12:33:51 +0200

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.

> 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.

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

> 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.

> 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.

> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]