Re: Skipping unexec via a big .elc file

[Ken Raeburn <raeburn@raeburn.org>]

On Jan 14, 2017, at 05:41, Eli Zaretskii <eliz@gnu.org> wrote:
> It does fail for me while byte compiling 2 files:

I still haven’t hit these.

> The category '>' is defined in characters.el.  Surprisingly,
> characters.elc in this branch is identical to the file on master, so
> byte compilation (see below) is off the hook here.  What else could
> explain that this category is deemed unknown?

I recently noticed the standard syntax and category tables don’t appear to be among the information dumped out, so anything set by characters.el isn’t preserved.  I also didn’t see an existing way to restore them trivially.  (A huge list of “modify-syntax-entry” calls and such seems impractical.)  Also, the buffer-local nature of some variables was being lost; that presented itself as a failure to get syntax-based highlighting in C source files.

Having patched around these, I’m still failing on the same file, but later; it prompts me for the coding system to use to write an output file, because it’s not valid UTF-8.  Apparently the leading comments copied from SKK-JISYO.L are being corrupted.  The first non-ASCII bytes in the buffer (in the “ACKNOWLEDGEMENTS” part of the comment) are 0xe3, 0x81, 0x93, 0xe3, 0x81, 0xae, 0xe8 in a normal build and 0xf5, 0x80, 0x84, 0xac, 0xf5, 0x80, 0x85, 0x87 in my build.  I discovered this maybe half an hour ago, so that’s as far as I’ve gotten.

I’ve just pushed my changes, plus your change to avoid the dump-emacs call, to the branch.  Saving and restoring the standard syntax table seems cheap, because it was already referenced by other objects that were dumped out, but the standard category table almost doubles the size of my dumped.elc, and presumably increases the time to read it accordingly.  Perhaps reading characters.el(c) at startup would be a better choice.

Ken