From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Finding the dump Date: Mon, 28 Jan 2019 17:35:51 +0200 Message-ID: <834l9s4wx4.fsf@gnu.org> References: <83munr8jb1.fsf@gnu.org> <838szb8ey9.fsf@gnu.org> <83d0oj62bc.fsf@gnu.org> <87ef8z4g1m.fsf@igel.home> <838sz75u7p.fsf@gnu.org> <877eer4e4x.fsf@igel.home> <835zub5p3i.fsf@gnu.org> <8736pf408v.fsf@igel.home> <83womq3z5c.fsf@gnu.org> <871s4yxfvb.fsf@igel.home> <83o9823xcq.fsf@gnu.org> <87womqvyy4.fsf@igel.home> <4f30b2b598e71d2c6ad766a3da8e4a33.squirrel@dancol.org> <87o982vszn.fsf@igel.home> <87k1ipx3jq.fsf@igel.home> <87bm41wzmv.fsf@igel.home> <837eep4fkj.fsf@gnu.org> <47a6df84-35b1-a85c-44be-5cec033e9255@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="218500"; mail-complaints-to="usenet@blaine.gmane.org" Cc: rpluim@gmail.com, dancol@dancol.org, schwab@linux-m68k.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 28 16:36:17 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1go8xN-000ujB-Ar for ged-emacs-devel@m.gmane.org; Mon, 28 Jan 2019 16:36:17 +0100 Original-Received: from localhost ([127.0.0.1]:33899 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1go8xM-0006ij-C2 for ged-emacs-devel@m.gmane.org; Mon, 28 Jan 2019 10:36:16 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1go8xG-0006iQ-Eb for emacs-devel@gnu.org; Mon, 28 Jan 2019 10:36:11 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52959) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1go8xD-0006M8-Dl; Mon, 28 Jan 2019 10:36:07 -0500 Original-Received: from [176.228.60.248] (port=4407 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1go8xC-0001vQ-Ir; Mon, 28 Jan 2019 10:36:07 -0500 In-reply-to: <47a6df84-35b1-a85c-44be-5cec033e9255@cs.ucla.edu> (message from Paul Eggert on Sun, 27 Jan 2019 20:13:11 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:232761 Archived-At: > Cc: schwab@linux-m68k.org, dancol@dancol.org, rpluim@gmail.com, > emacs-devel@gnu.org > From: Paul Eggert > Date: Sun, 27 Jan 2019 20:13:11 -0800 > > > I very much doubt that you could do that portably, let alone allow > > repeated dumping after the initial one. > > For repeated dumping without a C compiler present, we'd need to stick to > something like the current approach. But hardly anybody needs repeated dumping, > and those who do typically have a C compiler available, so the approach that I'm > thinking of should work for the vast majority of real-world cases. Like Daniel, I very much disagree that repeated dumping is unimportant. I think we want that capability restored very much, and I think that it will be quite popular. Having a working compiler as a prerequisite for that would be a severe limitation. > > I really don't see why we should waste our energy on making the Emacs > > package one file less (out of 3000 it already has). > > This particular file is a bigger deal than the rest because Emacs cannot run > without it. Emacs can run without all those other 3000 files. Emacs can run without them, but it is quite limited, so I don't think we should consider that a significant difference. > > It certainly isn't a "hassle". > > It's already been a hassle for us, as seen in this thread. Well, by that measure we have a lot of "hassle" in Emacs already ;-) > It will be a hassle for installers and maintainers too. I don't see why. It's just one more file in libexec, that's all. > The separate file also slows down startup compared to the approach I > have in mind. > > But you're the maintainer, so if you are opposed to the idea I'll drop it. I wouldn't tell you to drop it, certainly not without knowing more details, but in general I think we should not make any significant design changes in how the pdumper works, until we (a) stabilize what we have now (for now, a bug related to pdumper is reported roughly every other day, so we still have some fallout), and (b) collect some significant experience with it. Based on that experience, we might find good reasons to make some radical changes, but we are not there yet, and I certainly don't see any serious problems with the current design at this time, nothing that would justify yet another significant change in that area.