From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Wed, 30 Nov 2016 13:06:47 -0800 Organization: UCLA Computer Science Department Message-ID: <340e162e-a0dc-982c-ec0d-59ecc7bb73b9@cs.ucla.edu> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> <0839b53b-4607-144f-3746-db054a29c1cd@cs.ucla.edu> <83zikiqdu5.fsf@gnu.org> <834m2orkhn.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1480540022 9036 195.159.176.226 (30 Nov 2016 21:07:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 30 Nov 2016 21:07:02 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 Cc: dancol@dancol.org, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 30 22:06:58 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 1cCC5i-0001vk-Fw for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2016 22:06:58 +0100 Original-Received: from localhost ([::1]:46624 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCC5m-00024w-B3 for ged-emacs-devel@m.gmane.org; Wed, 30 Nov 2016 16:07:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCC5d-00023o-TY for emacs-devel@gnu.org; Wed, 30 Nov 2016 16:06:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCC5d-0004Mb-1R for emacs-devel@gnu.org; Wed, 30 Nov 2016 16:06:53 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37656) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cCC5Z-0004LV-9B; Wed, 30 Nov 2016 16:06:49 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 694F016006D; Wed, 30 Nov 2016 13:06:48 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id d3kqKEHSyYWg; Wed, 30 Nov 2016 13:06:47 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A463A16006B; Wed, 30 Nov 2016 13:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Xb59ZCWhW6mf; Wed, 30 Nov 2016 13:06:47 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 8D128160075; Wed, 30 Nov 2016 13:06:47 -0800 (PST) In-Reply-To: <834m2orkhn.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 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:209836 Archived-At: On 11/30/2016 08:38 AM, Eli Zaretskii wrote: > you didn't like this same idea very much Yes and I still don't like it much, and if someone implements a better solution I will be happy to advocate replacing the currently-proposed approach with a better one. The Emacs dumping scheme has always been and will remain private and Emacs-version-specific, so we will have a lot of flexibility here. In the meantime, if the currently-proposed approach works and is fast, I see no reason to reject the contribution, or to delay it indefinitely by putting it into some branch that nobody looks at. If the patch adequately fixes a real and growing problem and we have no other working fix, we should install it into the master branch. >> from what I can see, the C pipeline is by no means empty. > Well, it somehow becomes all but empty on the other end. Sure, maybe 40 years from now C programmers will be history! That is no reason for us to reject a patch that we need today. If we want to switch the Emacs core from C to some other programming environment, fine. We can think about doing that and we will have plenty of time to think. In the meantime, the core can and should assume C. Every solution to this more-urgent problem will involve some C hacking, and that's OK.