From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: compiled lisp file format (Re: Skipping unexec via a big .elc file) Date: Mon, 29 May 2017 05:33:38 -0400 Message-ID: <60D5F708-B068-4D27-8FC5-F73F6AB1C44D@raeburn.org> References: <8A8DA980-13A7-4F8B-9D07-391728C673C9@raeburn.org> <123104DD-447F-4CDB-B3A0-CED80E3AC8C9@raeburn.org> <20170403165736.GA2851@acm> <2497A2D5-FDB1-47FF-AED3-FD4ABE2FE144@raeburn.org> <83lgrhpalq.fsf@gnu.org> <0D99B4FE-FEEF-4565-87D6-E230A05DEF3C@raeburn.org> <86lgrc4vob.fsf@molnjunk.nocrew.org> <834ly0oew1.fsf@gnu.org> <968E8F50-92F6-43C7-B7E4-EE8378943087@raeburn.org> <83wpawmj4d.fsf@gnu.org> <1e397033-8291-1625-8b78-a1e1c200aea5@gmail.com> <18196f08-408d-8b17-423e-8be54507bb84@gmail.com> <8360hkkcgj.fsf@gnu.org> <26b35c16-33e7-0e08-9cc5-6f9b81e40968@cs.ucla.edu> <554fd451-8c5a-755d-1fba-a5473bf2ecfc@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1496111265 14543 195.159.176.226 (30 May 2017 02:27:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 May 2017 02:27:45 +0000 (UTC) Cc: Emacs developers To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 29 11:34:20 2017 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 1dFH42-0008DH-R5 for ged-emacs-devel@m.gmane.org; Mon, 29 May 2017 11:34:15 +0200 Original-Received: from localhost ([::1]:47763 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dFH48-0007cC-5i for ged-emacs-devel@m.gmane.org; Mon, 29 May 2017 05:34:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dFH3Y-0007c7-Sd for emacs-devel@gnu.org; Mon, 29 May 2017 05:33:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dFH3V-0007QN-M2 for emacs-devel@gnu.org; Mon, 29 May 2017 05:33:44 -0400 Original-Received: from mail-qt0-x242.google.com ([2607:f8b0:400d:c0d::242]:33717) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dFH3V-0007QF-Dl for emacs-devel@gnu.org; Mon, 29 May 2017 05:33:41 -0400 Original-Received: by mail-qt0-x242.google.com with SMTP id a46so8411361qte.0 for ; Mon, 29 May 2017 02:33:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SCo3+qhbw7Exwh0mlxHZO/4sC69pHHnm+q1JN+T/BbU=; b=tsUnkWlKvleQ+o2EE1wzcIMGEq2toeFeXF6UTGuC2epA9kfJyAqUJd1gvNToVfmrvA knTkPBVhWaFPoxXiikxqOrE79Mgw904wxObq45lOqOKg5436wi4hylVbATr7JroXNoyh R0uzNdTppskSIX+NKB32wvg67nOjas3QrDmCD3tWej5PVRxFsgHLis8vF77+eFDOWn3W vncz40vj8wOwe/WVJoM2rCdHPJCNFIZVymE4hssViIEMb5vYKAX9vHpVUH67JBJ5AAB9 v5HbgXmZInC1JiS9U51IwW7ZAp0uU0xxXp2a3mxfenTzBiEb5C9SGmktVYYuY2yta18l PS2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SCo3+qhbw7Exwh0mlxHZO/4sC69pHHnm+q1JN+T/BbU=; b=ifZCj9vbqyQirRWXoLNNULlq8paeyBzsBHKaR8H9hDCVof8gHtqSsZcwDOvLx/Ja37 NbVFwl3obltlKjPJfLq+8s21TDLrQ43rtG2XaIq383rMxgVtBq13uZFDd8A2aZt0DBR/ MLcaDPnx5Gz3v27Mh2x6c6brAfqNRmJmgziFFYOjzJ9ESndjH2jhyRFemt9V8mcMKxwG 55jHTKQ5q0tf9cOJwyaB3BOiYOorQ/nU7esCsc7gBVZWDTNeXBD03Iz1eYG/XP02quSp nZZtLemzxPQ8ySVd+RqmgdlFJC0uIglfB2uS6VYLW+TKzstV3AVcxKsH6BIf1LTNrKv0 8kAw== X-Gm-Message-State: AODbwcCfZwyGNQkn0AN60YgQmXMRupgeUI+xAKLgYYJ6cne8jawHnSwL oHOVmBF0ujns1pqb X-Received: by 10.200.53.4 with SMTP id y4mr16377432qtb.136.1496050420658; Mon, 29 May 2017 02:33:40 -0700 (PDT) Original-Received: from [192.168.23.52] (c-73-253-167-23.hsd1.ma.comcast.net. [73.253.167.23]) by smtp.gmail.com with ESMTPSA id n19sm5900502qkn.66.2017.05.29.02.33.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 May 2017 02:33:40 -0700 (PDT) In-Reply-To: <554fd451-8c5a-755d-1fba-a5473bf2ecfc@cs.ucla.edu> X-Mailer: Apple Mail (2.3124) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c0d::242 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:215335 On May 28, 2017, at 17:09, Paul Eggert wrote: > Ken Raeburn wrote: >> I think Guile is using whatever the native word size and architecture = are. If we do that for Emacs, they=E2=80=99re not portable between = platforms. >=20 > Sure, but we're talking about the format Emacs uses to save its state, = not the format of .elc files. Currently Emacs saves its state as an = executable file that in general cannot be moved from one GNU/Linux = distribution to another even if they have the same architecture. = Switching to Guile's platform-neutral approach would make Emacs's = saved-state format more portable, not less. Actually, I was referring to compiled-Lisp files generally, including = the =E2=80=9Cdumped.elc=E2=80=9D file, when I suggested it. And I wouldn=E2=80=99t describe Guile=E2=80=99s =E2=80=9CELF = everywhere=E2=80=9D approach as entirely platform-neutral. I built a = Guile tree tonight to take a look. My guess earlier about using the = native architecture was wrong (it uses =E2=80=9Cnone=E2=80=9D), but it = appears that the generated files are specific to the host=E2=80=99s byte = order and word size. So some sharing is possible between similar = platforms, but not across all as with the current .elc format. Even saving just the Lisp state as with =E2=80=9Cdumped.elc=E2=80=9D, I = think there could be state from the environment or build options that = varies across distributions. Lists of supported image types, distro = customizations, things like that. I=E2=80=99m not sure what benefit = there is in trying to share saved Emacs state across distros. If the = goal is for a user to save a massively customized environment for future = invocations, perhaps we should just work on speeding up the loading of = the customizations. If we want standardized object/executable format specifically for the = preloaded environment, perhaps using the native format by way of the C = compiler is a better choice. I think this may have come up in the = discussion before. The big loss there is the ability to create a new = saved environment without having a C compiler handy, but it seems like a = thing few people are likely to want to do, and even fewer non-developers = who might not be able to install a compiler. Ken=