unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: akrl--- via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Mauricio Collares <mauricio@collares.org>
Cc: 45854-done@debbugs.gnu.org
Subject: bug#45854: 28.0.50; [feature/native-comp] autoload behavior different in the presence of errors
Date: Mon, 01 Feb 2021 14:00:22 +0000	[thread overview]
Message-ID: <xjflfc7ubux.fsf@sdf.org> (raw)
In-Reply-To: <87bld4lzqm.fsf@collares.org> (Mauricio Collares's message of "Mon, 01 Feb 2021 09:49:21 -0300")

Mauricio Collares <mauricio@collares.org> writes:

> Andrea Corallo <akrl@sdf.org> writes:
>> Here I'm,
>>
>> I can see the same exact behavior on current master as on a native-comp
>> build so I believe this is not a misbehavior.  I did the two experiments
>> starting from a clean .emacs.d to avoid state issues.
>
> Hi Andrea,
>
> Yes, I now agree. Starting with "HOME=~/tmp", a git bisect says that
> master changed behaviour at 9973019764250ac1f4d77a6b426cdd9c241151c5
> too. So this is not a problem with native-compilation and the bug I
> reported is invalid. Truly sorry for the confusion. I took care to
> delete ~/.emacs.d/elpa and the eln-cache directories between tests but
> there must be additional state that interfered with my initial testing.

No problem.

> I have one last question to ask you. The original investigation started
> because failure to compile a trampoline (due to an empty
> comp-eln-load-path, say) previously didn't interrupt package
> installation, and after changes on master it now does. So the remaining
> question is: Is triggering trampoline compilation expected even when
> running emacs non-interactively in a context (such as in the above
> testcase with an uncommented (provide 'transientx)) that otherwise does
> not generate .eln files? If this is the intended behaviour, would it
> make sense to make trampoline compilation failure emit a warning instead
> of an error in those contexts?

A trampoline is requested each time a primitive function gets redefined
or advised, if this is not available it gets synthesized.  Each eln
might make use of this, not only the one being compiled or installed
therfore is mandatory to have in interactive sessions as well as in non
interactive.  If we cannot satisfy this condition for any reason I think
is correct to have an error as Emacs might misbehave.

I'm not sure about what's going on in this specific case but if the
trampoline is requested means a primitive is being redefined or advised.

Okay I'm closing this bug.

Thanks

  Andrea





      reply	other threads:[~2021-02-01 14:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14  2:52 bug#45854: 28.0.50; [feature/native-comp] autoload behavior different in the presence of errors Mauricio Collares
     [not found] ` <handler.45854.B.161059277013405.ack@debbugs.gnu.org>
2021-01-14 12:01   ` Mauricio Collares
2021-01-14 14:23     ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-17 16:03       ` akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-17 15:29 ` Andrea Corallo
2021-01-17 15:32   ` akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-18 12:36   ` Mauricio Collares
2021-01-18 20:56     ` akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-22 22:00       ` Mauricio Collares
2021-01-28 21:11         ` akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-28 22:04           ` Mauricio Collares
2021-01-29  9:08             ` akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-01-30 14:24               ` akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-01 12:49                 ` Mauricio Collares
2021-02-01 14:00                   ` akrl--- via Bug reports for GNU Emacs, the Swiss army knife of text editors [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

  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=xjflfc7ubux.fsf@sdf.org \
    --to=bug-gnu-emacs@gnu.org \
    --cc=45854-done@debbugs.gnu.org \
    --cc=akrl@sdf.org \
    --cc=mauricio@collares.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 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).