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: Thu, 01 Dec 2016 20:09:16 +0200 Message-ID: <834m2nplmb.fsf@gnu.org> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480615803 12565 195.159.176.226 (1 Dec 2016 18:10:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Dec 2016 18:10:03 +0000 (UTC) Cc: dancol@dancol.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 01 19:09:56 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 1cCVnw-0002Aw-61 for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 19:09:56 +0100 Original-Received: from localhost ([::1]:58099 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCVo0-0007cN-04 for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 13:10:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCVnR-0007c6-VP for emacs-devel@gnu.org; Thu, 01 Dec 2016 13:09:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCVnP-0007Ne-98 for emacs-devel@gnu.org; Thu, 01 Dec 2016 13:09:25 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53364) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCVnP-0007NO-6B; Thu, 01 Dec 2016 13:09:23 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4311 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cCVnH-00076k-0T; Thu, 01 Dec 2016 13:09:16 -0500 In-reply-to: (message from Richard Stallman on Thu, 01 Dec 2016 04:18:03 -0500) 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:209886 Archived-At: > From: Richard Stallman > CC: dancol@dancol.org, emacs-devel@gnu.org > Date: Thu, 01 Dec 2016 04:18:03 -0500 > > I sympathize with your general point, but I don't think it is > conceivable to make Emacs's C code much simpler or easier to maintain > than it is now. I agree. However, this is not about making existing code simpler. It's about _adding_ more C code, where an alternative implementation might allow doing that without such additions. > Also, I don't think the portable dumper would increase the conplexity, > not if it is written cleanly. It's a new and significant mechanism, which is central to building and starting Emacs. It needs to be studied, understood, and maintained. Therefore, it does increase the complexity. You might argue that the increase in complexity is not significant enough to worry about, but it's definitely there. > To increase the _number_ of modules that look at Lisp objects with a > given level of complexity does not increase the complexity. It's not just the number of modules, it's what they do with the objects. The dumper does qualitatively different things, unlike any other module in Emacs. It's not just "more of the same". > When changing the data structures, it is no harder to update 4 > places than 3 places. It adds a little more work, but it isn't > _harder_ work. Well, if I need to do more work, the job is harder. > I conclude that the portable dumper won't make it any harder to > find people to work on the C code. I agree with that conclusion. However, my problem is that, since finding such people is already hard, making more Emacs modules depend on that might expose us to more future maintenance problems than if we don't. Especially if those modules are so central to Emacs as the one being discussed here.