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: Tue, 29 Nov 2016 20:39:17 +0200 Message-ID: <8360n6ruzu.fsf@gnu.org> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480444995 14141 195.159.176.226 (29 Nov 2016 18:43:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2016 18:43:15 +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 Tue Nov 29 19:43:11 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 1cBnN0-0002iq-CR for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 19:43:10 +0100 Original-Received: from localhost ([::1]:38753 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBnN4-0006zl-4x for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 13:43:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBnJi-0005Bq-Fc for emacs-devel@gnu.org; Tue, 29 Nov 2016 13:39:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBnJf-0000Ip-DI for emacs-devel@gnu.org; Tue, 29 Nov 2016 13:39:46 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38674) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBnJf-0000Il-AI; Tue, 29 Nov 2016 13:39:43 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1142 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cBnJV-0000J8-Ua; Tue, 29 Nov 2016 13:39:36 -0500 In-reply-to: (message from Richard Stallman on Tue, 29 Nov 2016 11:55:16 -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:209749 Archived-At: > From: Richard Stallman > CC: dancol@dancol.org, emacs-devel@gnu.org > Date: Tue, 29 Nov 2016 11:55:16 -0500 > > Maintaining the portable dumper will be far simpler than maintaining > unexec. Unexec has to write a file in whatever format the system uses > for executables. If that is ELF format, it is very complicated, > and it wasn't designed for this purpose. It is necessary to copy > the material from the temacs executable, and modify it along the way. > > All those problems will be absent for the portable dumper, which > will make its maintenance much easier. Easier: yes. Easy enough: no, not IMO. Not for most of the Emacs contributors we have and will have in the near future. The number of people aboard who can matter-of-factly hack the Emacs internals on the C level is consistently going down, and is already so small they can be counted on one hand. We must make Emacs depend less on people from this small and diminishing group, if we want the development pace increased or even kept at its current level. To me, that means keep as many features out of low-level C, and limit futzing with C-level internals of Lisp objects and the Lisp interpreter to the absolute minimum. IOW, any feature that can have an alternative implementation in Lisp should not be done in C, even if the Lisp implementation will be slightly slower. > On top of that, adding Lisp objects will now require > > writing its dumper back-end, so this will be a constant maintenance > > burden of the kind that only a few of us can bear. > > Yes, but how often do we make such changes? Once every few years, > I think. More like once a year, maybe more. > And it won't be a big difficulty to do so, if the code of the dumper > is clean. For you and me, and for a few others, sure. But Emacs cannot be developed by a handful of people anymore. We already fall behind with frequency of releases, with the speed of delivering new features, with analyzing and fixing bugs reported to the tracker, etc. If we don't attract more core developers, we will never get out of this vicious cycle. And bringing C-level core developers on board is a very slow, painful, and unreliable process, because C programmers are a dying breed, and Emacs internals are not for the faint at heart. > I am sure it will be a lot cleaner than the code of unexec. I'm sure, too, but that's not the issue. > > Making the initial load of preloaded Lisp files (most probably, a > > single large file) fast enough to allow us to dump the dumping phase > > altogether is a much more perspective direction. > > I think this has its own difficulty -- the need to represent everything > in Lisp syntax. I don't think I follow: what we preload in loadup already has Lisp syntax.