From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#57627: 29.0.50; [native-compilation] cl-loaddefs.el recompiled on startup Date: Fri, 14 Oct 2022 15:00:00 -0400 Message-ID: References: <87bkrsr1g2.fsf@gnus.org> <875yi0qz5b.fsf@gnus.org> <83sfl4ihfo.fsf@gnu.org> <87mtbcp774.fsf@gnus.org> <877d2e5ba1.fsf@gnus.org> <87czc4v5id.fsf@gnus.org> <874jxfsv9o.fsf@gnus.org> <874jw6d6cl.fsf@gnus.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18689"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: germanp82@hotmail.com, 57627@debbugs.gnu.org, Eli Zaretskii , Andrea Corallo To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Oct 14 21:01:49 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1ojPwK-0004fR-UO for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Oct 2022 21:01:49 +0200 Original-Received: from localhost ([::1]:36266 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ojPwJ-0002pR-L5 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Oct 2022 15:01:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52912) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ojPvb-0002ii-0D for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 15:01:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39546) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ojPva-0003Mt-II for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 15:01:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ojPva-0004gG-67 for bug-gnu-emacs@gnu.org; Fri, 14 Oct 2022 15:01:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Oct 2022 19:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57627 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 57627-submit@debbugs.gnu.org id=B57627.166577401217895 (code B ref 57627); Fri, 14 Oct 2022 19:01:02 +0000 Original-Received: (at 57627) by debbugs.gnu.org; 14 Oct 2022 19:00:12 +0000 Original-Received: from localhost ([127.0.0.1]:38624 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojPul-0004eX-Bl for submit@debbugs.gnu.org; Fri, 14 Oct 2022 15:00:11 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ojPui-0004d5-SX for 57627@debbugs.gnu.org; Fri, 14 Oct 2022 15:00:09 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 82A7D44121A; Fri, 14 Oct 2022 15:00:03 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B645C4411A6; Fri, 14 Oct 2022 15:00:01 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1665774001; bh=S6XhxrgyToTMCoJ5lQfJWDg9yDvoSB5Z0/nNsUTD/D8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=H9i9odjQOfS0c1NEzYmaIpmK2nHNkmSyyhenViQ4xOs1fNdjlf102a5QHOOnESzNW SQcE0T5oXNvVSyetyfcwUjuEZ01lNhYAOxrlhPL/PoNa7AoDYwE/7HQDr+yYD4SPY7 1K6mzzXMC180Wm7Bi5xscmUi5NPA38BhqxBJN0OXgn4UjgmbAUKdN/iPdx+Q66FDXV A9NtREzN1bm4y5bKc5Uh1bMDluuLENGX1aB7QfgsU+9MmE1CRfHRRi2+5UVLK6rHzK EABWuNc2VBRG/Mgjqn9CNzkryyVuhm2w4xSmuyVuSJgZxN+4HFg8luXp24NQTClQLh 0tc0q+xPAVUeA== Original-Received: from pastel (65-110-220-202.cpe.pppoe.ca [65.110.220.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 77675120F4D; Fri, 14 Oct 2022 15:00:01 -0400 (EDT) In-Reply-To: <874jw6d6cl.fsf@gnus.org> (Lars Ingebrigtsen's message of "Fri, 14 Oct 2022 12:53:14 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:245477 Archived-At: > ;; no-native-compile: t > > into .el files to signal that we don't want them to be native-compiled. > However, the machinery today doesn't see that when we want it to. That > is, we load the .elc file, the nativecomp machinery then kicks in and > adds the file to the async .eln list, which then forks off an Emacs > which then loads the .el file and sees that cookie, and then does > nothing. (And this will happen on every Emacs run.) > > So the machinery either has to inspect the .el file in addition to the > .elc file (which is inefficient), or we need to put something into the > .elc file to tell the machinery not to bother with generating the .eln. After spending many milliseconds thinking about it, my conclusion is that the bytecompiler should add a little code snippet like (puthash load-file-name t comp--no-native-compile) in the file if `no-native-compile` was specified. So it then be easy for the lazy native compilation to detect that it should skip this file (since lazy native compilation is triggered after loading the file) by just consulting `comp--no-native-compile`. For that, there's no need to change the way `no-native-compile` is specified. > So... is it time to introduce something like `pragma'? > > That is, in this case, we'd say > > (pragma 'no-native-compile) > > somewhere in the file. I guess that could work for `no-native-compile`, indeed. But if you ask to native compile this file and the pragma is halfway down the file, what happens? > We could have > > (pragma 'dynamic-binding) I guess this one could work (of course, it'd have to be at top-level), and we could switch back&forth within the same file (yuck!). But if we allow such `pragma` to be output by macros, then it becomes tricky for `eval-region` to reliably decide which dialect to use. > And we could have > > (pragma 'shorthands "snu-" "some-nice-string-utils-") Same question: the tooling will often want to have access to that information but without necessarily wanting to run (or macroexpand) all the code first. So we could allow such `pragma`, but we'd likely end up restricting its syntax so we're able to find it with something like a regexp search, so in the end it's not clear what's the advantage over file-local variables. Stefan