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: Mon, 28 Nov 2016 22:31:23 +0200 Message-ID: <83wpfnxs6c.fsf@gnu.org> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480365138 25359 195.159.176.226 (28 Nov 2016 20:32:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 20:32:18 +0000 (UTC) Cc: dancol@dancol.org, emacs-devel@gnu.org To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 28 21:32:12 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 1cBSax-0005Qz-HZ for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 21:32:11 +0100 Original-Received: from localhost ([::1]:32915 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBSaz-0003vs-RL for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 15:32:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45422) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBSaN-0003vj-IE for emacs-devel@gnu.org; Mon, 28 Nov 2016 15:31:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBSaI-00080P-OD for emacs-devel@gnu.org; Mon, 28 Nov 2016 15:31:35 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48657) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBSaI-00080K-Lb; Mon, 28 Nov 2016 15:31:30 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3806 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1cBSaG-0001iX-VM; Mon, 28 Nov 2016 15:31:30 -0500 In-reply-to: (message from John Wiegley on Mon, 28 Nov 2016 12:20:41 -0800) 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:209692 Archived-At: > From: John Wiegley > Cc: Daniel Colascione , emacs-devel@gnu.org > Date: Mon, 28 Nov 2016 12:20:41 -0800 > > >>>>> "EZ" == Eli Zaretskii writes: > > EZ> Thanks for your efforts, but I think this is a wrong direction, that will > EZ> eventually get us into the same problem we have with unexec: the need to > EZ> know and depend on intimate details of relocations, memory allocation, > EZ> etc. On top of that, adding Lisp objects will now require writing its > EZ> dumper back-end, so this will be a constant maintenance burden of the kind > EZ> that only a few of us can bear. > > Is there a way to get away from such a requirement, Eli? Yes, by loading Lisp code directly. > If I understand Daniel's contribution, he's proposing the equivalent of a > program loader for Emacs Lisp byte-code, stored within what amounts to a > custom object file format. No, it's not only the byte code, its the entire state of Emacs after loading that byte code and initializing variables and subroutines not in Lisp. IOW, all of the Lisp objects in the entire heap, no matter where they came from.