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: Regression in dump-emacs-portable Date: Tue, 21 Feb 2023 09:21:27 -0500 Message-ID: References: <83ttzocomk.fsf@gnu.org> <834jrncd6a.fsf@gnu.org> <83r0up39qe.fsf@gnu.org> <83bkls1hzn.fsf@gnu.org> <83ttzjzc2q.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000888dda05f5367f0e" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36089"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 21 15:22:56 2023 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 1pUTXj-0009CZ-I2 for ged-emacs-devel@m.gmane-mx.org; Tue, 21 Feb 2023 15:22:55 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pUTWc-00019X-He; Tue, 21 Feb 2023 09:21:46 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUTWa-00019K-Rv for emacs-devel@gnu.org; Tue, 21 Feb 2023 09:21:44 -0500 Original-Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pUTWZ-0000eH-0u; Tue, 21 Feb 2023 09:21:44 -0500 Original-Received: by mail-pf1-x432.google.com with SMTP id fb30so2498082pfb.13; Tue, 21 Feb 2023 06:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1676989300; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=eqLcsA7VJ+OCD3Utm0XsDHQGUr5jMcA78VX5Zz8WsFA=; b=Fi6W4mJNwid0i5jAee7IGEtmajz85ef7/otP/PS5Q2WNCnTMJg59WjFX9CwEnYcDh7 /Fnn9SdkNoN+tZ1yCvYHq2nlorzb+7gZSNhQA7UGXkvjX+avoh1dmwu9FeHdMdKX2X1O hrfjJ2RyqNeNcJCBHpnw5qPVK4Hho7cCyxjgDvrOt6mcfAoJzdxsIuRWrWBVt5Jh/oaB SaM6y8eUnmGTo79ReiBWTaJevm0gbCBtGWeiVDKICimSd4EDhgC0jHbFU7XC9GE2A0gu nVXi1rVsq/IcQpOyyF7IypZlTjgNotVq7Ju84FsX7LDjQrr0tS9er6Fe3ZkozSl290/r jM/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1676989300; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=eqLcsA7VJ+OCD3Utm0XsDHQGUr5jMcA78VX5Zz8WsFA=; b=NXPEJcBjU78RuZIXxv4Ug9yjJA9xeqo6SpDB7ZCRtjYDxekcmIWLA9SRjVwwvuwU/K ka0/LASVIIXNi8aZx4dhqw+MoVFP6KC3aLQvOdwql2s3Vx+OGsO2e/hvq5HU63+mj8hJ GBmpQ0iE57t5jDNFf+3fW1h/d+F2BOsglb3zFFWvuNult6GIrd2aylZS47LSbMurKc20 lXR1eTtSzDqzKfuMKNQpXEgMPXR58BVF9VhSUEcGhT3mpxXwFf4vqCnGbcffj0Dc1doS znn69pg19JAxiEMZvC7RCazorC7K8IFnSKvItW1frQ0QUF+PM73eDwaAC63R7RB0ly6Y OSsg== X-Gm-Message-State: AO0yUKWcATmbTjE4tJeBNznFIh08hWQYPx+XKVJEyFoTrk8Tp8hwMmcQ QiwHZVezN83bFdkAbbteOp0JVpcEeo5h/hrysK1S1hzr X-Google-Smtp-Source: AK7set8JWeS45COvqmQ6gU4l1rp/peb15tao8Dg7uQX+KS77uM/P+qiaio3zf4ijiV0P2n9wZQUok+PTQXTOYARbFMs= X-Received: by 2002:aa7:973b:0:b0:5a8:dd03:3272 with SMTP id k27-20020aa7973b000000b005a8dd033272mr545333pfg.51.1676989300246; Tue, 21 Feb 2023 06:21:40 -0800 (PST) In-Reply-To: <83ttzjzc2q.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::432; envelope-from=owinebar@gmail.com; helo=mail-pf1-x432.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 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303648 Archived-At: --000000000000888dda05f5367f0e Content-Type: text/plain; charset="UTF-8" On Sat, Feb 18, 2023, 2:07 AM Eli Zaretskii wrote: > > From: Lynn Winebarger > > Date: Fri, 17 Feb 2023 18:44:18 -0500 > > Cc: emacs-devel@gnu.org > > > > On Fri, Feb 17, 2023 at 9:31 AM Eli Zaretskii wrote: > > > I don't understand what will this solve. Why does it matter when > > > exactly is a variable initialized, if in any case that will happen > > > before re-dumping? > > > > You're right with respect to the current definitions of > > custom-initialize-* functions that will only set variables if they are > > unbound. > > The docstring for custom-initialize-delay is: > > "Delay initialization of SYMBOL to the next Emacs start. > > This is used in files that are preloaded (or for autoloaded > > variables), so that the initialization is done in the run-time > > context rather than the build-time context. This also has the > > side-effect that the (delayed) initialization is performed with > > the :set function." > > But "so the initialization is done in the run-time context" and "to > > the *next* Emacs start" (emphasis mine) are contradictory unless > > dumping can only happen once. The first sentence should be "Ensure > > SYMBOL is set to initial-value at Emacs startup". > > temacs and bootstrap-emacs (and in general any Emacs that is about to > dump itself) also start up, so the change you propose will make the > doc string less accurate. > > > I'll take a shot at a more thorough rewrite of the customization > > system to properly support redumping this weekend and send another > > patch. > > I'm not sure this is the tree we should be barking up. The problem is > more general than just delayed-initialization of some defcustoms. > I wrote about 95% of this over the weekend, most of which is the efficient solver for dependency ordering of the customization variables set at startup. I'll finish it up in the next couple of evenings and post the patch in a bug report/feature request. My immediate concern is being able to use the current re-dumping facility more effectively. Lynn --000000000000888dda05f5367f0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Feb 18, 2023, 2:07 AM Eli Zaretskii <eliz@gnu.org> wrote:
> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Fri, 17 Feb 2023 18:44:18 -0500
> Cc: emacs-devel@gnu.org
>
> On Fri, Feb 17, 2023 at 9:31 AM Eli Zaretskii <eliz@gnu.org> wrote= :
> > I don't understand what will this solve.=C2=A0 Why does it ma= tter when
> > exactly is a variable initialized, if in any case that will happe= n
> > before re-dumping?
>
> You're right with respect to the current definitions of
> custom-initialize-* functions that will only set variables if they are=
> unbound.
> The docstring for custom-initialize-delay is:
>=C2=A0 =C2=A0"Delay initialization of SYMBOL to the next Emacs sta= rt.
> This is used in files that are preloaded (or for autoloaded
> variables), so that the initialization is done in the run-time
> context rather than the build-time context.=C2=A0 This also has the > side-effect that the (delayed) initialization is performed with
> the :set function."
> But "so the initialization is done in the run-time context" = and "to
> the *next* Emacs start" (emphasis mine) are contradictory unless<= br> > dumping can only happen once.=C2=A0 =C2=A0 The first sentence should b= e "Ensure
> SYMBOL is set to initial-value at Emacs startup".

temacs and bootstrap-emacs (and in general any Emacs that is about to
dump itself) also start up, so the change you propose will make the
doc string less accurate.

> I'll take a shot at a more thorough rewrite of the customization > system to properly support redumping this weekend and send another
> patch.

I'm not sure this is the tree we should be barking up.=C2=A0 The proble= m is
more general than just delayed-initialization of some defcustoms.

I wrote ab= out 95% of this over the weekend, most of which is the efficient solver for= dependency ordering of the customization variables set at startup.=C2=A0 I= 'll finish it up in the next couple of evenings and post the patch in a= bug report/feature request.

My immediate concern is being able to use the current re-dumping facil= ity more effectively.=C2=A0

Lynn

--000000000000888dda05f5367f0e--