From: "N. Jackson" <njackson@posteo.net>
To: 73303@debbugs.gnu.org
Subject: bug#73303: 30.0.91; Native compiler repeatedly interrupts at random moments
Date: Tue, 17 Sep 2024 16:01:18 +0000 [thread overview]
Message-ID: <87ed5iz2up.fsf@Phoenix> (raw)
In-Reply-To: <867cbbcuen.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 16 Sep 2024 21:42:24 +0300")
I'm resending this message to 73303@debbugs.gnu.org only, because
the first time my mail service provider bounced the copy to
73303@debbugs.gnu.org (because debbugs.gnu.org[209.51.188.43]
refused a TLS connection).
Hello Eli, thank you for your response.
At 21:42 +0300 on Monday 2024-09-16, Eli Zaretskii wrote:
> I see no bug in what you describe.
Fair enough. The concern that prompted me to file a bug report was
not that native compile is broken (a literal bug) but rather that
since it's a newish feature you might welcome end-user feedback
about it's default behaviour (or perceived behaviour) that might
lead to to beneficial tweaks to either the behaviour or to the
documentation.
> These warnings usually mean that the offending Lisp file lacks
> some 'require's. JIT native compilation runs in a separate Emacs
> session, which only loads the file it compiles, so any missing
> 'require's or autoloading cookies trigger these warnings, whereas
> when the same packages are loaded into your main Emacs session,
> they can benefit from packages loaded earlier in the session.
...
> JIT native compilation is triggered by loading a .elc file that
> doesn't yet have a corresponding .eln file
Thank you for the overview of how native compilation works. I had
wrongly guessed that it was deferring the compilation lazily and
doing it later on an idle timer or something of that sort. If I
understand what you are saying correctly, the native compiler, not
having a crystal ball, cannot possibly know ahead of time what .elc
files a user might load, so it cannot compile them ahead of time.
However, as a naïve end-user of Emacs, when I am _using_ Emacs, as a
tool to get a job done -- writing an essay, say -- I don't want to
think about the guts of how Emacs works. I'm happy to save that for
when I'm building Emacs or maintaining my configuration files and
that is when I would want the native compilation to happen, if that
were possible.
You write
> You can disable these warnings if you are annoyed by them. They
> are just warnings, and will not usually cause any problems when
> using the compiled code. See
> native-comp-async-report-warnings-errors.
Sweeping warnings under the rug isn't something I'm comfortable with
even if nine times out of ten (or 999 times in 1000) they're false
alarms. (I'm the sort of person that -Werror was made for.)
> You can cause these compilations to happen at the beginning of your
> Emacs session if you change your init files such that Emacs loads all
> these files.
...
> In any case, Emacs compiles each Lisp file just once, so you should
> only see these when you start a new Emacs version for the first time.
I guess, then, that I would want to (somehow) process my init files --
before using Emacs for the first time after upgrading to a new
version -- to ensure native compilation of all dependencies.
Do you have any pointers on how to go about doing that? It seems
impractical for a casual Emacs user since they don't necessary know
what files will be loaded by the packages they use. The warnings
I've seen so far all refer to files I've never heard of.
I don't suppose there's a function
native-compile-eagerly-compile-all-dependencies-of-my-init-files-and-do-it-synchronously-right-now?!
If I can deal with my init files (ensuring that they won't load any
files that haven't yet been native compiled), it seems I would be
left with two potential sources of files being native compiled --
Emacs itself, and newly installed/updated packages. Two questions
about that, then:
1. Does the native compiler compile all the .elc files in
Emacs itself into .eln files ahead of time, or does it also leave
those until they are loaded?
2. When the package system installs/updates a package, does it
natively compile the files at the same time as it byte compiles
them?
prev parent reply other threads:[~2024-09-17 16:01 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-16 18:14 bug#73303: 30.0.91; Native compiler repeatedly interrupts at random moments N. Jackson
2024-09-16 18:42 ` Eli Zaretskii
2024-09-16 19:27 ` Andrea Corallo
2024-09-18 0:43 ` N. Jackson
[not found] ` <87plp2mhj1.fsf@moondust.awandering>
2024-09-17 15:59 ` Eli Zaretskii
2024-09-17 18:46 ` Philip Kaludercic
2024-09-17 19:09 ` N. Jackson
2024-09-17 20:10 ` Philip Kaludercic
2024-09-24 19:13 ` Andrea Corallo
2024-09-17 19:09 ` Eli Zaretskii
2024-09-17 20:09 ` N. Jackson
2024-09-18 11:29 ` Eli Zaretskii
2024-09-24 19:10 ` Andrea Corallo
2024-09-25 11:15 ` Eli Zaretskii
2024-09-25 18:47 ` Andrea Corallo
2024-10-19 6:58 ` Eli Zaretskii
2024-10-22 16:29 ` Andrea Corallo
2024-10-23 7:04 ` Eli Zaretskii
2024-10-23 7:44 ` Andrea Corallo
2024-09-17 16:01 ` N. Jackson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ed5iz2up.fsf@Phoenix \
--to=njackson@posteo.net \
--cc=73303@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.