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

[martin rudalics <rudalics@gmx.at>]

 > Possibly.  Has anybody raised a bug report concerning (the lack of) an
 > i.c.c.?

I've been talking about annoyances not about bugs.  If, at all, people
would file a feature request disguised as a bug report for that.

 > The reaction to my work on this bug, AFTER spending many many days
 > hacking it has been uniformly hostile.  Not one reply has said "thanks
 > for fixing this bug", or anything like it.  I'm trying to think of a
 > reply which even acknowledged that a bug, a difficult bug, has been
 > fixed.

As someone who has been bitten by this bug occasionally I express my
thanks to you for your efforts.  I even have to admit that due to the
fact that line numbers are often reported incorrectly, I now never
bother to consult them in the first place but try to retrieve the
necessary information from any other context available.

But please do not judge my replies as "hostile".  I expressed my
concerns and I tried to do that at a sufficiently early stage in
response to similar concerns raised by Paul before.  And I tried to
provide a context in the sense that for me there are many annoyances
that bother me to the same extent (or even more) and where I never
would accept a slowdown as your reported.

For some years already I cannot run Emacs regularly from a debug build
because it can't keep up with my typing speed (which ironically also
gets slower day by day).  I can't yet imagine what to do when my
optimized builds slow down to a similar degree.

 > Not one reply has offered to try to help optimise the new code, rather
 > than discarding it.
 >
 > I'm not entirely sure either that those criticizing entirely understand
 > what has been fixed.  Paul E. admitted as much in his latest post.

I do _not_ criticize you and have no intentions to do that.  My
knowledge of the byte compiler is much too limited for that.

 >> I've kept quiet when the 'open-paren-in-column-0-is-defun-start'
 >> convention was abolished recently.  And I would have kept quiet in the
 >> case at hand as well.  But Eli once said that people should complain
 >> _before_ a change is made and so I did.
 >
 > Nobody complained before I put in 50 - 100 hours of work fixing the bug.
 > Or if they did, I wasn't listening.  Perhaps if they had, I might have
 > not bothered fixing it, given that people don't really seem to want it
 > fixed anyway.

You did not say in advance what people would have to pay for the fix.
And IIUC even you didn't know the price when you started coding.

 > The solution to this bug would be the same regardless of who implemented
 > it.  The improvement in performance from your changes will be the same
 > regardless of whether my bug fix is merged in or not.

Here I disagree.  If bug fixes are allowed to cause a significant
slowdown of Emacs, people will sooner or later stop improving its
performance or stop using it at all.  This is IMO reality and I hope
you don't dismiss it as yet another criticism.

 > And after my bug fix a bootstrap would still take "more than an hour".
 > You'd scarcely notice the difference.

Noticing differences and their cause is a process that may take
months.  Remember our ups and downs with xdisp.c.

 > Yes.  I haven't forgotten doing overnight builds on Emacs myself.  But
 > you also have to live with acknowledging most people's typical setup, as
 > I'm sure you do.

I do.  Although I'm probably too old to understand the philosophy of
using a retina display with reduced resolution when running Emacs.

 >>   > If you still object to this fix, even after trying it, what you are
 >>   > saying is that you prefer fast buggy software over slightly slower
 >>   > functional software.
 >
 >> I don't say that.
 >
 > You are saying that.  You're saying that the 7% - 8% or whatever slowdown
 > is more important to you than a bug free byte compiler.

If I can make the byte compiler bug free by not printing line numbers
when they are buggy with a probability of ...

 >> IMO the "byte compiler bug" has a simple fix which, however, nobody but
 >> me would accept: When there is the slightest doubt do not print
 >> position indications.
 >
 > This would mean printing no positions at all.  In a bootstrap (which I've
 > done rather a lot of, recently) only 25% of the positions output are
 > correct.  The other three quarters are junk.  Likely the pattern is
 > repeated in compilations of users' programs.  Apparently, nobody but me
 > thinks this is a Bad Thing.

... 75% then the first solution that comes to my mind is to not print
line numbers at all.  Then we have a "bug free compiler" (we all know
that such a thing does not exist, in reality).

martin