From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Tue, 29 Nov 2016 11:03:35 -0800 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480446294 5242 195.159.176.226 (29 Nov 2016 19:04:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2016 19:04:54 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 29 20:04:49 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 1cBnhu-0000Zj-PB for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 20:04:47 +0100 Original-Received: from localhost ([::1]:38838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBnhy-0004q8-Jw for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 14:04:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBngu-0004ox-Du for emacs-devel@gnu.org; Tue, 29 Nov 2016 14:03:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBngt-0000GC-7N for emacs-devel@gnu.org; Tue, 29 Nov 2016 14:03:44 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:54636) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBngs-0000G5-Tm; Tue, 29 Nov 2016 14:03:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References:Subject:Cc:To:From; bh=jnjZlJXPtEcVA1Ny0Ya6GufrpMPNWCwdPLyGF3xzQwk=; b=iF4OU/lyjU8a+dCK4PEkw3vTvYkRGWcGAxL5Wd8S3sWk9ZeJdt/Hp+2Ocigp85C/o6eVPyYc4sP2T7w8hYH0HVLMFIJAZTg+n2V1pvOzWatdXoTwItZsE0EIGYq+aeSb+1m9Lzq1t+fgwsjyPrMWs4xNStpZ24z3dp7VvqH5NNix9z8j6aF7rQ9TaawKskkmdMASg47Y1WnEkOCdB5x7Ucllbx4CwQSRt60fS9oJiLzKeJ0cRWwpkrpMdcOQ5tl6C6ZQx385QZ33uPnXK7okoskOqBEszwZPxsHHlPRj+i/jwhv4tfAFlfixCjd+6sxy4yN6Oj+Io2e6wuO9lTOyFg==; Original-Received: from [2620:0:1008:1101:a803:88c3:331:8b1] (helo=dancol-glaptop0) by dancol.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2) (envelope-from ) id 1cBngr-0003KL-PG; Tue, 29 Nov 2016 11:03:41 -0800 In-Reply-To: <8360n6ruzu.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 29 Nov 2016 20:39:17 +0200") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:209753 Archived-At: On Tue, Nov 29 2016, Eli Zaretskii wrote: >> 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. Who do you imagine maintaining Emacs? CS 101 students? We have to assume a certain baseline level of skill on the part of our future colleagues. I don't want to dumb down our implementation for the sake of people we don't know and who, for all we know, may never actually appear. > 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. I've discussed before why I think this argument is ill-founded. We already have examples over the past few years of people who've familiarized themselves with Emacs internals in order to add a feature they want. If there's a need, people will familiarize themselves with the editor. Please, present some evidence that the reason we've seen a decline in core contributions due to the complexity of the current codebase. I don't agree that we'd see more contributors appear if we simplified our algorithms. On the contrary, making Emacs slower will drive users away. The solution to the problem you're raising is better internals documentation, not oversimplification. > 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. I agree that what *can* be done in Lisp should be done in Lisp. We're talking about a facility that doesn't fall under this general guideline. It's the job of the C core to provide to Lisp facilities necessary to implement higher-level features. Fast startup is one of these platform facilities, one very common in other Lisp systems. >> 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. Like what? The last two new types in core have been finalizers and the module thing, both of which have been trivial Lisp_Misc types. By the way: it's very easy to add support for new object types to pdumper. Have you read the code? There are certain types of object that are especially easy to support: Do you have a pseudovector with no non-Lisp allocations? Adding support to pdumper for this object type is one line of code. Do you have a pseudovector that you want to come back from dumps "dead", like frames? Adding support to pdumper for this object type is one line of code. How many new objects types are we going to add that don't fall under one of these two categories? You're optimizing for hypotheticals at the expense of the concrete present. > >> 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. So move more functionality to Lisp. We've done a good job of doing that lately. We're talking about a special case. You can't move eval to Lisp either. If you want to pursue this path, how about moving redisplay to Lisp? You know more about redisplay than anyone else around, I think, and redisplay is a much hairier blob of C code than the portable dumper is. >> 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. Yes, but the data structures that we create via loadup don't all have easy-to-digest Lisp representations, and creating them is on the same level of complexity as the portable dumper. *This* code exists. Where is the hypothetical sufficiently-fast lread?