[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Skipping unexec via a big .elc file
From: |
Ken Raeburn |
Subject: |
Re: Skipping unexec via a big .elc file |
Date: |
Mon, 27 Mar 2017 22:27:26 -0400 |
On Mar 26, 2017, at 12:44, Eli Zaretskii <address@hidden> wrote:
>> From: Ken Raeburn <address@hidden>
>> Date: Mon, 13 Mar 2017 04:25:19 -0400
>> Cc: Emacs developers <address@hidden>
>>
>> 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 happens. No worries.
>
>> 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?
Looks like I missed a “require” or “load” to pull in cl-macs. Perhaps it’s
loaded by something else in my build that’s platform-dependent (X11 vs
Windows?) and isn’t in yours; I’m not sure. But it isn’t working for me to just
load it explicitly without fixing up the load path too. Perhaps I should’ve
just defined a helper function instead of using cl-labels.
For now, try adding this patch. It bootstraps for me, and should get cl-labels
defined.
diff --git a/lisp/loadup.el b/lisp/loadup.el
index 4ef9712ab6..f9251020cd 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -57,6 +57,17 @@
;; Add subdirectories to the load-path for files that might get
;; autoloaded when bootstrapping.
;; This is because PATH_DUMPLOADSEARCH is just "../lisp".
+(let ((dir (car load-path)))
+ (message "load path is %S" load-path)
+ (setq load-path (list (expand-file-name "." dir)
+ (expand-file-name "emacs-lisp" dir)
+ (expand-file-name "language" dir)
+ (expand-file-name "international" dir)
+ (expand-file-name "textmodes" dir)
+ (expand-file-name "vc" dir))))
+
+(setq purify-flag nil)
+
(if (or (equal (member "bootstrap" command-line-args) '("bootstrap"))
;; FIXME this is irritatingly fragile.
(equal (nth 4 command-line-args) "unidata-gen.el")
@@ -64,19 +75,10 @@
(if (fboundp 'dump-emacs)
(string-match "src/bootstrap-emacs" (nth 0 command-line-args))
t))
- (let ((dir (car load-path)))
- ;; We'll probably overflow the pure space.
- (setq purify-flag nil)
- ;; Value of max-lisp-eval-depth when compiling initially.
- ;; During bootstrapping the byte-compiler is run interpreted when
- ;; compiling itself, which uses a lot more stack than usual.
- (setq max-lisp-eval-depth 2200)
- (setq load-path (list (expand-file-name "." dir)
- (expand-file-name "emacs-lisp" dir)
- (expand-file-name "language" dir)
- (expand-file-name "international" dir)
- (expand-file-name "textmodes" dir)
- (expand-file-name "vc" dir)))))
+ ;; Value of max-lisp-eval-depth when compiling initially.
+ ;; During bootstrapping the byte-compiler is run interpreted when
+ ;; compiling itself, which uses a lot more stack than usual.
+ (setq max-lisp-eval-depth 2200))
(if (eq t purify-flag)
;; Hash consing saved around 11% of pure space in my tests.
@@ -308,6 +310,8 @@
;; Preload some constants and floating point functions.
(load "emacs-lisp/float-sup")
+(load "emacs-lisp/cl-macs")
+
(load "vc/vc-hooks")
(load "vc/ediff-hook")
(load "uniquify")
- Re: Skipping unexec via a big .elc file, (continued)
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/03/11
- Re: Skipping unexec via a big .elc file, Andreas Schwab, 2017/03/11
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/03/11
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2017/03/11
- Re: Skipping unexec via a big .elc file, Richard Stallman, 2017/03/11
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2017/03/11
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2017/03/11
- Re: Skipping unexec via a big .elc file, Stefan Monnier, 2017/03/12
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2017/03/13
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/03/26
- Re: Skipping unexec via a big .elc file,
Ken Raeburn <=
- Re: Skipping unexec via a big .elc file, Eli Zaretskii, 2017/03/31
- Re: Skipping unexec via a big .elc file, Ken Raeburn, 2017/03/31