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

[Alan Mackenzie]

Hello again, Michael.

On Sat, Dec 01, 2018 at 18:58:08 +0000, Alan Mackenzie wrote:
> On Sat, Dec 01, 2018 at 18:44:27 +0100, Michael Heerdegen wrote:
> > Alan Mackenzie <address@hidden> 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)?

[ .... ]

No, I don't think that idea (snipped) was at all good.  If it could
work, it would be a security nightmare.

Instead, how about this:

We build (part of) Emacs using the scratch/accurate-warning-pos versions
of EQ, NILP, ....  Using some object code utility, we systematically
change the names of variables, constants, ......  We note the addresses
of the subrs (of which there are a mere 1450).  Call this the "bulky"
version.  We build the "slim" Emacs, then link them together into
temacs.

At run time, when we do byte compilation, we first set the function
addresses of (most of?) the subrs to the "bulky" subrs, perform the
compilation, then restore them again.

The main disadvantage would be the increased size of temacs,
approximately doubled.  The advantage would be that "normal" Emacs would
run at "full speed".

> > Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).