From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Sat, 03 Dec 2016 10:48:23 +0200 Message-ID: <83zikdl7oo.fsf@gnu.org> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> <834m2nplmb.fsf@gnu.org> <83inr2oje6.fsf@gnu.org> <83bmwuogfb.fsf@gnu.org> <878trydrbo.fsf@red-bean.com> <83a8cem1eq.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480754938 18902 195.159.176.226 (3 Dec 2016 08:48:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Dec 2016 08:48:58 +0000 (UTC) Cc: kfogel@red-bean.com, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 03 09:48:53 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cD605-0003p0-Fe for ged-emacs-devel@m.gmane.org; Sat, 03 Dec 2016 09:48:53 +0100 Original-Received: from localhost ([::1]:38276 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cD609-0002ec-0P for ged-emacs-devel@m.gmane.org; Sat, 03 Dec 2016 03:48:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cD5zT-0002eW-Ve for emacs-devel@gnu.org; Sat, 03 Dec 2016 03:48:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cD5zQ-0002G3-Ta for emacs-devel@gnu.org; Sat, 03 Dec 2016 03:48:16 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43591) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cD5zQ-0002Fz-QC; Sat, 03 Dec 2016 03:48:12 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3266 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cD5zP-0002SQ-WA; Sat, 03 Dec 2016 03:48:12 -0500 In-reply-to: (message from Daniel Colascione on Fri, 02 Dec 2016 14:28:25 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:209975 Archived-At: > From: Daniel Colascione > Cc: Karl Fogel , emacs-devel@gnu.org > Date: Fri, 02 Dec 2016 14:28:25 -0800 > > We've all been contributing to Emacs for many years. I think we have a > pretty good grasp of the issues and potential problems. I understand > that you think there's an existential risk that goes into this change, > but I think you're mistaken, and a lot of other people agree. We all > have access to the same information; it's unlikely (but not impossible) > that you're the only one who can see certain potential problems. Assessment of trends and their impact on the future, with all the uncertainties involved, requires more than just processing the immediately available information. > Please give this change the benefit of the doubt. I thought I was already doing that. Isn't that why the code will be on a branch soon? > Even if your worst-case scenario comes to pass, the worst outcome > outcome will just be more fiddly maintenance. We already have such "fiddly maintenance" situation in several areas. Font selection, font back-ends, character composition, complex script shaping, and (to some extent) the interaction with X and its window managers -- all of these are areas where bugs are left for months and years without being fixed, and no progress is made to adapt Emacs to the new technologies out there. IOW, "the worst outcome" is already here. I'm desperately trying not to make it worse. > I think the pdumper code is pretty clean; I'm open to suggestions > for making it moreso. I will definitely try to keep this in mind when reviewing the code. However, code cleanness is not the main problem, based on the above examples. There's nothing unclean in the code in any of the areas I mentioned. The problems are elsewhere. > If there's no one left who can understand pdumper, there's no one > left who can understand the GC either. GC is stable for many years, and "just works". Bugs only happen there when people make changes in GC code, for benefits that are not essential. If there's no one on board who understands GC, we can simply disallow any changes in that area. By contrast, the portable dumper is new code. No matter how simple and clean, it will take some time until it becomes mature enough to raise to the current status of GC. Until that happens, we cannot afford being in the same situation as with GC. > You won't have to touch this code. I most probably will, and I have no reason to be afraid of that. But this isn't about me.