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:22:02 +0800 Message-ID: <87y5lpvof9.fsf@gnu.org> References: <50191B54.2070705@yandex.ru> <5019FE2D.2060005@yandex.ru> <501B8C48.3000704@yandex.ru> <501C1F4D.5010007@cs.ucla.edu> <501D4E6F.6040702@cs.ucla.edu> <501E8B4B.3000805@yandex.ru> <501FAE02.80703@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1344410541 21635 80.91.229.3 (8 Aug 2012 07:22:21 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 8 Aug 2012 07:22:21 +0000 (UTC) Cc: Paul Eggert , 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:22:21 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 1Sz0au-0005Dq-57 for ged-emacs-devel@m.gmane.org; Wed, 08 Aug 2012 09:22:16 +0200 Original-Received: from localhost ([::1]:36717 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sz0at-0003Jm-0c for ged-emacs-devel@m.gmane.org; Wed, 08 Aug 2012 03:22:15 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49875) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sz0ap-0003AG-UF for emacs-devel@gnu.org; Wed, 08 Aug 2012 03:22:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sz0ao-00027O-2T for emacs-devel@gnu.org; Wed, 08 Aug 2012 03:22:11 -0400 Original-Received: from mail-pb0-f41.google.com ([209.85.160.41]:41985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sz0an-00026x-Sz for emacs-devel@gnu.org; Wed, 08 Aug 2012 03:22:10 -0400 Original-Received: by pbbjt11 with SMTP id jt11so1110861pbb.0 for ; Wed, 08 Aug 2012 00:22:09 -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=kkSAyNTh5x+J3/qEq30fVxy7T8FStTNaCYyrdKREOIc=; b=xhBuRUjY4NumBv1Kn2tYxAZ2SZAFyWowk/MQs7DQSDCW/YYvg+oHzRWo/moYg/vui0 TzKT/N78nOCiX2CRvk2OqrpsjxzI79YZZFuq7hNErc10AU4iKfcly+gIrt67HPN5ej0C 9maWVj1hLCHHaUFQcpPeMY6T8+dAIGRuIh4H/0bNIHpO3nQHmgF5pNhp+0xj7PDX9Ye4 M3jCTVXyEhOiv3wBn4CnXY61r56Q0B4eCkerewWM9FOI5wxAgCc2psyZQ7p7m9PIpi9a ctreKvoB9TdyRH8GG66ImNS7WSQ6ycHn5Dy9FM7Y1nB8+l7hnHAa8Ao01kXZyLJv4zoP 7qJg== Original-Received: by 10.68.193.196 with SMTP id hq4mr29338531pbc.32.1344410528885; Wed, 08 Aug 2012 00:22:08 -0700 (PDT) Original-Received: from ulysses ([155.69.17.198]) by mx.google.com with ESMTPS id gv1sm1825456pbc.38.2012.08.08.00.22.05 (version=SSLv3 cipher=OTHER); Wed, 08 Aug 2012 00:22:07 -0700 (PDT) In-Reply-To: <501FAE02.80703@yandex.ru> (Dmitry Antipov's message of "Mon, 06 Aug 2012 15:44:02 +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:152323 Archived-At: Dmitry Antipov 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.