From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Patch for fields of `struct buffer' Date: Tue, 01 Feb 2011 21:42:58 -0500 Message-ID: References: <4D47DFD4.1040108@gmail.com> Reply-To: rms@gnu.org NNTP-Posting-Host: lo.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: dough.gmane.org 1296615247 5238 80.91.229.12 (2 Feb 2011 02:54:07 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 2 Feb 2011 02:54:07 +0000 (UTC) Cc: dan.colascione@gmail.com, emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 02 03:54:02 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PkSq1-0002VL-8i for ged-emacs-devel@m.gmane.org; Wed, 02 Feb 2011 03:53:57 +0100 Original-Received: from localhost ([127.0.0.1]:59070 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkSpn-0006IE-Q4 for ged-emacs-devel@m.gmane.org; Tue, 01 Feb 2011 21:52:43 -0500 Original-Received: from [140.186.70.92] (port=53823 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PkSpd-0006GD-48 for emacs-devel@gnu.org; Tue, 01 Feb 2011 21:52:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PkSgR-0002kr-Gr for emacs-devel@gnu.org; Tue, 01 Feb 2011 21:43:04 -0500 Original-Received: from fencepost.gnu.org ([140.186.70.10]:47040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PkSgR-0002kd-AP for emacs-devel@gnu.org; Tue, 01 Feb 2011 21:43:03 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.69) (envelope-from ) id 1PkSgM-0007gQ-SR; Tue, 01 Feb 2011 21:42:58 -0500 In-reply-to: (message from Tom Tromey on Tue, 01 Feb 2011 09:51:54 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.10 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:135442 Archived-At: One thing worth noting is that if the concurrency branch is a huge failure, it is simple to back out at least the buffer change. That is true. And, since there is no performance penalty possible until concurrency is actually merged, I think the risks associated with moving forward are rather low. If the new macros expand into the existing code, they won't cause a slowdown. They only make the code less natural. So why merge the macro calls into the trunk? You could put them in a branch. If you ever get preemptive threads working such that we want to install it, we could install that change then. The point of this patch series is to make it simpler to work on the other problems on a branch. That goal seems unobjectionable, but why do you need to change these calls in the trunk to be able to work on your branch? -- Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org, www.gnu.org