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: Finalizing 'inhibit-automatic-native-compilation' Date: Mon, 6 Feb 2023 22:57:54 -0500 Message-ID: References: <837cx8cey0.fsf@gnu.org> <837cx6a8me.fsf@gnu.org> <83357ua6ja.fsf@gnu.org> <83zga28ra8.fsf@gnu.org> <83r0vd97s0.fsf@gnu.org> <83lell73yv.fsf@gnu.org> <83k0145guk.fsf@gnu.org> <835ychtcq9.fsf@gnu.org> <83r0v4sgpj.fsf@gnu.org> <83cz6nq70a.fsf@gnu.org> <834jryrioo.fsf@gnu.org> <83v8keq0dy.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="3957"; mail-complaints-to="usenet@ciao.gmane.io" Cc: akrl@sdf.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Feb 07 05:01:01 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 1pPFAC-0000uK-Of for ged-emacs-devel@m.gmane-mx.org; Tue, 07 Feb 2023 05:01:00 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pPF7U-0000uo-7e; Mon, 06 Feb 2023 22:58:12 -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 1pPF7S-0000ue-PJ for emacs-devel@gnu.org; Mon, 06 Feb 2023 22:58:10 -0500 Original-Received: from mail-pj1-x1033.google.com ([2607:f8b0:4864:20::1033]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pPF7R-0001XN-3A; Mon, 06 Feb 2023 22:58:10 -0500 Original-Received: by mail-pj1-x1033.google.com with SMTP id bg10-20020a17090b0d8a00b00230c7f312d4so4166601pjb.3; Mon, 06 Feb 2023 19:58:08 -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=U5qJ8bjnEPCD6TnZ8ADLLoWjCr7QMisw2cg5dAmJx8w=; b=ZrPvN79ps7r2P7tuHIL9HLgSmWu8OPe+eGEEasfg2NkXU6Q5GlL+Ck2P2v5s9p4aWM lzXpiU9n37yTjJIXSPGV6h/KnJKxbxKwoQ5gbJhYP36IXkNPuHTngJByOGPQKaG+xK+s QZtWq2HO0i1PtbaSxIiXTgOzeVhPGKF4pye+KyStp9iudC8dLY5e73Mk9/KW3DDAF4y3 EjKc/nyaxby7E+jaEqbEEQ4h1BuZlm/9V5xioMC0fff5rIjT6lLsywOfkZBkquEUT+Kn tZkpWrobM/4DMsQ5/pr6nkWNffEkRUlbxatOJjHsasaY/1UI8x3ed9xsT/ae01eMRuEt kM8Q== 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=U5qJ8bjnEPCD6TnZ8ADLLoWjCr7QMisw2cg5dAmJx8w=; b=0RuhVconB37zv5nORYrxsGU35+3sXoUnLRofxwyKLupWF9jznQIP2TOoQ45etX+f5i s3OaV+V+9WcrkeLA7VuJxht4XIZ5j/+rz1dRy0sOz4j60V07CC81+TQJsQac5jOkn1YS OWwHQ9c3mj+yTbf9ikekQZXVRlPFwF3RgNeDJJswrlGDKHWbmiClD5VpIip9iIDU5jh+ t/EZiOCEgKO+keeVLnU9NtxUX6H9Hr5kVIDdIsmEmoLdmONr7SG0LHGT0HXi2OAQNjG8 GmASFGITQtk9ZIGj0wb64w4juGQncIXfr8xeTNXZNsmmNRuWOSuvKe2Q3Cmeqeaa5lu+ gUUw== X-Gm-Message-State: AO0yUKWb2PTN+V3I0v7KNLMQuX+L+TlDfFu7T+QGtH7LIRjrqvY7AyzT WHGlRPSZuxMbdLsTEoI479O9vNq+IckB1SthtHfMTq6w X-Google-Smtp-Source: AK7set+FAQ1RJsSiFcV8SJyN+MAoI6B40d3HfihhVZBUFtvquBoIJkBKS7nz6XuyRSOu98DQs8CHdd9pML7AjuHX29w= X-Received: by 2002:a17:902:dac3:b0:199:648:edb8 with SMTP id q3-20020a170902dac300b001990648edb8mr309761plx.23.1675742286561; Mon, 06 Feb 2023 19:58:06 -0800 (PST) In-Reply-To: <83v8keq0dy.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::1033; envelope-from=owinebar@gmail.com; helo=mail-pj1-x1033.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:303029 Archived-At: On Mon, Feb 6, 2023 at 10:28 AM Eli Zaretskii wrote: > > From: Lynn Winebarger > > Date: Mon, 6 Feb 2023 09:29:10 -0500 > > Cc: Andrea Corallo , Stefan Monnier , > > emacs-devel > > > > No, I'm saying that starting Emacs assumes the dumped *.eln files live > > in one of two possible locations, and you must make sure they are in > > one of those two locations, or else Emacs will fail to start. > > > > Then I'm confused by what you mean by "re-dumping" above. I'm only referencing the result of starting > > temacs in dump-mode. > > You started the re-dumping subject (although the current discussion is > about something completely different). Not with regard to native-compiled libraries. But to circle back to your question about whether emacs 29 exhibited this behavior, this discussion has clarified the disconnect in our understanding. To answer your question, I need to construct some test cases with the following property: Library A containing function f which is always invoked in the native compiler process Library B containing function g is used to advise function f under 2 variants of the dump file 1) Library A is included in the dump used in the native compiler process, but the ELN is not loaded prior to the dump 2) Library A is included in the dump used in the native compiler process, and the ELN was loaded prior to the dump and 3 variants in the way the advice is applied a) In the ordinary eval phase of loading the library b) In a compile-when-eval or compile-and-eval context c) During macro expansion A variant of these test cases would be when function f is only conditionally invoked in the native compiler process. I observed the behavior in question when "f" was "call-interactively" with variant (2) of the dump file. I don't know what library B or function g was, or which of variants (a) - (c) was the case. But it should be possible to identify some other function f involved in the native compiler process and a library B and function g under each of those variants without having to be able to dump (e.g.) a native-compiled cl-lib. Another set of test cases would be those that are unlikely to arise by accident, for example in which each B/g deliberately creates a novel B'/g' that it native-compiles and requires during the trampoline compiling process, so it couldn't be caught by simply tracking which functions are being processed. Lynn