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: Wed, 30 Nov 2016 21:12:35 -0800 Message-ID: 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> <83h96opaye.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 1480569175 29098 195.159.176.226 (1 Dec 2016 05:12:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Dec 2016 05:12:55 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 To: Eli Zaretskii , eggert@cs.ucla.edu, rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 01 06:12:50 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 1cCJfu-0006QU-Br for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 06:12:50 +0100 Original-Received: from localhost ([::1]:48142 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCJfw-0002HV-B7 for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 00:12:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42727) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCJfp-0002HF-FP for emacs-devel@gnu.org; Thu, 01 Dec 2016 00:12:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCJfm-0005ml-Qt for emacs-devel@gnu.org; Thu, 01 Dec 2016 00:12:45 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:51762) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCJfm-0005mM-Gr; Thu, 01 Dec 2016 00:12:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=2DtAFsJiB0yH9Wz/NKGTlLaQb+W+jG2XYET/k2N/nPk=; b=VA+G3YRe94uWy4bEW0PdfGBQwRgxVjJHomTvtRJVpouSeqvH4WYUgY9EksNKbXayI8ccT/XOF87BlNruQWO1SvWiefXaj13b5frXPk4KDtLHTrZcbFuQKeGNJlKThiGfA8ZrXfT/4srXn30dy3tqpynsVAHoYgeGFuziiiwroUvwaeYc2PIKFqo1cQYhF7P3hVcugmeURifpNLtpFF9cphS0WsXRUxGp1V/kNXRHleJeu5FdTdQ5cA0MViWqeOLrWgeUZ5NhvQa4kDkx8H9p7DHWBjyrSfAqH0je6hC8P4Uecz/yaEyLmPlh0BJ2GfR4RTER8aRDxYcOuwsHEh78cg==; Original-Received: from [73.109.63.69] (helo=[10.240.209.181]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cCJfl-0004rq-K1; Wed, 30 Nov 2016 21:12:41 -0800 In-Reply-To: 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:209864 Archived-At: On 11/30/2016 08:49 PM, John Wiegley wrote: >>>>>> Daniel Colascione writes: > >> If that's your decision, I'm going to fork. > > I'm quite sorry to hear it, but if branches are unacceptable, then such is > your right as a free software developer. Branches in general are fine. Relegating this specific feature to a branch feels political. I would very much prefer to continue improving GNU Emacs. I'm a longtime fan of the GNU Project. But I feel like the current gatekeepers are standing in the way of progress. We can't even make the conservative GC safe in the face of foreseeable compiler optimizations. This isn't the first time that I've gotten a flat "no" in response to a good idea. If I do fork, I can incorporate many more kinds of experimental work. One of the first things I'd consider would be an LLVM-based tracing JIT. Let me try one last time to explain my position: this dumping code will make no Emacs no worse. It cannot possible destabilize Emacs when it is compiled out of Emacs at configure-time. I specifically designed this feature to be optional. I am perfectly happy merging my code in such a way that it is not compiled into Emacs by default, and I am perfectly happy waiting until we've gotten sufficient testing before enabling the portable dumper. In the miraculous case that someone contributes an lread optimization that allows that the big-ELC approach to perform as well as a memory image, I will happily back out of my code. But because this code is harmless when compiled away and because we can back it out without problems, I see the requirement that we put this code into a branch as a way to kill the feature. If this code were more fundamentally destabilizing, I would feel different --- but as it is, since this code is *not* fundamentally destabilizing, I don't see a technical case for a feature branch. I am perfectly happy with a six month or longer timetable for enabling this code at ./configure time. I expected as much. The XEmacs experience with their portable dumper (which I have not read) was similar. I specifically designed this code to be compatible with the current implementation and to allow for a gradual transition. Is anyone else signing up to make Emacs work better on modern systems? > Just so you know, I'd hope to see your patches on master within six months, What specific conditions need to be met before merging? Why can't I meet these requirements before landing the diff? This code will never meet the "nobody has complained" requirement. It's going to have to land over some objections, because some contributors object to the very essence of the change. If there are technical requirements, why can't I meet these requirements before landing this work in master? If there are political requirements, what makes you think that a branch would help me meet them? > if > we can find some willing testers (and one has already stepped forward). The > only way your changes *wouldn't* land is if a better alternative comes along > in the meantime -- which, of course, would mean we all win. What is the fundamental difference between merging this code into mainline in a disabled-by-default configuration and merging it into a branch, except that it's much more convenient to try the feature in the former case? > > I don't suppose I can encourage you to maintain your fork within the Emacs.git > repository? There this thing, rhymes with "blanch", where you could work on > your version in tandem, even merge changes from us every once in a while... :) > There have been cries to adopt a more modern development style, one focused on GitHub and pull requests. I can certainly accommodate.