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: Sun, 04 Dec 2016 09:12:13 -0800 Message-ID: <87y3zvehzm.fsf@dancol.org> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> <834m2nplmb.fsf@gnu.org> <83inr2oje6.fsf@gnu.org> <83bmwuogfb.fsf@gnu.org> <878trydrbo.fsf@red-bean.com> <83a8cem1eq.fsf@gnu.org> <83fum3lmag.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480871587 10850 195.159.176.226 (4 Dec 2016 17:13:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Dec 2016 17:13:07 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: kfogel@red-bean.com, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 04 18:13:03 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 1cDaLV-0001yP-KI for ged-emacs-devel@m.gmane.org; Sun, 04 Dec 2016 18:13:01 +0100 Original-Received: from localhost ([::1]:35149 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDaLZ-0008I5-Af for ged-emacs-devel@m.gmane.org; Sun, 04 Dec 2016 12:13:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60359) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cDaKy-0008H6-GN for emacs-devel@gnu.org; Sun, 04 Dec 2016 12:12:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cDaKx-0004ok-C6 for emacs-devel@gnu.org; Sun, 04 Dec 2016 12:12:28 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:57624) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cDaKx-0004mp-18; Sun, 04 Dec 2016 12:12:27 -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:Date:References:In-Reply-To:Subject:Cc:To:From; bh=rh6sZVJdI75L4dAbtZPVtzD0DKnJYHDqv94QaJuyTxk=; b=LRmLlB8yNQJahrAeW8h5hyL1A+C9JNfeS4Hitnc5ol1fliXvLSPLkVp4s5a+dUB7+VsKgo8ErOc0uEoOdTrATwFtOtVQ+4eHMZADynPK7Tt1Gmp9ZCjyDBuzma79H9K2Tuu04yW6P6Gc6zC3gTfgtqYlK6cADUo2kfb4uztN9VY74qwPYVTS/NGvVEu3+52kcuZ/QZfWvfEwz+m8ogOUfQ/33Nv7Zo25831uPW02zS+A6nFPtVPtPkIc7tXDQfg45pFQbQgQiz86VYJzscqBxC4c1md95MOYtCgt+TZEq/KPJ9/2yL1QYivT6mOqwWz507WDqcZaddRDZumtCiSiPg==; Original-Received: from [2601:602:9802:d9d1:2026:72b9:2371:2501] (helo=xyzzy) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cDaKp-0001TJ-EO; Sun, 04 Dec 2016 09:12:19 -0800 In-Reply-To: <83fum3lmag.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 04 Dec 2016 17:57:27 +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:210027 Archived-At: On Sun, Dec 04 2016, Eli Zaretskii wrote: >> From: Richard Stallman >> CC: kfogel@red-bean.com, emacs-devel@gnu.org >> Date: Sat, 03 Dec 2016 16:28:58 -0500 >> >> You have explained a possible drawback of the portable dumper: >> it could make maintenance more difficult some years from now. >> >> No one can doubt that this is a possibility. People do disagree about >> how much of a problem it is likely to be. Many of us don't expect it >> will make a big difference. You forecast that it could. > > Thank you for acknowledging that this is a possibility. I was under > the impression that my opponents didn't agree. You're misinterpreting this "agreement". Nobody else agrees that a a significant maintenance burden is likely. This is how FUD starts. >> But you've got to admit that it is uncertain. We're all making >> guesstimates about probabilities. > > IMO, dangerous outcomes should be taken seriously even if their > probability is low, as long as it's non-zero. The people who moved humanity forward were not the ones huddling in caves afraid of the mammoths outside. We're talking about software. Anything we do, we can undo. (And please, stop suggesting that we have some kind of duty to keep master absolutely stable because someone, somewhere might make a master snapshot tarball available for something. Why do we even have releases?) > "Taken seriously" means > we should do something to try to avoid the danger. That is what I'm > trying to do: find a solution for the problem that will avoid the > danger. You keep saying that you'd prefer a "solution" that "avoids" the "danger". There *is* no solution that avoids the "danger" you've highlighted, which is the mere addition of C code. (No other free software project views C code as a "danger" to be avoided at all costs.) Your preferred approach, a magically faster lread, *will* *also* *involve* *C* *code*. It will *also* require knowledge of Lisp layout, since what lread does is transform text into Lisp objects. It will *also* need touchups when we add new lisp objects. The idea that your preferred fast lread (which, again, does not actually exist) would be a fine, but that the portable dumper is a "danger" --- it makes no sense. Your arguments against the portable dumper apply also to lread. Please don't tell me that lread is qualitatively different because it's existing functionality or something: you're talking about complex, disruptive additions to lread code, and that these additions would go into a C file that already exists instead of one that doesn't is immaterial. >> So if we install the portable dumper, please don't treat it as a >> certain disaster. > > The "disaster" is not the installation of the dumper. The disaster I > alluded to would be not to try to find a solution that minimizes the > above danger. If we have tried our best and failed, then it's not a > disaster, it's life: after all, we can only make the best use of the > cards we've been dealt. We've known about unexec problems for years and nobody's come up with a workable alternative. Please stop obstructing progress because you wish it weren't so. The biggest danger here is that you get your way, block progress, and that we're stuck with unexec and fragile hacks for many more years.