From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Tue, 29 Nov 2016 19:43:48 +0200 Message-ID: <83k2bmxju3.fsf@gnu.org> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <727ccd66-3bc3-2a41-7d1d-ef6dae9f0d1e@dancol.org> <7A914757-B1A4-4EEE-9DF0-68EFDDA9A5DB@autodesk.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480441714 26541 195.159.176.226 (29 Nov 2016 17:48:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2016 17:48:34 +0000 (UTC) Cc: dancol@dancol.org, emacs-devel@gnu.org, burton.samograd@autodesk.com To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 29 18:48:30 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 1cBmW6-0005O4-Dj for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 18:48:30 +0100 Original-Received: from localhost ([::1]:38469 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBmW5-0002pk-Fz for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 12:48:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47273) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBmRi-0008Qu-I8 for emacs-devel@gnu.org; Tue, 29 Nov 2016 12:44:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBmRe-0001hZ-J2 for emacs-devel@gnu.org; Tue, 29 Nov 2016 12:43:58 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37576) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBmRe-0001hV-FR; Tue, 29 Nov 2016 12:43:54 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1058 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1cBmRX-0006xp-Bu; Tue, 29 Nov 2016 12:43:47 -0500 In-reply-to: (message from Richard Stallman on Tue, 29 Nov 2016 11:48:40 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:209739 Archived-At: > From: Richard Stallman > CC: burton.samograd@autodesk.com, eliz@gnu.org, emacs-devel@gnu.org > Date: Tue, 29 Nov 2016 11:48:40 -0500 > > > Frame and window objects come back dead after being restored from the dump. > > Can that be fixed by creating new equivalent windows and frames? I'm actually wondering why frames and windows (and buffers, for that matter) need to be dumped at all. The fact we do that now is just an artifact of how unexec works: it dumps the entire data section. We even have special code that runs at startup to undo some of the peculiarities this causes. However, a dumper that we control by manually telling it what to dum and what not doesn't have to do that. IMO, that's just something that doesn't need to exist in the brave new unexec-free world. (Note that the "one huge .elc file" method has this built-in.)