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

[Alan Mackenzie <acm@muc.de>]

Hello, Michael.

On Sat, Dec 01, 2018 at 18:44:27 +0100, Michael Heerdegen wrote:
> Alan Mackenzie <acm@muc.de> writes:

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

> FWIW I really appreciate your efforts, and I hope the final state will
> not be to leave the bug unfixed.

Thanks!

> But I must also admit that the slowdown is a high price, a price that is
> in a similar region of annoyance than the bug itself (depending on
> personal preferences).  I really wished we could find an acceptable way
> to soften the slowdown.

Going back to Paul's idea of a "double interpreter", how about the
following strategy (I don't know enough about the subject even to know
if it's a reasonable idea)?

We build "bulky" Emacs using the scratch/accurate-warning-pos
definitions of EQ, NILP, etc.  We then build "slim" Emacs using the
traditional definitions of EQ, NILP, etc., such that functions'
addresses are the same in both versions.

At runtime, when we want to byte compile, get the operating system to
switch the mapping of code virtual addresses to the "bulky" code
segment.  When this is complete, we switch back again.

Or something like that.

Is this feasible?

> Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).