From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Objects that can't be purified during dumping Date: Sun, 24 Jul 2022 08:16:14 -0400 Message-ID: References: <83czdwhsc1.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005a609a05e48c09d8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36873"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Jul 24 14:17:35 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFaYB-0009Mw-2N for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jul 2022 14:17:35 +0200 Original-Received: from localhost ([::1]:51272 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFaY9-00035H-QG for ged-emacs-devel@m.gmane-mx.org; Sun, 24 Jul 2022 08:17:33 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55610) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFaX8-0001pR-Sb for emacs-devel@gnu.org; Sun, 24 Jul 2022 08:16:30 -0400 Original-Received: from mail-ot1-x331.google.com ([2607:f8b0:4864:20::331]:45906) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oFaX6-0007FX-RJ; Sun, 24 Jul 2022 08:16:30 -0400 Original-Received: by mail-ot1-x331.google.com with SMTP id c20-20020a9d4814000000b0061cecd22af4so2184019otf.12; Sun, 24 Jul 2022 05:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vrJKZdLcAVl3ssrTFLXOW2S9icgNwNsvnD026y7A7wc=; b=X76L9VW7pkeNpIUN14FLkBj+0DaEvKV1se6u1KSMBOEyKfuF5ZDyzvWhsKZdzbHps2 EYw11zxSKdlpCR88pdPJbUvxqmbA4+u12OGvCkK8CMYsNC2b+giR5+ViDNV2EmIx1f7m MxemxH0QzUL1vN3tcFsi7bP7tYb06zpqe+lNYFCqvYJGA5K2j7GpMu/zC2OcmlnSB2EA wqirc873dRX+ro2MPNFvP9mLb6IA9b0a2B/ZM2na5Onzrz/N7frO5I5gTNdvuM5GMsHe u1dJRQLPkq0jQ/VP9W0l8YpQzjgIb8kZHknN5/hwF8N4avFz/yh+pQVWcwNriBroDDmI wwLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vrJKZdLcAVl3ssrTFLXOW2S9icgNwNsvnD026y7A7wc=; b=SiJcSU/BN1gpJI3SOvNm6jA/6LdIVzfBVHEqYuzYCr0IpsXZJ6GDLG7ZC1V16+BTjU WVkU1HWgvZbJIparWHk5eeesjGGE7UvM/O7tVXCC2ktr96PAKCuWluaNhfutcQ/PRm6g wrdiDLb26KBEYD3vwEtmv2rVRB+ed4QvNRNnqVfTqFCQfR7nZ8vaBbB1cbYZREWA7+k+ MLXxxzGEIU3D8gNIXI67fK4A8I3200Uo4Lr4ndRkOqWtVUyvZaJfU2SXPdQZ87tZHo4q +ju1Ol6/OGgjQYg6jjglYW6b3u8DMEGeb2L6tObrXZgxdfqJSJif8jWLglJ5AAC9dFvz 0DzQ== X-Gm-Message-State: AJIora8/hcKV42vAxTx0gOkBKYDuZKV+iSf+tVWQa5p6/s97S/YjK93h fxlSKX5I34MY7PrZlskeaXTUNA2yxhVAq3e1+io= X-Google-Smtp-Source: AGRyM1vMST25zwO9QJzNTsTjn/9xT5ETfDAiQdfeEyv2BM4qh1kVsCKNLaindx0oGbHlnBgQTwm86CmnPq85Q3dYeI8= X-Received: by 2002:a9d:7749:0:b0:61c:88a1:4d54 with SMTP id t9-20020a9d7749000000b0061c88a14d54mr3084893otl.5.1658664987024; Sun, 24 Jul 2022 05:16:27 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::331; envelope-from=owinebar@gmail.com; helo=mail-ot1-x331.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292581 Archived-At: --0000000000005a609a05e48c09d8 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 23, 2022, 11:55 AM Stefan Monnier 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 --0000000000005a609a05e48c09d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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.=C2=A0 =C2=A0I'll try the
> hack (on alloc.c) and see if it works as an interim solution.

I think you can just do:

=C2=A0 =C2=A0 diff --git a/src/alloc.c b/src/alloc.c
=C2=A0 =C2=A0 index 6e166d00d5b..acf558f3c7a 100644
=C2=A0 =C2=A0 --- a/src/alloc.c
=C2=A0 =C2=A0 +++ b/src/alloc.c
=C2=A0 =C2=A0 @@ -5611,7 +5611,8 @@ DEFUN ("purecopy", Fpurecopy,= Spurecopy, 1, 1, 0,
=C2=A0 =C2=A0 =C2=A0static Lisp_Object
=C2=A0 =C2=A0 =C2=A0purecopy (Lisp_Object obj)
=C2=A0 =C2=A0 =C2=A0{
=C2=A0 =C2=A0 -=C2=A0 if (FIXNUMP (obj)
=C2=A0 =C2=A0 +=C2=A0 if (true
=C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 || FIXNUMP (obj)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|| (! SYMBOLP (obj) && PUR= E_P (XPNTR (obj)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|| SUBRP (obj))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return obj;=C2=A0 =C2=A0 /* Already pure.= =C2=A0 */

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 on= ly being called because the ELISP source uses defconst instead of defvar wh= en defining the symbol.=C2=A0 I just changed that statement to a defvar and= the problem went away. That's the most expedient solution at the momen= t, 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

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
--0000000000005a609a05e48c09d8--