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: Skipping unexec via a big .elc file Date: Wed, 8 Feb 2017 05:31:31 -0500 Message-ID: References: <9463F91F-DB82-48E1-BE01-1E2BC8DA0766@raeburn.org> <831swxzbw8.fsf@gnu.org> <83y3z2wphb.fsf@gnu.org> <83tw9bb42m.fsf@gnu.org> <349ED8B9-C34B-495B-9FB5-E72CE6EFCA38@raeburn.org> <87inpni6xa.fsf@linux-m68k.org> <8360lmesso.fsf@gnu.org> <3B044D64-7C94-42D7-BE1B-7A9CA76C5A67@raeburn.org> <83k29xc49v.fsf@gnu.org> <2C5C5C6E-9D73-4613-948B-C15B93968717@raeburn.org> <83poiy8cnv.fsf@gnu.org> <83y3xk7i07.fsf@gnu.org> <7DB61BDC-41C5-41A5-BB01-B15F2B03A81E@raeburn.org> <491113AD-F03F-4E9D-8005-F4C430E60A16@raeburn.org> <5AF6553B-9ECD-4F0B-8841-55656D4D1B99@raeburn.org> 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 1486549921 2191 195.159.176.226 (8 Feb 2017 10:32:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 8 Feb 2017 10:32:01 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 08 11:31:54 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 1cbPXT-0008F3-8j for ged-emacs-devel@m.gmane.org; Wed, 08 Feb 2017 11:31:51 +0100 Original-Received: from localhost ([::1]:58635 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbPXT-00056N-PY for ged-emacs-devel@m.gmane.org; Wed, 08 Feb 2017 05:31:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47907) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cbPXI-00051s-42 for emacs-devel@gnu.org; Wed, 08 Feb 2017 05:31:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cbPXF-00060c-0V for emacs-devel@gnu.org; Wed, 08 Feb 2017 05:31:40 -0500 Original-Received: from mail-qt0-x236.google.com ([2607:f8b0:400d:c0d::236]:33240) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cbPXE-00060T-RP for emacs-devel@gnu.org; Wed, 08 Feb 2017 05:31:36 -0500 Original-Received: by mail-qt0-x236.google.com with SMTP id v23so161024325qtb.0 for ; Wed, 08 Feb 2017 02:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=49HBKsaawJItTR4IlQoHjxxipTzz+1TIhGpsS8pInFc=; b=jJfqzGfaZ+Dobe8hU1grtAiN5bIWLaZUaySKwWgcd/lpz38Hi8EGaDSd24Vp+epJUX R5w9R/Tf0Iz8BwQ8Hcr9hdaNn04guhFlGVfZwDwbm93t8c+dOJ5k8aE2Gyd3gtdgc+42 7GgchDwAz/0K32gT2uJDWg0+NWnmT6Mw/t/Yr40KWV1Gu7nbssAFKmEHM0DldSW/5W47 JR2J3FnIva11qPwjE7vrNuLq+AD62YayO9Z2Y7eOG89xy1HmhnRoDYL6b+cy1bMXI9oS y3auNe6D+71r6NZtehwf7HwkR+2R6a8HX3JlE7+EQ64aT5UV7u/qJFePbf5Nrg/DitSy CHFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=49HBKsaawJItTR4IlQoHjxxipTzz+1TIhGpsS8pInFc=; b=OofobJHYSMEDZAbXHb/1XYK44Kk492cLy0Q2FdqETYiO+7S11mLfwSA5cbpBdYa9Ts uqUV7xbMbK/ruQFu4mUA2VC5Ock+BdB1X2AN9LE86svt39b+X0JwEfmBi3cogjwVKbv4 7emppN/qelHghr8K+4b3OZe7MCQDvcPiL312iKJObLEyGSKLDGNIUlqa8IP758KWsseq titfK7dz17xKlJ9XzD0ulLi7AANGYraGHxHMSalutacxupVCIhfGOVbUkwvQT0jh6gKB c29YdaSnt7VLQqrT9prz7+zdpRpjg4exUdZHVRGyXOXRFRYNUv3OKjabI+g7QjHRLv7c CfIw== X-Gm-Message-State: AMke39kMXAgAKhfz+lR1mIwlhcB+BVPePDJ42IczJOtEEKnRlTsBEuS8btNVI/SV5WR6lw== X-Received: by 10.200.39.212 with SMTP id x20mr18188497qtx.109.1486549894024; Wed, 08 Feb 2017 02:31:34 -0800 (PST) Original-Received: from [192.168.23.52] (c-50-138-183-136.hsd1.ma.comcast.net. [50.138.183.136]) by smtp.gmail.com with ESMTPSA id k62sm5849378qkd.21.2017.02.08.02.31.32 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Feb 2017 02:31:32 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3124) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c0d::236 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:212129 Archived-At: On Feb 6, 2017, at 17:39, Stefan Monnier = wrote: >> Is this a known (and filed) bug? >=20 > I don't think it's filed, no. I've known about it for a while now, = and > it came up "recently" in the discussion about reproducible builds. > Until then it wasn't considered as a real bug, I think, more like > a quirk. Ah, okay. I didn=E2=80=99t follow that discussion closely. I haven=E2=80= =99t got the bandwidth to keep up on everything, and until now I thought = I didn=E2=80=99t care about this one. :-) With my bootstrap builds running without parallel make, I=E2=80=99ve = gotten things much further along in terms of generating .elc files that = match what I get without all the big-elc changes. The difference in progmodes/python.elc came down to the use of UTF-8 in = the environment during byte compilation affecting the generated doc = strings (using format-message in a macro). Removing = internal--text-quoting-flag from the stuff saved in dumped.elc made the = files match for me on my Mac (with UTF-8 in use by default). I think = that=E2=80=99s just papering over the real problem (the macro=E2=80=99s = result shouldn=E2=80=99t depend on the UTF-8-ness of the environment), = but the flag should reflect the environment of the current Emacs = invocation anyway, not the one that produced dumped.elc. The difference in url/url-handler.elc was because the subr doc strings = were getting lost. The numbers (=E2=80=9CDOC=E2=80=9D file offsets) = stored in the Lisp_Subr structure weren=E2=80=99t preserved, so = url-handlers-create-wrapper would just fill in =E2=80=9CNo original = documentation.=E2=80=9D I=E2=80=99m making dumped.elc invoke = Snarf-documentation for now. A tangent: As it happens, a couple years back I was experimenting with = having C-based subr/variable documentation stuffed into the executable = instead of needing the DOC file, in ways that wouldn=E2=80=99t add a lot = of Lisp data unless the doc strings were actually needed. For subr = documentation, it doesn=E2=80=99t create Lisp strings until they=E2=80=99r= e requested. For variables, I=E2=80=99ve got an idea on deferring the = Lisp string creation, but currently they=E2=80=99re created at startup = and stuffed into the property list. I=E2=80=99ve just updated it to = recent Emacs sources, in case we might want to explore that direction = further; it might be more efficient than patching up doc pointers every = time we start up. Anyway, with the changes I=E2=80=99ve just pushed to the branch, my = bootstrapped tree has .elc files that match those built from the branch = point, except for mule.elc, macroexp.elc (both source files changed on = the branch), bytecomp.elc and byte-opt.elc (probably due to macroexp = changes). I haven=E2=80=99t tried any more extensive testing. There may be some funny stuff going on in restoring the charset = definitions that I still need to look into. I haven=E2=80=99t pulled in Ken Brown=E2=80=99s Cygwin changes; Ken, = feel free to push those to the branch as well. Ken=