From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames. Date: Thu, 02 Aug 2012 18:34:15 +0300 Message-ID: <83fw85cnpk.fsf@gnu.org> References: <50191B54.2070705@yandex.ru> <5019FE2D.2060005@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1343921677 18524 80.91.229.3 (2 Aug 2012 15:34:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Aug 2012 15:34:37 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 02 17:34:33 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SwxQ0-00088a-Pt for ged-emacs-devel@m.gmane.org; Thu, 02 Aug 2012 17:34:32 +0200 Original-Received: from localhost ([::1]:52157 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwxQ0-0006Uy-57 for ged-emacs-devel@m.gmane.org; Thu, 02 Aug 2012 11:34:32 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40855) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwxPu-0006Sl-Gf for emacs-devel@gnu.org; Thu, 02 Aug 2012 11:34:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwxPt-0008Od-AW for emacs-devel@gnu.org; Thu, 02 Aug 2012 11:34:26 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:54465) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwxPt-0008OR-1M for emacs-devel@gnu.org; Thu, 02 Aug 2012 11:34:25 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0M8400400WGI9M00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Thu, 02 Aug 2012 18:34:23 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M84004Q6WLAC700@a-mtaout20.012.net.il>; Thu, 02 Aug 2012 18:34:23 +0300 (IDT) In-reply-to: <5019FE2D.2060005@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:152118 Archived-At: > Date: Thu, 02 Aug 2012 08:12:29 +0400 > From: Dmitry Antipov > Cc: emacs-devel@gnu.org > > On 08/02/2012 03:52 AM, Stefan Monnier wrote: > > > Then, please undo your changes. The INTERNAL_FIELD part is fine, but > > the new FVAR, WVAR, ... are not. Maybe it can be useful as an > > intermediate step on some separate generational-gc branch, but it > > doesn't have its place in trunk: > > Look at concurrency branch. Everyone agrees that this is an interesting > and useful feature, but no one wants to handle an endless merging efforts. I cannot speak for Tom and the concurrency branch, but in my experience the merging is almost a non-issue. > Again, this is a kind of chicken-egg problem: it's very hard to design > GC bits without supporting infrastructure implemented, and no one wants > to deal with obfuscated internal things in the absence of visible > advantages provided by new GC. IMHO the only solution is to suffer > some obfuscation until it becomes really useful. In general, at least in this project, if a feature needs to be developed incrementally over a significant time period, then it is better to do it on a branch, and then merge it onto the trunk when it is more or less ready and stable. Experience taught me that this paradigm minimizes friction with people who just want to track the latest code, but not be alpha-testers for unstable new features in the core that cannot be easily turned off.