[Top][All Lists]

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

Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstr

From: Paul Eggert
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Fri, 30 Nov 2018 15:46:23 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

On 11/30/18 2:02 PM, Alan Mackenzie wrote:
I'm afraid we'll have to disagree about that. It's not worth slowing all
Emacs computations by 3.5% - 10% or whatever, merely to get
more-accurate locations in byte-compiler diagnostics.
Please stop being so disparaging.  There's nothing "mere" about accurate
compiler messages, and the current bug fix delivers CORRECT locations,
not "more-accurate" ones.

I value performance and the error message location issues don't bother me much in practice, perhaps partly because I tend to break Lisp code into smaller pieces so the exact location of the error doesn't matter that much. Evidently your preferences differ: the location issues bother you, and your machine is faster and/or you don't mind the performance hit. That doesn't make you right and me wrong, or vice versa. It's a matter of balancing priorities.

Remember, in a bootstrap, only 25% of
these locations are correct.  People notice, and it makes us maintainers
look incompetent and stupid.

My impression is more that it's the presence of the diagnostics, not the line numbers in the diagnostics, that are makes us developers look "incompetent and stupid" (I would say "spread too thin" but maybe that's just me :-).

And even if this were a public-relations issue that could be fixed by proper line numbers (an assertion I'm skeptical of), I proposed a solution that will work for this particular issue and won't involve slowing down Emacs significantly in ordinary use, namely, use a separate Emacs binary for batch byte compiling when bootstrapping.

I too have played with the idea to redefine eq, for a different purpose
(so that bignums behave more like fixnums), and I gave it up because of
similar slowdowns. It wasn't worth the cost there either.
No doubt, you found some alternative.

Sure, and my alternative then was to live with Emacs as it is. That's preferable to making Emacs significantly slower for a relatively minor benefit.

Bug #9109 could be fixed by a read variant that returns
symbols-with-positions, by changing the byte-compiler to understand
the output of this read variant, and by having the byte compiler
remove position information before passing a subexpression to a macro.
That wouldn't work.

It would work for the test case in Bug#9101. It no doubt would not work for some other examples. The point is that it's not clear (to me, at least) what the scope of the problem is, and we don't seem to be making progress on delineating the scope, and without knowing the scope it's hard to suggest or evaluate alternative solutions.

scratch/accurate-warning-pos is looking like the only
pracaticable solution to these many bugs.  It is a bad solution, yes,
but there are no good ones, and it is the least bad from what's

All in all the status quo is preferable to scratch/accurate-warning-pos. Although I don't expect you to agree with me on this, I don't think I'm alone in having concerns about the significant performance issues here.

reply via email to

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