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

[Alan Mackenzie <acm@muc.de>]

Hello, Martin.

On Sat, Dec 01, 2018 at 15:09:48 +0100, martin rudalics wrote:
> Hello, Alan

>  >> There are around 50 issues in current Emacs that annoy me at least as
>  >> much as wrong positions reported by the byte compiler.

>  > Likely, none of them are as difficult to address as the byte compiler
>  > bug.

> Running an incremental copying collector in a separate thread is, for
> example.

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

>  > But who's going to address them, if they can expect the reaction
>  > I'm getting at the moment?

> I've been following this thread since its beginning and I've not seen
> an unjustified reaction so far, including mine.

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.

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

>  >> If, on the average, solving any such issue took away just 2% of the
>  >> performance of my Emacs, I'd experience an overall slowdown of 100%
>  >> when solving all of them.  So please note that Paul is not alone with
>  >> his concerns.

>  > On average, solving these other bugs will cost 0% in performance.
>  > You're positing a completely unrealistic scenario.

> Right.  But mainly so because many of these 50 problems should have a
> solution in the opposite direction.  They aim at improving performance
> rather than degrading it.  For example, I spent quite some time on
> reducing the overhead associated with creating Emacs tooltip frames -
> largely unnoticed, but it saves me an entire GC cycle for every
> tooltip displayed here.  Why should I spend my time on such things if
> any gains are annihilated by solutions like yours.

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.

>  > Have you even tried scratch/accurate-warning-pos?  You've said in the
>  > past that you have a slow machine, so if that's still true, you would
>  > probably be the person to notice perceptible slowdown, should there be
>  > any.  Do you notice any slowdown with it?

> I haven't tried it.  As a rule, I bootstrap each of my Emacs instances
> once a year, after Glenn changed the file headers.  Here a bootstrap
> means that I can't use my machine for more than an hour.

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

> And that I have to either make a separate copy of my Emacs tree or do
> another bootstrap to return to the previous version.  This year I
> already made one extra bootstrap for the portable dumper and that
> consumed enough of my remaining energy for such endeavours.  You have
> to live with the fact that people like me live in a different world.

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.

>  > The byte compiler bug is extremely unusual, possibly unique, in its
>  > resistance to being resolved.  Just about every possible approach has
>  > been tried (along with several which are not possible), and only one
>  > approach, the one in scratch/accurate-warning-pos, has got anywhere at
>  > all.

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

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

> Also I don't understand why it should be the byte compiler's task to
> check the syntax of expressions for correctness.  If the byte compiler
> raises an error or new Lisp code should be compiled, run a separate
> syntax checker that gets as close as possible to the source of any
> error in the code.

That wouldn't help.  The difficulty is associating a source code position
with the (read) code, which is being steadily transformed.  This would be
the same regardless of whether the byte compiler itself or some separate
bit of code does the checking.

> And it can spend as much time on that as it needs.  But enough heresy
> here.

What takes the extra time is that EQ, NILP, SYMBOLP, and XSYMBOL have
been amended to recognize, when a flag is set, that #<symbol foo at 666>
is the same as foo.  It is the testing of that flag which takes the time,
even when it is not set.

> martin

-- 
Alan Mackenzie (Nuremberg, Germany).