Re: Objects that can't be purified during dumping

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]

On Sat, Jul 23, 2022, 11:55 AM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > I recalled seeing an exchange to that effect on this list.   I'll try the
> > hack (on alloc.c) and see if it works as an interim solution.
>
> I think you can just do:
>
>     diff --git a/src/alloc.c b/src/alloc.c
>     index 6e166d00d5b..acf558f3c7a 100644
>     --- a/src/alloc.c
>     +++ b/src/alloc.c
>     @@ -5611,7 +5611,8 @@ DEFUN ("purecopy", Fpurecopy, Spurecopy, 1, 1, 0,
>      static Lisp_Object
>      purecopy (Lisp_Object obj)
>      {
>     -  if (FIXNUMP (obj)
>     +  if (true
>     +      || FIXNUMP (obj)
>            || (! SYMBOLP (obj) && PURE_P (XPNTR (obj)))
>            || SUBRP (obj))
>          return obj;    /* Already pure.  */
>
> But, the "pinned" approach as is done for hash-tables should work just
> fine as well.
>

I had an off-list response indicating the purify routine is only being
called because the ELISP source uses defconst instead of defvar when
defining the symbol.  I just changed that statement to a defvar and the
problem went away. That's the most expedient solution at the moment, as
changing the c source would require re-native-compiling all the elisp files
I'm including in the dump, which takes hours to do sequentially.
I will keep this approach in my back pocket for now. Once I know the dump
will work, I may revisit the issue.

Thanks,
Lynn

[-- Attachment #2: Type: text/html, Size: 2161 bytes --]