emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIEL


From: Chong Yidong
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames.
Date: Wed, 08 Aug 2012 15:22:02 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux)

Dmitry Antipov <address@hidden> writes:

> Development (and politics) is the art of the possible, and we have those
> tools which are. I investigated this area, and I believe that coccinelle
> is good enough to be used in our work; finally, I don't see the practical
> reasons to wait until someone develops a wunderwaffe like GCC plugin
> for automatic barrier insertion on any critical pointer stores.

Absolutely, but that does not mean this has to be done in the
development trunk for what is supposed to go into Emacs 24.2.  Yes,
we've stated that the trunk is open for new features, but there's no
conceivable universe in which a generational GC will be ready for 24.2.
So even if these macros ultimately prove necessary, right now it's doing
nothing but introducing lots of code churn that does nothing but hamper
bugfixing by making it difficult to compare 24.1 and 24.2 code.

I see that you got rid of FGET, PGET and WGET, presumably in response
due to Stefan's concerns (with which I agree).  I think the FSET, WSET
etc. macros are similarly inappropriate, and should also be reverted.
Will you do so?

This work is best done in a branch.  After all, the *GET/*SET macros are
straightforward to apply again once we need them.  Working in a branch
will also let you get more quickly to the problem of the GC itself,
which is presumably the non-trivial part.



reply via email to

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