From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109327: Generalize INTERNAL_FIELD between buffers, keyboards and frames. Date: Wed, 08 Aug 2012 15:46:05 +0800 Message-ID: <87628tj076.fsf@gnu.org> References: <50191B54.2070705@yandex.ru> <5019FE2D.2060005@yandex.ru> <87r4rigihu.fsf@gnu.org> <502211C4.1010404@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1344411981 354 80.91.229.3 (8 Aug 2012 07:46:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Aug 2012 07:46:21 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Aug 08 09:46:22 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 1Sz0yD-0000oW-KX for ged-emacs-devel@m.gmane.org; Wed, 08 Aug 2012 09:46:21 +0200 Original-Received: from localhost ([::1]:45419 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sz0yC-0000l1-VJ for ged-emacs-devel@m.gmane.org; Wed, 08 Aug 2012 03:46:20 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sz0y5-0000kn-IK for emacs-devel@gnu.org; Wed, 08 Aug 2012 03:46:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sz0y4-0000Ex-FZ for emacs-devel@gnu.org; Wed, 08 Aug 2012 03:46:13 -0400 Original-Received: from mail-pb0-f41.google.com ([209.85.160.41]:63013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sz0y4-0000Ep-7r for emacs-devel@gnu.org; Wed, 08 Aug 2012 03:46:12 -0400 Original-Received: by pbbjt11 with SMTP id jt11so1146826pbb.0 for ; Wed, 08 Aug 2012 00:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=7um9qbJq89n7uiXXWK2uV0BM8urpZX5nrh+Kt5lEs9k=; b=dpaDTGJ4WVq9IutE8cA+WYiVW2Zzoh2Bui66d3KiieZnFJNR32zLqOT0Y3StBvC2Ny CNaBpeKr3g/yx40tKGwdhfc4Hi8YchWG6jEiE9IYKI6OG9+Ed1w5r6cppV0+2cNG4K03 v05tIt72DypBZTGa7JtVR782SkcVgs6sNmiz79cXM0cbuU5mwi+m4DlutfhYTV1B3V7O BhsvF5ow2AU+1LCHa9wo3KWrl6Zb9tZ6BQE6qWJvaPTL+aKvuWjSOQPxSzM1xgo8FQi8 idZ4q7lAR8yzBHAYk5qFCI1i5qgQf/I9XnL34PuGEuSm0CZkehUxvoWw6Of2d04JmmkK h3wQ== Original-Received: by 10.68.197.70 with SMTP id is6mr33949712pbc.64.1344411971392; Wed, 08 Aug 2012 00:46:11 -0700 (PDT) Original-Received: from ulysses ([155.69.17.198]) by mx.google.com with ESMTPS id ph1sm12877053pbb.45.2012.08.08.00.46.08 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 00:46:10 -0700 (PDT) In-Reply-To: <502211C4.1010404@yandex.ru> (Dmitry Antipov's message of "Wed, 08 Aug 2012 11:14:12 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.160.41 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:152324 Archived-At: Dmitry Antipov 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?