[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.
- Re: The poor quality of Emacs's backtraces, (continued)
- Re: The poor quality of Emacs's backtraces, Alan Mackenzie, 2023/07/14
- Re: The poor quality of Emacs's backtraces, Mattias Engdegård, 2023/07/14
- Re: The poor quality of Emacs's backtraces, Alan Mackenzie, 2023/07/14
- Re: The poor quality of Emacs's backtraces, Mattias Engdegård, 2023/07/17
- Re: The poor quality of Emacs's backtraces, Alan Mackenzie, 2023/07/17
- Re: The poor quality of Emacs's backtraces, Ihor Radchenko, 2023/07/17
- Re: The poor quality of Emacs's backtraces, Alan Mackenzie, 2023/07/18
- Re: The poor quality of Emacs's backtraces, Ihor Radchenko, 2023/07/18
- Re: The poor quality of Emacs's backtraces, Alan Mackenzie, 2023/07/18
- Re: The poor quality of Emacs's backtraces, Ihor Radchenko, 2023/07/19
- Re: The poor quality of Emacs's backtraces,
Mattias Engdegård <=
- Re: The poor quality of Emacs's backtraces, Alan Mackenzie, 2023/07/19
Re: The poor quality of Emacs's backtraces, Michael Heerdegen, 2023/07/13