From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov 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 11:47:05 +0400 Message-ID: <501A3079.5040905@yandex.ru> References: <50191B54.2070705@yandex.ru> <5019FE2D.2060005@yandex.ru> <87a9ydbzwf.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1343893498 10912 80.91.229.3 (2 Aug 2012 07:44:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Aug 2012 07:44:58 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 02 09:44:57 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 1Swq5X-0002Qu-Ot for ged-emacs-devel@m.gmane.org; Thu, 02 Aug 2012 09:44:55 +0200 Original-Received: from localhost ([::1]:47953 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swq5X-0000Ab-57 for ged-emacs-devel@m.gmane.org; Thu, 02 Aug 2012 03:44:55 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49734) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swq5Q-00005h-3p for emacs-devel@gnu.org; Thu, 02 Aug 2012 03:44:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Swq5P-0000R7-27 for emacs-devel@gnu.org; Thu, 02 Aug 2012 03:44:48 -0400 Original-Received: from forward4h.mail.yandex.net ([84.201.186.22]:47128) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swq5O-0000Qo-Hv for emacs-devel@gnu.org; Thu, 02 Aug 2012 03:44:46 -0400 Original-Received: from smtp4h.mail.yandex.net (smtp4h.mail.yandex.net [84.201.186.21]) by forward4h.mail.yandex.net (Yandex) with ESMTP id 8CE9C1B21802; Thu, 2 Aug 2012 11:44:44 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1343893484; bh=M6dOVQHvznhDNTiRWXx+jktO1D+DTYjPKqW345dG2PY=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=raYHmh3p4NRVsxIZ648CS1BF2sEqtjSOk4Ta4R0FSMKM9y8ago4mo5iYALO8sZ4A7 BkFFOZzbh9zoNt7soE0T3TsDx7SwMpLAAVA8MgrxdokoI/geFwlbAF/Bjzfip5Wo16 /hvigfjxfNKdK5rpJ095PmCbXKbj5f/Xv1GQ3BSg= Original-Received: from smtp4h.mail.yandex.net (localhost [127.0.0.1]) by smtp4h.mail.yandex.net (Yandex) with ESMTP id 3B4DC2C0121; Thu, 2 Aug 2012 11:44:44 +0400 (MSK) Original-Received: from 222.gprs.mts.ru (222.gprs.mts.ru [213.87.132.222]) by smtp4h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id igAOLNrD-ihAa2aoE; Thu, 2 Aug 2012 11:44:43 +0400 X-Yandex-Rcpt-Suid: stephen@xemacs.org X-Yandex-Rcpt-Suid: monnier@IRO.UMontreal.CA X-Yandex-Rcpt-Suid: emacs-devel@gnu.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1343893484; bh=M6dOVQHvznhDNTiRWXx+jktO1D+DTYjPKqW345dG2PY=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=SJb90yuYN873qoqmoYapyvQh0FqBwYvVhJ4wXEBMW9RG8EO8hC3t3x8mbrIF+x7y0 GRW3nqdMTi3yim0NnKVrD/IZJHEW59MAugb7BnR7PTL04yAnFWrRDsTusow1r+kQ02 yj63OCEYI1HqPJUzy4DsenTP9UHqvtgS2nYpUAqM= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120713 Thunderbird/14.0 In-Reply-To: <87a9ydbzwf.fsf@uwakimon.sk.tsukuba.ac.jp> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 84.201.186.22 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:152108 Archived-At: On 08/02/2012 09:56 AM, Stephen J. Turnbull wrote: > > Look at concurrency branch. Everyone agrees that this is an > > interesting and useful feature, > > I don't think that's true. Emacs needs concurrency, it's true. It's > not obvious that Emacs Lisp does. Hm, I mean not only Lisp-level threads, but also implicit concurrency like one thread per frame or similar things. > > but no one wants to handle an endless merging efforts. If we had > > the same amount of developers as involved in Linux kernel, > > It's not the number of developers, it's the customary discipline in > the community. SXEmacs has a far smaller number of developers than > GNU Emacs does, but they branch like crazy and seem to love it. Many > projects do. I agree, but only when the feature is more or less isolated (like BIDI, IIUC). Most probably new GC will introduce new limitations on how the Lisp_Objects may be used, and, unfortunately, these limitations should be enforced through the whole project _before_ new GC becomes alive for the first time. For the particular write barriers case, just one bypass is most likely to crash everything; so, barriers should be designed and implemented first, and all developers should be encouraged to remember about them and obey new limitations when writing new code or fixing an old bugs. The only reliable way to do it is to have barriers in the trunk (defined to zero-overhead no-ops in the default configuration, of course). > Merging really isn't that bad if your architecture is designed for it > and your workflow adapted to it. This is not the matter or _my_ architecture; current code base provides very poor opportunities for any GC designer, and this should be changed _before_ any useful GC improvements may be implemented. Everyone wants a new house, but nobody wants to suffer the temporary inconveniences connected with building; but (if the house is large enough) it's practically impossible to build the house somewhere else and then transport it to the final destination. Dmitry