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: Skipping unexec via a big .elc file Date: Sun, 26 Mar 2017 19:44:45 +0300 Message-ID: <83a8889ede.fsf@gnu.org> 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> <83r32mqq5f.fsf@gnu.org> <83zih1jf37.fsf@gnu.org> <8A8DA980-13A7-4F8B-9D07-391728C673C9@raeburn.org> <831su4dmn4.fsf@gnu.org> <87h9300x5n.fsf@linux-m68k.org> <734D2132-71FD-414D-B091-629189742DB4@raeburn.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1490546725 13365 195.159.176.226 (26 Mar 2017 16:45:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 26 Mar 2017 16:45:25 +0000 (UTC) Cc: emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Mar 26 18:45:18 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 1csBHu-00015w-Np for ged-emacs-devel@m.gmane.org; Sun, 26 Mar 2017 18:45:06 +0200 Original-Received: from localhost ([::1]:41629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csBHx-0004PR-Mb for ged-emacs-devel@m.gmane.org; Sun, 26 Mar 2017 12:45:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csBHr-0004P9-7J for emacs-devel@gnu.org; Sun, 26 Mar 2017 12:45:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1csBHm-0003lS-W1 for emacs-devel@gnu.org; Sun, 26 Mar 2017 12:45:03 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41000) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1csBHm-0003lK-T4; Sun, 26 Mar 2017 12:44:58 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2909 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1csBHk-00056K-Ht; Sun, 26 Mar 2017 12:44:58 -0400 In-reply-to: (message from Ken Raeburn on Mon, 13 Mar 2017 04:25:19 -0400) 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:213377 Archived-At: > From: Ken Raeburn > Date: Mon, 13 Mar 2017 04:25:19 -0400 > Cc: Emacs developers > > I have a patch which seems to recreate all the abbrev tables that were in the initial Emacs process, including the sharing (lisp-mode-abbrev-table being a parent of emacs-lisp-mode-abbrev-table; local-abbrev-table set to the fundamental mode table). Please let me know if it fixes your problem. Sorry for the long delay: Life™ intervened big time... > It depends on a couple key things: (1) The abbrev tables are empty at that point, so we don’t have to worry about reconstructing all the abbrevs in a table; this can be fixed, it’s just tedious. (2) Abbrev-table values are only used as symbol values, or parents of other abbrev tables. This is much harder. Stefan’s printable replacement for obarrays would probably be a better solution. Though, normally I’d expect people to want printing of an obarray to show symbol names, and for this use case we need the function, value, and plist data as well. I applied your patch, and while dumping I get an error message: Dumping into dumped.elc...preparing... Dumping into dumped.elc...generating... Symbol's function definition is void: cl-labels and dumped.elc is not re-created. What did I miss?