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 19:07:43 +0300 Message-ID: <83d339cm5s.fsf@gnu.org> References: <50191B54.2070705@yandex.ru> <5019FE2D.2060005@yandex.ru> <87a9ydbzwf.fsf@uwakimon.sk.tsukuba.ac.jp> <501A3079.5040905@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1343923724 4824 80.91.229.3 (2 Aug 2012 16:08:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 2 Aug 2012 16:08:44 +0000 (UTC) Cc: stephen@xemacs.org, 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 18:08:44 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 1Swxx3-0001fu-LR for ged-emacs-devel@m.gmane.org; Thu, 02 Aug 2012 18:08:41 +0200 Original-Received: from localhost ([::1]:43370 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swxx2-0000vx-TV for ged-emacs-devel@m.gmane.org; Thu, 02 Aug 2012 12:08:40 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swxww-0000vL-5u for emacs-devel@gnu.org; Thu, 02 Aug 2012 12:08:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Swxwu-0003ZI-QE for emacs-devel@gnu.org; Thu, 02 Aug 2012 12:08:34 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:56024) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Swxwu-0003Z1-Hb for emacs-devel@gnu.org; Thu, 02 Aug 2012 12:08:32 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M8400E00XNH0F00@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Thu, 02 Aug 2012 19:07:50 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M8400DJGY52ILC0@a-mtaout22.012.net.il>; Thu, 02 Aug 2012 19:07:50 +0300 (IDT) In-reply-to: <501A3079.5040905@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.172 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:152122 Archived-At: > Date: Thu, 02 Aug 2012 11:47:05 +0400 > From: Dmitry Antipov > Cc: Stefan Monnier , emacs-devel@gnu.org > > I agree, but only when the feature is more or less isolated (like > BIDI, IIUC). How can you consider "isolated" a feature that invades every little corner of the Emacs display engine? Can you imagine an Emacs with broken redisplay being used by someone? xdisp.c, the main source file that implements the display engine, weighs in at almost 30K lines. Given that size, the probability of someone else fixing a bug in the same file is not negligible. I just counted several dozens of changes made in xdisp.c while I was working on a branch. And still the amount of clashes was small, see my other mail. > 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. Once you make the initial pass over the sources and replace direct access with getters and setters, the merges that will bring you code that uses direct access will be few and far apart, since the bulk of Emacs code doesn't change. Moreover, the compiler will flag those places right away. So fixing the few build failures introduced by merges should be simple and fast. A few minutes devoted to that every week or so is not a high price to pay. > 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). I don't think this will work, not in Emacs, anyway. We don't have here enough discipline or omniscient team leaders to enforce this kind of order. People _will_ do what you don't want them to, and they _will_ bump into bugs, and then will blame you. The trick I used to spare users from potentially unstable code (when I merged the bidi branch onto the trunk, after 1.5 years of working aside) was to have a variable, whose default was OFF, that allowed me to switch the new code on or off. After a while, a few well-meaning people started running with that variable ON and reported the problems they saw; but the vast majority of people who track the development were never exposed to the bidi code, until I considered it stable enough to be used by default. This way (or something similar) will allow you to avoid annoying people by unstable code. So you could develop the entire thing on a branch, until all of its main pieces are in place, then merge to the trunk (perhaps after some peer review, to make sure the overall design and implementation are good enough), and continue development and debugging on the trunk, having the new code switched off by default until it's deemed ready for prime time. > 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. Then make these changes on a branch, one by one, until everything is in place. > 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. What is impossible with houses, is fortunately possible with a dVCS ;-)