[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: Alan Mackenzie
Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.
Date: Sat, 1 Dec 2018 18:58:08 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

Hello, Michael.

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.


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

reply via email to

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