Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.

[Eli Zaretskii]

> Date: Thu, 02 Aug 2012 11:47:05 +0400
> From: Dmitry Antipov <address@hidden>
> Cc: Stefan Monnier <address@hidden>, address@hidden
> 
> I agree, but only when the feature is more or less isolated (like
> BIDI, IIUC).

How can you consider "isolated" a feature that invades every little
corner of the Emacs display engine?  Can you imagine an Emacs with
broken redisplay being used by someone?

xdisp.c, the main source file that implements the display engine,
weighs in at almost 30K lines.  Given that size, the probability of
someone else fixing a bug in the same file is not negligible.  I just
counted several dozens of changes made in xdisp.c while I was working
on a branch.  And still the amount of clashes was small, see my other
mail.

> Most probably new GC will introduce new limitations on
> how the Lisp_Objects may be used, and, unfortunately, these limitations
> should be enforced through the whole project _before_ new GC becomes
> alive for the first time.

Once you make the initial pass over the sources and replace direct
access with getters and setters, the merges that will bring you code
that uses direct access will be few and far apart, since the bulk of
Emacs code doesn't change.  Moreover, the compiler will flag those
places right away.  So fixing the few build failures introduced by
merges should be simple and fast.  A few minutes devoted to that every
week or so is not a high price to pay.

> For the particular write barriers case, just
> one bypass is most likely to crash everything; so, barriers should be
> designed and implemented first, and all developers should be encouraged
> to remember about them and obey new limitations when writing new code
> or fixing an old bugs. The only reliable way to do it is to have barriers
> in the trunk (defined to zero-overhead no-ops in the default configuration,
> of course).

I don't think this will work, not in Emacs, anyway.  We don't have
here enough discipline or omniscient team leaders to enforce this kind
of order.  People _will_ do what you don't want them to, and they
_will_ bump into bugs, and then will blame you.

The trick I used to spare users from potentially unstable code (when I
merged the bidi branch onto the trunk, after 1.5 years of working
aside) was to have a variable, whose default was OFF, that allowed me
to switch the new code on or off.  After a while, a few well-meaning
people started running with that variable ON and reported the problems
they saw; but the vast majority of people who track the development
were never exposed to the bidi code, until I considered it stable
enough to be used by default.

This way (or something similar) will allow you to avoid annoying
people by unstable code.  So you could develop the entire thing on a
branch, until all of its main pieces are in place, then merge to the
trunk (perhaps after some peer review, to make sure the overall design
and implementation are good enough), and continue development and
debugging on the trunk, having the new code switched off by default
until it's deemed ready for prime time.

> This is not the matter or _my_ architecture; current code base provides
> very poor opportunities for any GC designer, and this should be changed
> _before_ any useful GC improvements may be implemented.

Then make these changes on a branch, one by one, until everything is
in place.

> Everyone wants a new house, but nobody wants to suffer the temporary
> inconveniences connected with building; but (if the house is large
> enough) it's practically impossible to build the house somewhere
> else and then transport it to the final destination.

What is impossible with houses, is fortunately possible with a dVCS ;-)