From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: cpitclaudel@gmail.com, emacs-devel@gnu.org, raman@google.com
Subject: Re: More reliable byte compilation, take 45
Date: Tue, 05 Oct 2021 14:52:46 +0300 [thread overview]
Message-ID: <83r1cz4rjl.fsf@gnu.org> (raw)
In-Reply-To: <jwvo884iml1.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Mon, 04 Oct 2021 16:13:33 -0400)
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: raman@google.com, cpitclaudel@gmail.com, emacs-devel@gnu.org
> Date: Mon, 04 Oct 2021 16:13:33 -0400
>
> >> Converting a `.elc` file to a `.eln` file can be done by a pure function
> >> with no need for any extra information.
> > I very much doubt that.
>
> You might be right, there might be corner cases I'm not taking into
> account, but by and large it should be the case. At least much more so
> than for `.el` files where it's clearly a real problem.
>
> > I have no reason to believe that the problems we see with native
> > compilation are related to these aspects.
>
> I'm not sure which problems you're referring to.
The Subject is "more reliable byte compilation", and we are talking
specifically about more reliable native compilation. So the problems
I was referring to are problems with compilation reliability.
> > Do you have evidence of that?
>
> IIRC, in Raman's case the evidence was that the `.eln` file was calling
> a macro as if it were a function, and that this didn't happen when using
> the `.elc` file. These problems typically happen when a `.el` file is
> miscompiled because some other ELisp file was not loaded beforehand.
And that's all? Then why not fix that problem right away, it sounds
like something that should be easy to fix. (Though I'm not sure I
understand why "some other ELisp file was not loaded beforehand" -- is
that a case of a missing 'require' or 'eval-when-compile' or somesuch?)
> In any case, the problem with compiling from the `.el` file instead of
> from the `.elc` file is real and it's easy to trigger it on purpose.
Examples? Are you saying that it's impossible to solve those
problems?
> There's a chance that it will simply encourage people to fix their ELisp
> files to better follow the (undocumented) conventions, so to some degree
> I agree that it might be preferable not to fix this issue.
Ah, so the problem is with buggy *.el files, and only with them?
next prev parent reply other threads:[~2021-10-05 11:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 10:51 More reliable byte compilation, take 45 Lars Ingebrigtsen
2021-10-04 15:36 ` Clément Pit-Claudel
2021-10-04 16:16 ` Lars Ingebrigtsen
2021-10-04 18:16 ` T.V Raman
2021-10-04 18:21 ` Eli Zaretskii
2021-10-04 19:18 ` Stefan Monnier
2021-10-04 19:51 ` Eli Zaretskii
2021-10-04 20:13 ` Stefan Monnier
2021-10-05 11:52 ` Eli Zaretskii [this message]
2021-10-05 13:27 ` Stefan Monnier
2021-10-05 14:06 ` Adam Porter
2021-10-05 15:41 ` Eli Zaretskii
2021-10-04 16:03 ` Steingold
2021-10-04 17:35 ` Lars Ingebrigtsen
2021-10-04 18:59 ` Steingold
2021-10-05 7:14 ` Lars Ingebrigtsen
2021-10-05 14:50 ` Steingold
2021-10-05 14:51 ` Steingold
2021-10-05 19:30 ` Stefan Monnier
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=83r1cz4rjl.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=cpitclaudel@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=raman@google.com \
/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).