From: Andrea Corallo <acorallo@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Philip Kaludercic <philipk@posteo.net>,
"N. Jackson" <njackson@posteo.net>,
73303@debbugs.gnu.org
Subject: bug#73303: 30.0.91; Native compiler repeatedly interrupts at random moments
Date: Tue, 24 Sep 2024 15:10:10 -0400 [thread overview]
Message-ID: <yp134log965.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <865xqub7ai.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 17 Sep 2024 18:59:17 +0300")
Eli Zaretskii <eliz@gnu.org> writes:
>> From: "N. Jackson" <njackson@posteo.net>
>> Cc: 73303@debbugs.gnu.org, Andrea Corallo <acorallo@gnu.org>
>> Date: Tue, 17 Sep 2024 15:22:42 +0000
>>
>> 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.
>
> The feedback is always welcome, of course (if my wording somehow made
> an impression it wasn't, I apologize). And what you describe is
> already known: a few users posted similar experiences during the
> development and testing of Emacs 29. So these issues are not new, and
> I think Emacs 30 is better equipped to deal with them, and gives users
> more knobs to deal with them.
>
>> > 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.
>
> Yes, exactly. JIT compilation compiles only packages that you load,
> when you load them for the first 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.)
>
> If you set native-comp-async-report-warnings-errors to the value
> 'silent', the warnings will be logged in the *Warnings* buffer, where
> you can later review them, but will not be shown in a popup buffer,
> which might distract you when you don't want that.
>
>> > 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.
>
> If your init file arranges for many packages to load only on demand,
> then I don't think there is a way, except summarily compile all the
> packages under your ~/.emacs.d/ directory (assuming that's where you
> install them). Maybe we should have a native-compile-directory
> function to make that easier; currently we only have
> emacs-lisp-native-compile, which compiles a single file. Andrea,
> WDYT?
Yes we could do that if we think is useful, is probably few lines like:
(defun native-compile-directory (directory)
(mapc (lambda (file)
(native-compile file))
(directory-files-recursively directory ".+\\.el$")))
but this will recompile all files, so maybe to make it useful for .emacs
we should have something that compiles files only when the corresponding
eln is not already present?
next prev parent reply other threads:[~2024-09-24 19:10 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 [this message]
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
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yp134log965.fsf@fencepost.gnu.org \
--to=acorallo@gnu.org \
--cc=73303@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=njackson@posteo.net \
--cc=philipk@posteo.net \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).