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: Thu, 16 Feb 2023 18:45:07 -0500 Message-ID: References: <83ttzocomk.fsf@gnu.org> <834jrncd6a.fsf@gnu.org> <83r0up39qe.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26920"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 17 00:46:22 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 1pSnxE-0006om-U7 for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Feb 2023 00:46:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pSnwP-0001zn-Vn; Thu, 16 Feb 2023 18:45:30 -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 1pSnwK-0001zI-Em for emacs-devel@gnu.org; Thu, 16 Feb 2023 18:45:24 -0500 Original-Received: from mail-pj1-x1030.google.com ([2607:f8b0:4864:20::1030]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pSnwI-0006xf-MK; Thu, 16 Feb 2023 18:45:24 -0500 Original-Received: by mail-pj1-x1030.google.com with SMTP id cp18so1321729pjb.0; Thu, 16 Feb 2023 15:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=jShC+F0ZvNVzo/dzNSoNqnHJt1kTyLBZeQrvlj84I8c=; b=J9Z++BSrusX1Zz2vTNLRj5ACzF8UioQaI4NBkQ0/d5Pc1qUoAdZXocp58f4dszUudK KX9ae3CkEVDk0jSqLWsUUAebJKX/S6H+znECtrf9WehjkVbXzhRPDZEJsaZ0e0AsjEQu 3IIDe93OciPfUCCOW5Ohi2DUO2jpikyMqKiU5egP2tf6xw+z2dzi3Fq9xrzv6ucntG2L S9lLoKdW7iiGlIBACLM6fbQRbhd9KCNRWxx6kNR2Vu/1yijKoyoA8pzydG1aVFgJYXxq 4W6mb/D/z5hOPPpsyY/++6AG89dMJESltqxX6XmUChJ0EZ4ouChRaRtY7MYV5/5IRPDF f70w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=jShC+F0ZvNVzo/dzNSoNqnHJt1kTyLBZeQrvlj84I8c=; b=T2i1emn39/wjgybrHFwBp2VPkUjEU80uYmHh2TW1yKNtKxQH6S1IYQT/cQfJSWS0kD sfJgHiTrOKBCtIQsFfdYZYP4hRIqi3E0xcYeFnA+hVVrDRsBX1GA2wAu/+rn+KdFJNjv EXnXLfVG07qrbul6Tk5L01dc0kcOF6ZL94gcimCzXgNUeE0VaBSULQvmomrq0j5pF2n9 g5yeQTDTqaqS7NQesyCt9cImE0EmrJSdRtEwdoGqoWlC+wgcHyVq8ry0/3WhMXvQxsAK NvlGgUvn6Jj7rYTLDPf1Knw8yn8EZ27sTO+WJ2JXd0i+Jx35+HH3tRuNdeQkUA4Vfg4s OpTw== X-Gm-Message-State: AO0yUKXp4B2GJGF2MIKIAUOinMiuHsGH2AA7pxd8lAPiZNSj1y60i3AH Zwjk/6zudLEL/HxVnBxS/04ag/G5eA3obJZCqILC8jZM X-Google-Smtp-Source: AK7set/sPO3S7d6TK5ORic1RNaE581Vw2M9RVvs/LsQPKO4PuqlH2UuEB06Ez1fPI1LV+uxbO3Et1mBxiTivie38r4I= X-Received: by 2002:a17:90b:2784:b0:232:ce4d:8da8 with SMTP id pw4-20020a17090b278400b00232ce4d8da8mr863136pjb.143.1676591118951; Thu, 16 Feb 2023 15:45:18 -0800 (PST) In-Reply-To: <83r0up39qe.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::1030; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1030.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, 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:303443 Archived-At: On Thu, Feb 16, 2023 at 10:34 AM Eli Zaretskii wrote: > > > From: Lynn Winebarger > > Date: Thu, 16 Feb 2023 10:05:00 -0500 > > Cc: emacs-devel > > > > I do see something in the redumped emacs that seems like a bug to me. The process I use for creating the > > dump uses the -Q flag. But some of the settings I see in "emacs -Q --dump-file ..." are not the ones I see > > with just "emacs -Q". Some are pretty basic - menu-bar-mode, tool-bar-mode, global-font-lock-mode, > > transient-mark-mode are all nil in the redumped process but not the baseline. > > That is exactly the problem with re-dumping: stuff that was > initialized on the first start gets dumped, and then works differently > when Emacs is restarted from the second dump. That appears to be a consequence of setting custom-delayed-init-variables to t in startup, without saving a copy to be restored by an after-pdump-load-hook. Those modes have an init-value expression involving "(not noninteractive)" that is evaluated during batch mode startup but not in the post-redump startup. > Figuring this out is the main part of the job of enabling re-dumping. > re-dumping in 28.2 works well enough to be useful. At least I can explicitly set the custom-delayed-init-variables by setting a hook, and various kludges to make things work. The dump procedure just failing in 29/30 is much more problematic for me. I only mentioned the failures with the libraries included in emacs, but libraries from packages that previously dumped just fine also fail. Starting up with 2200 loaded libraries is much faster after redumping in 28.2. > > A general test would be load the additional files to be dumped, write out all the symbol properties, variable > > values, and function values, then load the dump file and compare everything with equal, including the set of > > symbols, variables and functions defined. > > Is it fair to say that is the correct expectation of the dumping procedure? > > I don't think this will work, because at least the defcustoms are > evaluated upon each startup, and a defcustom can have a setter > function. And there are probably more features which will get in the > way. I suppose there are two versions of this test. One is, what is the correct behavior, and has it been achieved? The regression version is, is the current behavior no more incorrect than the reference version, i.e. correct for all elements of the lisp heap for which the reference version is correct? Lynn