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

[Chong Yidong <cyd@gnu.org>]

Dmitry Antipov <dmantipov@yandex.ru> writes:

>> I think FSET/WSET/PSET/PGET/etc should be removed from the trunk, at
>> least for now.  I recommend moving the generational GC work to a branch.
>
> Look at the size of changes I did just for a few days. This is just a
> preliminary changes needed to implement write barriers on top of them.
> Each pointer store is a subject to handle; most probably each source
> file will be affected. I suppose that new GC tree will look so different
> so the final merge will be a tremendous task on a few weeks. So I'm
> thinking about 2-stage approach: preliminary work is in trunk (where
> it might be used for concurrency branch and other development), and
> new GC (barriers and core GC bits) is in branch.

Isn't the point of Coccinelle to make it possible to transform the code
with minimal manual intervention?  With the Coccinelle scripts you've
written and committed, it shouldn't matter *when* we pull the trigger to
transform the direct accesses into *VAR macros.  This will mitigate the
problem that "new GC tree will look so different so the final merge will
be a tremendous task".  If the new GC tree starts out with the same code
transformations, the merge would involve running Coccinelle on the old
tree, then doing a diff between the result and the GC branch.

Obviously, you've been the one doing all the heavy lifting on this task,
so maybe this is an over-simplification.  But if running the Coccinelle
scripts is straightforward enough, I really think it would be better to
postphone implementing its changes on the actual code in the trunk.

By the way, would you eventually need a macro for the common Vfoo = bar
case?