GNU bug report logs -
#48025
28.0.50; Add an invocation option to inhibit native-compilation functionality
Previous Next
Reported by: Phil Sainty <psainty <at> orcon.net.nz>
Date: Mon, 26 Apr 2021 05:53:01 UTC
Severity: normal
Tags: wontfix
Found in version 28.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48025 in the body.
You can then email your comments to 48025 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Mon, 26 Apr 2021 05:53:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Phil Sainty <psainty <at> orcon.net.nz>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Mon, 26 Apr 2021 05:53:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Now that the native-compilation feature is merged, it would be very
useful to be able to build Emacs --with-native-compilation but be
able to choose to inhibit that functionality at start time via a
command-line option such as 'emacs --no-native-compilation', which
would cause Emacs to load/execute only .el and .elc files.
This will enable users to easily compare functionality with and
without native-compilation, so that native-compilation bugs can be
more easily identified and reproduced without requiring people to
maintain more than one build of Emacs in order to test how the
traditional interpreters behave.
I'm not sure if/how this ties in with the portable dumper. Perhaps
there are .eln files included in the dump? If so, perhaps the dump
would need to include both the .elc and the .eln code, and choose
which to use based on the new option.
-Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Mon, 26 Apr 2021 12:10:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 48025 <at> debbugs.gnu.org (full text, mbox):
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Date: Mon, 26 Apr 2021 17:52:52 +1200
> Cc: Andrea Corallo <akrl <at> sdf.org>
>
> Now that the native-compilation feature is merged, it would be very
> useful to be able to build Emacs --with-native-compilation but be
> able to choose to inhibit that functionality at start time via a
> command-line option such as 'emacs --no-native-compilation', which
> would cause Emacs to load/execute only .el and .elc files.
>
> This will enable users to easily compare functionality with and
> without native-compilation, so that native-compilation bugs can be
> more easily identified and reproduced without requiring people to
> maintain more than one build of Emacs in order to test how the
> traditional interpreters behave.
>
> I'm not sure if/how this ties in with the portable dumper. Perhaps
> there are .eln files included in the dump? If so, perhaps the dump
> would need to include both the .elc and the .eln code, and choose
> which to use based on the new option.
Andrea will correct me, but I think this is not trivial to implement,
not even close. Indeed, the contents of the pdumper file is different
in the two cases, and I see no easy way of having both byte-compiled
and native-compiled stuff live together in the same dump (they define
the same functions, remember?).
We could perhaps provide a special value of --temacs= switch to
temacs, so that the same temacs executable could be dumped into 2
different *.pdmp files, one with natively-compiled preloaded stuff,
the other with byte-compiled stuff; then users could use the existing
option --dump-file= to start Emacs with the non-standard pdumper file
(they will also need to set comp-deferred-compilation to nil to
prevent any run-time native-compilations once Emacs starts).
But frankly, I would hesitate to complicate Emacs even for the latter
possibility. What you ask for doesn't seem to be a user-level
feature, it is mainly important for Emacs developers, and those can
always build 2 separate binaries (e.g., I already did). Building a
differently-configured Emacs, even from the same Git repository, is so
easy that I don't really see a justification for a feature like you
describe.
(As for reproducing problems easily: it isn't hard to run the
interpreted or byte-compiled Lisp, if you can identify the relevant
Lisp files involved in the problem: just load them manually. Andrea,
am I missing something?)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Mon, 26 Apr 2021 14:11:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 48025 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Phil Sainty <psainty <at> orcon.net.nz>
>> Date: Mon, 26 Apr 2021 17:52:52 +1200
>> Cc: Andrea Corallo <akrl <at> sdf.org>
>>
>> Now that the native-compilation feature is merged, it would be very
>> useful to be able to build Emacs --with-native-compilation but be
>> able to choose to inhibit that functionality at start time via a
>> command-line option such as 'emacs --no-native-compilation', which
>> would cause Emacs to load/execute only .el and .elc files.
>>
>> This will enable users to easily compare functionality with and
>> without native-compilation, so that native-compilation bugs can be
>> more easily identified and reproduced without requiring people to
>> maintain more than one build of Emacs in order to test how the
>> traditional interpreters behave.
>>
>> I'm not sure if/how this ties in with the portable dumper. Perhaps
>> there are .eln files included in the dump? If so, perhaps the dump
>> would need to include both the .elc and the .eln code, and choose
>> which to use based on the new option.
>
> Andrea will correct me, but I think this is not trivial to implement,
> not even close. Indeed, the contents of the pdumper file is different
> in the two cases, and I see no easy way of having both byte-compiled
> and native-compiled stuff live together in the same dump (they define
> the same functions, remember?).
>
> We could perhaps provide a special value of --temacs= switch to
> temacs, so that the same temacs executable could be dumped into 2
> different *.pdmp files, one with natively-compiled preloaded stuff,
> the other with byte-compiled stuff; then users could use the existing
> option --dump-file= to start Emacs with the non-standard pdumper file
> (they will also need to set comp-deferred-compilation to nil to
> prevent any run-time native-compilations once Emacs starts).
>
> But frankly, I would hesitate to complicate Emacs even for the latter
> possibility. What you ask for doesn't seem to be a user-level
> feature, it is mainly important for Emacs developers, and those can
> always build 2 separate binaries (e.g., I already did). Building a
> differently-configured Emacs, even from the same Git repository, is so
> easy that I don't really see a justification for a feature like you
> describe.
>
> (As for reproducing problems easily: it isn't hard to run the
> interpreted or byte-compiled Lisp, if you can identify the relevant
> Lisp files involved in the problem: just load them manually. Andrea,
> am I missing something?)
No you are not, once we bootstrap and dump a native compiled Emacs
there's no way we can undone it and get the equivalent one with only
bytecode.
Other than I can mention some knobs we already have that might partially
help here:
- inibith the automatic native compilation of new code with
`comp-deferred-compilation'.
- prevent .eln from being loaded in place of bytecode with
`load-no-native'.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Tue, 27 Apr 2021 04:29:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 48025 <at> debbugs.gnu.org (full text, mbox):
> Eli Zaretskii <eliz <at> gnu.org> writes:
>> We could perhaps provide a special value of --temacs= switch to
>> temacs, so that the same temacs executable could be dumped into 2
>> different *.pdmp files, one with natively-compiled preloaded stuff,
>> the other with byte-compiled stuff; then users could use the existing
>> option --dump-file= to start Emacs with the non-standard pdumper file
>> (they will also need to set comp-deferred-compilation to nil to
>> prevent any run-time native-compilations once Emacs starts).
That sounds like a good solution (and maybe one which could be wrapped
up under a new option, if the --with-native-compilation build process
automatically generated both *.pdmp files, and Emacs knows what they
both are).
>> But frankly, I would hesitate to complicate Emacs even for the latter
>> possibility. What you ask for doesn't seem to be a user-level
>> feature, it is mainly important for Emacs developers, and those can
>> always build 2 separate binaries (e.g., I already did). Building a
>> differently-configured Emacs, even from the same Git repository, is so
>> easy that I don't really see a justification for a feature like you
>> describe.
I guess time will tell. My feeling was that if end users encounter
native-comp bugs that are not trivial for the maintainers to reproduce
(e.g. some collection of third-party packages is involved), then it
might be super helpful to be able to ask them to test with native-comp
disabled, to confirm whether or not that is a factor. As many users
will, in future, be running a native-comp Emacs which has been pre-
packaged for their OS, they will not easily be able to perform such a
test without such a feature.
It would definitely be a "nice to have". However as it's evidentially
non-trivial to support this feature, I don't know whether the effort
would actually prove worthwhile.
>> (As for reproducing problems easily: it isn't hard to run the
>> interpreted or byte-compiled Lisp, if you can identify the relevant
>> Lisp files involved in the problem: just load them manually.
I did think of that, but my feeling was that it's just not the same
thing as inhibiting the native-compilation entirely. But as an existing
alternative which would probably do the job in most cases, it's hard to
argue with.
On 27/04/21 2:10 am, Andrea Corallo wrote:
> Other than I can mention some knobs we already have that might partially
> help here:
>
> - prevent .eln from being loaded in place of bytecode with
> `load-no-native'.
Yes, that's good to know about. I see now that "apropos-variable native"
is very useful (my bad for not thinking of that earlier).
That var should definitely be noted in the manual once we have some in-
built docs for this; but in the meantime it might be very helpful to
update https://akrl.sdf.org/gccemacs.html with a collection of the ways
that users can tweak/test this feature?
> - inhibit the automatic native compilation of new code with
> `comp-deferred-compilation'.
This, OTOH, doesn't use the "native" keyword at all.
Could we rename any such variables so that everything to do with
native compilation includes the word "native"? That's a dramatically
more specific term than "compilation", so it would seem good if it
was an easy way to find/identify the native-comp options.
-Phil
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Tue, 27 Apr 2021 13:36:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 48025 <at> debbugs.gnu.org (full text, mbox):
> Cc: 48025 <at> debbugs.gnu.org
> From: Phil Sainty <psainty <at> orcon.net.nz>
> Date: Tue, 27 Apr 2021 16:28:24 +1200
>
> >> But frankly, I would hesitate to complicate Emacs even for the latter
> >> possibility. What you ask for doesn't seem to be a user-level
> >> feature, it is mainly important for Emacs developers, and those can
> >> always build 2 separate binaries (e.g., I already did). Building a
> >> differently-configured Emacs, even from the same Git repository, is so
> >> easy that I don't really see a justification for a feature like you
> >> describe.
>
> I guess time will tell. My feeling was that if end users encounter
> native-comp bugs that are not trivial for the maintainers to reproduce
> (e.g. some collection of third-party packages is involved), then it
> might be super helpful to be able to ask them to test with native-comp
> disabled, to confirm whether or not that is a factor. As many users
> will, in future, be running a native-comp Emacs which has been pre-
> packaged for their OS, they will not easily be able to perform such a
> test without such a feature.
I agree that we should probably revisit the issue after we have more
experience with native-compilation.
> > - inhibit the automatic native compilation of new code with
> > `comp-deferred-compilation'.
>
> This, OTOH, doesn't use the "native" keyword at all.
>
> Could we rename any such variables so that everything to do with
> native compilation includes the word "native"?
Yes, I think it's a good idea. Perhaps also the commands in comp.el
and even some non-interactive functions?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Wed, 28 Apr 2021 19:40:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 48025 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Cc: 48025 <at> debbugs.gnu.org
>> From: Phil Sainty <psainty <at> orcon.net.nz>
>> Date: Tue, 27 Apr 2021 16:28:24 +1200
>>
>> >> But frankly, I would hesitate to complicate Emacs even for the latter
>> >> possibility. What you ask for doesn't seem to be a user-level
>> >> feature, it is mainly important for Emacs developers, and those can
>> >> always build 2 separate binaries (e.g., I already did). Building a
>> >> differently-configured Emacs, even from the same Git repository, is so
>> >> easy that I don't really see a justification for a feature like you
>> >> describe.
>>
>> I guess time will tell. My feeling was that if end users encounter
>> native-comp bugs that are not trivial for the maintainers to reproduce
>> (e.g. some collection of third-party packages is involved), then it
>> might be super helpful to be able to ask them to test with native-comp
>> disabled, to confirm whether or not that is a factor. As many users
>> will, in future, be running a native-comp Emacs which has been pre-
>> packaged for their OS, they will not easily be able to perform such a
>> test without such a feature.
>
> I agree that we should probably revisit the issue after we have more
> experience with native-compilation.
>
>> > - inhibit the automatic native compilation of new code with
>> > `comp-deferred-compilation'.
>>
>> This, OTOH, doesn't use the "native" keyword at all.
>>
>> Could we rename any such variables so that everything to do with
>> native compilation includes the word "native"?
>
> Yes, I think it's a good idea. Perhaps also the commands in comp.el
> and even some non-interactive functions?
I'll be happy to rename these functions if we come-up with a list.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Thu, 29 Apr 2021 13:57:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 48025 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: Phil Sainty <psainty <at> orcon.net.nz>, 48025 <at> debbugs.gnu.org
> Date: Wed, 28 Apr 2021 19:39:38 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> >> Could we rename any such variables so that everything to do with
> >> native compilation includes the word "native"?
> >
> > Yes, I think it's a good idea. Perhaps also the commands in comp.el
> > and even some non-interactive functions?
>
> I'll be happy to rename these functions if we come-up with a list.
Here's a list I came up with:
comp-limple-mode
comp-speed
comp-debug
comp-verbose
comp-always-compile
comp-bootstrap-deny-list
comp-never-optimize-functions
comp-async-jobs-number
comp-async-cu-done-functions
comp-async-all-done-hook
comp-async-env-modifier-form
comp-async-report-warnings-errors
comp-async-query-on-exit
comp-native-driver-options
comp-warning-on-missing-source
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Thu, 29 Apr 2021 14:34:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 48025 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: Phil Sainty <psainty <at> orcon.net.nz>, 48025 <at> debbugs.gnu.org
>> Date: Wed, 28 Apr 2021 19:39:38 +0000
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> >> Could we rename any such variables so that everything to do with
>> >> native compilation includes the word "native"?
>> >
>> > Yes, I think it's a good idea. Perhaps also the commands in comp.el
>> > and even some non-interactive functions?
>>
>> I'll be happy to rename these functions if we come-up with a list.
>
> Here's a list I came up with:
>
> comp-limple-mode
> comp-speed
> comp-debug
> comp-verbose
> comp-always-compile
> comp-bootstrap-deny-list
> comp-never-optimize-functions
> comp-async-jobs-number
> comp-async-cu-done-functions
> comp-async-all-done-hook
> comp-async-env-modifier-form
> comp-async-report-warnings-errors
> comp-async-query-on-exit
> comp-native-driver-options
> comp-warning-on-missing-source
Thanks, should the renaming be comp-* to native-* ?
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Thu, 29 Apr 2021 15:06:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 48025 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: psainty <at> orcon.net.nz, 48025 <at> debbugs.gnu.org
> Date: Thu, 29 Apr 2021 14:33:17 +0000
>
> > comp-limple-mode
> > comp-speed
> > comp-debug
> > comp-verbose
> > comp-always-compile
> > comp-bootstrap-deny-list
> > comp-never-optimize-functions
> > comp-async-jobs-number
> > comp-async-cu-done-functions
> > comp-async-all-done-hook
> > comp-async-env-modifier-form
> > comp-async-report-warnings-errors
> > comp-async-query-on-exit
> > comp-native-driver-options
> > comp-warning-on-missing-source
>
> Thanks, should the renaming be comp-* to native-* ?
I think they all should begin with native-comp- and
comp-native-driver-options should become native-comp-driver-options.
Also, I'd prefer renaming comp-async-jobs-number to
native-comp-number-of-async-jobs.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Thu, 29 Apr 2021 15:15:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 48025 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 29 Apr 2021 18:05:01 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: psainty <at> orcon.net.nz, 48025 <at> debbugs.gnu.org
>
> > > comp-limple-mode
> > > comp-speed
> > > comp-debug
> > > comp-verbose
> > > comp-always-compile
> > > comp-bootstrap-deny-list
> > > comp-never-optimize-functions
> > > comp-async-jobs-number
> > > comp-async-cu-done-functions
> > > comp-async-all-done-hook
> > > comp-async-env-modifier-form
> > > comp-async-report-warnings-errors
> > > comp-async-query-on-exit
> > > comp-native-driver-options
> > > comp-warning-on-missing-source
> >
> > Thanks, should the renaming be comp-* to native-* ?
>
> I think they all should begin with native-comp- and
> comp-native-driver-options should become native-comp-driver-options.
> Also, I'd prefer renaming comp-async-jobs-number to
> native-comp-number-of-async-jobs.
And one more variable to rename:
comp-eln-load-path
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Thu, 29 Apr 2021 15:23:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 48025 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Thu, 29 Apr 2021 18:05:01 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: psainty <at> orcon.net.nz, 48025 <at> debbugs.gnu.org
>>
>> > > comp-limple-mode
>> > > comp-speed
>> > > comp-debug
>> > > comp-verbose
>> > > comp-always-compile
>> > > comp-bootstrap-deny-list
>> > > comp-never-optimize-functions
>> > > comp-async-jobs-number
>> > > comp-async-cu-done-functions
>> > > comp-async-all-done-hook
>> > > comp-async-env-modifier-form
>> > > comp-async-report-warnings-errors
>> > > comp-async-query-on-exit
>> > > comp-native-driver-options
>> > > comp-warning-on-missing-source
>> >
>> > Thanks, should the renaming be comp-* to native-* ?
>>
>> I think they all should begin with native-comp- and
>> comp-native-driver-options should become native-comp-driver-options.
>> Also, I'd prefer renaming comp-async-jobs-number to
>> native-comp-number-of-async-jobs.
>
> And one more variable to rename:
>
> comp-eln-load-path
Yeah was going to suggest it :)
Okay I'd just wait a bit for some other opinion/suggestion then I'll
take care of this.
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Thu, 29 Apr 2021 15:47:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 48025 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: psainty <at> orcon.net.nz, 48025 <at> debbugs.gnu.org
> Date: Thu, 29 Apr 2021 15:22:28 +0000
>
> Okay I'd just wait a bit for some other opinion/suggestion then I'll
> take care of this.
Sure, there's no rush.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Thu, 06 May 2021 15:20:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 48025 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andrea Corallo <akrl <at> sdf.org>
>> Cc: psainty <at> orcon.net.nz, 48025 <at> debbugs.gnu.org
>> Date: Thu, 29 Apr 2021 15:22:28 +0000
>>
>> Okay I'd just wait a bit for some other opinion/suggestion then I'll
>> take care of this.
>
> Sure, there's no rush.
Should be done as of fbbcbed10e, hopefully I've done it with no errors
(works for me here).
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Thu, 06 May 2021 15:42:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 48025 <at> debbugs.gnu.org (full text, mbox):
> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: psainty <at> orcon.net.nz, 48025 <at> debbugs.gnu.org
> Date: Thu, 06 May 2021 15:19:47 +0000
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Should be done as of fbbcbed10e, hopefully I've done it with no errors
> (works for me here).
Thanks!
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#48025
; Package
emacs
.
(Thu, 30 Jun 2022 13:10:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 48025 <at> debbugs.gnu.org (full text, mbox):
Phil Sainty <psainty <at> orcon.net.nz> writes:
> Now that the native-compilation feature is merged, it would be very
> useful to be able to build Emacs --with-native-compilation but be
> able to choose to inhibit that functionality at start time via a
> command-line option such as 'emacs --no-native-compilation', which
> would cause Emacs to load/execute only .el and .elc files.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
Skimming this bug report, it seems like the conclusion here was that
this would be very difficult to implement, and that the effect (allowing
users to compare) wasn't compelling enough, so I'm closing this bug
report.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) wontfix.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 30 Jun 2022 13:10:03 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
48025 <at> debbugs.gnu.org and Phil Sainty <psainty <at> orcon.net.nz>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Thu, 30 Jun 2022 13:10:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 29 Jul 2022 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 271 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.