* disable automatic native-compilation? @ 2022-07-09 16:49 Stephen Leake 2022-07-09 17:23 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Stephen Leake @ 2022-07-09 16:49 UTC (permalink / raw) To: emacs-devel I've just started using Emacs 28. I'm trying run the ada-mode test suite, which lauches a new Emacs instance for each test. Now that instance also starts a native-compile process, which slows things down (a lot), and does not terminate cleanly when the Emacs instance does at the end of the test. I'm on Windows, so this pops up a dialog that I have to acknowledge eventually. The elisp manual section on native compilation does not say how to disable it. I managed to disable starting the native-compile process by: (defun native-comp-available-p () nil) That sometimes causes an error about "can't find libgccjit", which aborts the test. I can't track down the specific cause of that error, because even C-h f foo gives the "can't find libgccjit" error once it happens. I tried M-x apropos-variable native, which turned up some interesting possibilities: native-comp-deferred-compilation The documentation for this variable says: "If non-nil compile loaded .elc files asynchronously." what happens if this is nil? the files are compiled synchronously, or not at all? Setting that nil instead of redefining native-comp-available-p seems to work. So, I suggest: - There should be a simple way to completely disable native compilation; Emacs should never do anything that I can't control. If setting native-comp-deferred-compilation nil is the right way to do this, it should be documented in the native compilation section of the elisp manual. - When native-comp-available-p returns nil, there should be no errors about libgccjit -- -- Stephe ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-09 16:49 disable automatic native-compilation? Stephen Leake @ 2022-07-09 17:23 ` Eli Zaretskii 2022-07-10 15:10 ` Lynn Winebarger 2022-07-09 22:36 ` Tor Kringeland 2022-08-06 15:32 ` Lynn Winebarger 2 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-07-09 17:23 UTC (permalink / raw) To: Stephen Leake; +Cc: emacs-devel > From: Stephen Leake <stephen_leake@stephe-leake.org> > Date: Sat, 09 Jul 2022 09:49:59 -0700 > > I've just started using Emacs 28. I'm trying run the ada-mode test > suite, which lauches a new Emacs instance for each test. > > Now that instance also starts a native-compile process, which slows > things down (a lot), and does not terminate cleanly when the Emacs > instance does at the end of the test. How does it not "terminate cleanly"? what uncleanliness is left? Please do tell the details. > I'm on Windows, so this pops up a dialog that I have to acknowledge > eventually. What dialog did pop up that you needed to acknowledge? what did it say? > The elisp manual section on native compilation does not say how to > disable it. That's because we don't see a need for disabling that, in a build that supports native compilation. The thought was that people who don't want native compilation will build Emacs without it in the first place. > native-comp-deferred-compilation > > The documentation for this variable says: > "If non-nil compile loaded .elc files asynchronously." > > what happens if this is nil? the files are compiled synchronously, or > not at all? You will need to compile them by hand in that case. Automatic native compilation always works asynchronously, because otherwise it would have wedged your session for many seconds, something that is unthinkable. > So, I suggest: > > - There should be a simple way to completely disable native compilation; > Emacs should never do anything that I can't control. I don't necessarily agree. Emacs doesn't do here anything different from what it did before: it loads a compiled Lisp library when you request that. It only compiles it to native code the first time it is loaded when no .eln file exists for it, that's all. But that's a side effect of loading the natively-compiled Lisp that you requested in a build that _you_ built with natively-compilation support. It sounds like you encountered problems in some very special situation, where you are running tests using sub-processes, and your test suite was not ready for native-compilation. So I'm not sure we should draw far-fetching conclusion from your use case. But whether this impression of mine is correct can only be established by discussing the details of your scenario, which you didn't provide. I suggest to submit a detailed bug report. > If setting native-comp-deferred-compilation nil is the right way to > do this, it should be documented in the native compilation section > of the elisp manual. That variable is not a user variable, it exists for internal use purposes. The ELisp manual does document how to disable native-compilation of a specific file (similarly to how you disable byte-compilation of a file). > - When native-comp-available-p returns nil, there should be no errors > about libgccjit Please tell the details and present a reproducible recipe (preferably in a bug report), then we can discuss what happens in that specific situation. In general, you are not supposed to override that function unless you know what you are doing. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-09 17:23 ` Eli Zaretskii @ 2022-07-10 15:10 ` Lynn Winebarger 2022-07-10 15:39 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Lynn Winebarger @ 2022-07-10 15:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Stephen Leake, emacs-devel On Sat, Jul 9, 2022 at 1:26 PM Eli Zaretskii <eliz@gnu.org> wrote: > > > From: Stephen Leake <stephen_leake@stephe-leake.org> > > Date: Sat, 09 Jul 2022 09:49:59 -0700 > > > > I've just started using Emacs 28. I'm trying run the ada-mode test > > suite, which lauches a new Emacs instance for each test. > > > > Now that instance also starts a native-compile process, which slows > > things down (a lot), and does not terminate cleanly when the Emacs > > instance does at the end of the test. > > How does it not "terminate cleanly"? what uncleanliness is left? > Please do tell the details. > > > I'm on Windows, so this pops up a dialog that I have to acknowledge > > eventually. > > What dialog did pop up that you needed to acknowledge? what did it > say? > If Stephen's building native compilation under cygwin, perhaps he's referring to an error message about not being able to load the ELN file, either in the form of a "fork" failure, or an explicit complaint about the dll base address conflicting with another dll that's already been loaded. For a 64-bit build, a restart of emacs seems to be enough to cure the issue, although I have also had issues that didn't seem to be resolved without doing a "rebase all". I don't know if this behavior is considered a bug (in either libgccjit or emacs) or just a basic limitation of using the cygwin platform. It is definitely an annoyance when either installing packages or when one of the package's features/modules is autoloaded the first time. Lynn ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-10 15:10 ` Lynn Winebarger @ 2022-07-10 15:39 ` Eli Zaretskii 2022-07-10 18:32 ` Lynn Winebarger 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-07-10 15:39 UTC (permalink / raw) To: Lynn Winebarger, Ken Brown; +Cc: stephen_leake, emacs-devel > From: Lynn Winebarger <owinebar@gmail.com> > Date: Sun, 10 Jul 2022 11:10:27 -0400 > Cc: Stephen Leake <stephen_leake@stephe-leake.org>, emacs-devel <emacs-devel@gnu.org> > > If Stephen's building native compilation under cygwin, perhaps he's > referring to an error message about not being able to load the ELN > file, either in the form of a "fork" failure, or an explicit complaint > about the dll base address conflicting with another dll that's already > been loaded. For a 64-bit build, a restart of emacs seems to be > enough to cure the issue, although I have also had issues that didn't > seem to be resolved without doing a "rebase all". > I don't know if this behavior is considered a bug (in either libgccjit > or emacs) or just a basic limitation of using the cygwin platform. > It is definitely an annoyance when either installing packages or when > one of the package's features/modules is autoloaded the first time. This was discussed with Ken Brown (CC'ed) at some point, but I don't remember what was the conclusion for the future. (And I don't think Stephen uses Cygwin. But I may be mistaken.) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-10 15:39 ` Eli Zaretskii @ 2022-07-10 18:32 ` Lynn Winebarger 2022-07-10 21:54 ` Ken Brown 0 siblings, 1 reply; 18+ messages in thread From: Lynn Winebarger @ 2022-07-10 18:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Ken Brown, Stephen Leake, emacs-devel I see a discussion under bug #50666 - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50666 [ note - only found by google site search on lists.gnu.org for "Ken Brown" "cygwin" "native", the bug did not show up when I used debbugs's search for bugs for package "emacs" with "cygwin" in the subject ]. It seems to have focused on the 32-bit architecture, but I only use 64-bit targets. I'm updating dozens of packages at a time, although the practical limit seems to be 20-30 in a pass before I get an error about having run out of some resource (process ids or file descriptors or something along those lines, not sure). In any case, if the eln files are asynchronously getting rebased before being loaded, perhaps there's a race condition somewhere? I can file a bug if merited. Lynn On Sun, Jul 10, 2022 at 11:39 AM Eli Zaretskii <eliz@gnu.org> wrote: > > > From: Lynn Winebarger <owinebar@gmail.com> > > Date: Sun, 10 Jul 2022 11:10:27 -0400 > > Cc: Stephen Leake <stephen_leake@stephe-leake.org>, emacs-devel <emacs-devel@gnu.org> > > > > If Stephen's building native compilation under cygwin, perhaps he's > > referring to an error message about not being able to load the ELN > > file, either in the form of a "fork" failure, or an explicit complaint > > about the dll base address conflicting with another dll that's already > > been loaded. For a 64-bit build, a restart of emacs seems to be > > enough to cure the issue, although I have also had issues that didn't > > seem to be resolved without doing a "rebase all". > > I don't know if this behavior is considered a bug (in either libgccjit > > or emacs) or just a basic limitation of using the cygwin platform. > > It is definitely an annoyance when either installing packages or when > > one of the package's features/modules is autoloaded the first time. > > This was discussed with Ken Brown (CC'ed) at some point, but I don't > remember what was the conclusion for the future. > > (And I don't think Stephen uses Cygwin. But I may be mistaken.) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-10 18:32 ` Lynn Winebarger @ 2022-07-10 21:54 ` Ken Brown 2022-07-11 1:52 ` Ken Brown 0 siblings, 1 reply; 18+ messages in thread From: Ken Brown @ 2022-07-10 21:54 UTC (permalink / raw) To: Lynn Winebarger, Eli Zaretskii; +Cc: Stephen Leake, emacs-devel, Achim Gratz On 7/10/2022 2:32 PM, Lynn Winebarger wrote: > I see a discussion under bug #50666 - > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50666 [ note - only > found by google site search on lists.gnu.org for "Ken Brown" "cygwin" > "native", the bug did not show up when I used debbugs's search for > bugs for package "emacs" with "cygwin" in the subject ]. > It seems to have focused on the 32-bit architecture, but I only use > 64-bit targets. Native compilation is unusable on 32-bit Cygwin, and this is reflected in the configure script. (See the --with-cygwin32-native-compilation configure option.) In the 64-bit case, Achim Gratz's autorebase postinstall script takes care of rebasing the .eln files on a regular basis, provided the user has set things up appropriately. Instructions can be found in the announcement at https://cygwin.com/pipermail/cygwin-announce/2022-April/010529.html In the 3 months since I sent that announcement, I have not heard from a single Cygwin user about rebase issues. This might simply mean that very few users have tried the native compilation release. I myself use that release daily, and I can only recall one instance in which I saw a fork failure and had to exit emacs and rebase. In summary, I would say that native compilation is usable with very occasional minor annoyances on 64-bit Cygwin. But I doubt if I will ever make it the default Cygwin build, simply because I don't want to be inundated with emails from people who haven't read the release announcement. Ken ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-10 21:54 ` Ken Brown @ 2022-07-11 1:52 ` Ken Brown 2022-07-11 2:39 ` Lynn Winebarger 0 siblings, 1 reply; 18+ messages in thread From: Ken Brown @ 2022-07-11 1:52 UTC (permalink / raw) To: Lynn Winebarger, Eli Zaretskii; +Cc: Stephen Leake, emacs-devel, Achim Gratz On 7/10/2022 5:54 PM, Ken Brown wrote: > On 7/10/2022 2:32 PM, Lynn Winebarger wrote: >> I see a discussion under bug #50666 - >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50666 [ note - only >> found by google site search on lists.gnu.org for "Ken Brown" "cygwin" >> "native", the bug did not show up when I used debbugs's search for >> bugs for package "emacs" with "cygwin" in the subject ]. >> It seems to have focused on the 32-bit architecture, but I only use >> 64-bit targets. > > Native compilation is unusable on 32-bit Cygwin, and this is reflected in the > configure script. (See the --with-cygwin32-native-compilation configure option.) > > In the 64-bit case, Achim Gratz's autorebase postinstall script takes care of > rebasing the .eln files on a regular basis, provided the user has set things up > appropriately. Instructions can be found in the announcement at > > https://cygwin.com/pipermail/cygwin-announce/2022-April/010529.html > > In the 3 months since I sent that announcement, I have not heard from a single > Cygwin user about rebase issues. This might simply mean that very few users > have tried the native compilation release. > > I myself use that release daily, and I can only recall one instance in which I > saw a fork failure and had to exit emacs and rebase. > > In summary, I would say that native compilation is usable with very occasional > minor annoyances on 64-bit Cygwin. But I doubt if I will ever make it the > default Cygwin build, simply because I don't want to be inundated with emails > from people who haven't read the release announcement. Lynn, Rereading your earlier message about problems during package installation, I see I didn't really respond to that. But it has nothing to do with the present bug, so please make a fresh bug report and give full details. And please follow the instructions in the announcement I cited. If you're working in your own build of Cygwin emacs that you haven't installed, you might also have to add its native-lisp directory to /var/lib/rebase/userpath.d/<username> Ken ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-11 1:52 ` Ken Brown @ 2022-07-11 2:39 ` Lynn Winebarger 2022-07-11 13:37 ` Ken Brown 0 siblings, 1 reply; 18+ messages in thread From: Lynn Winebarger @ 2022-07-11 2:39 UTC (permalink / raw) To: Ken Brown; +Cc: Eli Zaretskii, Stephen Leake, emacs-devel, Achim Gratz [-- Attachment #1: Type: text/plain, Size: 3001 bytes --] On Sun, Jul 10, 2022, 9:53 PM Ken Brown <kbrown@cornell.edu> wrote: > On 7/10/2022 5:54 PM, Ken Brown wrote: > > On 7/10/2022 2:32 PM, Lynn Winebarger wrote: > >> I see a discussion under bug #50666 - > >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50666 [ note - only > >> found by google site search on lists.gnu.org for "Ken Brown" "cygwin" > >> "native", the bug did not show up when I used debbugs's search for > >> bugs for package "emacs" with "cygwin" in the subject ]. > >> It seems to have focused on the 32-bit architecture, but I only use > >> 64-bit targets. > > > > Native compilation is unusable on 32-bit Cygwin, and this is reflected > in the > > configure script. (See the --with-cygwin32-native-compilation configure > option.) > > > > In the 64-bit case, Achim Gratz's autorebase postinstall script takes > care of > > rebasing the .eln files on a regular basis, provided the user has set > things up > > appropriately. Instructions can be found in the announcement at > > > > https://cygwin.com/pipermail/cygwin-announce/2022-April/010529.html > > > > In the 3 months since I sent that announcement, I have not heard from a > single > > Cygwin user about rebase issues. This might simply mean that very few > users > > have tried the native compilation release. > Will do, but could you include the details of the announcement in the emacs source distribution somewhere, as is done for the other variants with specific instructions? I'm only incidentally building it in a cygwin environment - it didn't even occur to me to check the general cygwin mailing list. > > > I myself use that release daily, and I can only recall one instance in > which I > > saw a fork failure and had to exit emacs and rebase. > > > > In summary, I would say that native compilation is usable with very > occasional > > minor annoyances on 64-bit Cygwin. But I doubt if I will ever make it > the > > default Cygwin build, simply because I don't want to be inundated with > emails > > from people who haven't read the release announcement. > > Lynn, > > Rereading your earlier message about problems during package installation, > I see > I didn't really respond to that. But it has nothing to do with the > present bug, > so please make a fresh bug report and give full details. And please > follow the > instructions in the announcement I cited. If you're working in your own > build > of Cygwin emacs that you haven't installed, you might also have to add its > native-lisp directory to > > /var/lib/rebase/userpath.d/<username> I am doing exactly what you surmised, running a build I haven't installed - in fact that I built with --prefix=/does/not/exist/ to ensure system installed site-lisp files will not get injected into the load-path while doing do. So I'll try that first. Although I think the packages generating the fork failures should be going into the cache in my home directory. If there are still issues, did you mean to log a bug with cygwin or emacs? Lynn [-- Attachment #2: Type: text/html, Size: 4356 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-11 2:39 ` Lynn Winebarger @ 2022-07-11 13:37 ` Ken Brown 2022-07-11 13:56 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Ken Brown @ 2022-07-11 13:37 UTC (permalink / raw) To: Lynn Winebarger; +Cc: Eli Zaretskii, Stephen Leake, emacs-devel, Achim Gratz On 7/10/2022 10:39 PM, Lynn Winebarger wrote: > On Sun, Jul 10, 2022, 9:53 PM Ken Brown <kbrown@cornell.edu > <mailto:kbrown@cornell.edu>> wrote: > > On 7/10/2022 5:54 PM, Ken Brown wrote: > > Native compilation is unusable on 32-bit Cygwin, and this is reflected in > the > > configure script. (See the --with-cygwin32-native-compilation configure > option.) > > > > In the 64-bit case, Achim Gratz's autorebase postinstall script takes > care of > > rebasing the .eln files on a regular basis, provided the user has set > things up > > appropriately. Instructions can be found in the announcement at > > > > https://cygwin.com/pipermail/cygwin-announce/2022-April/010529.html > <https://cygwin.com/pipermail/cygwin-announce/2022-April/010529.html> > > > > In the 3 months since I sent that announcement, I have not heard from a > single > > Cygwin user about rebase issues. This might simply mean that very few users > > have tried the native compilation release. > > > Will do, but could you include the details of the announcement in the emacs > source distribution somewhere, as is done for the other variants with specific > instructions? I'm only incidentally building it in a cygwin environment - it > didn't even occur to me to check the general cygwin mailing list. Yes, I'll add something to etc/PROBLEMS unless you or Eli can suggest a better place. > > > > I myself use that release daily, and I can only recall one instance in > which I > > saw a fork failure and had to exit emacs and rebase. > > > > In summary, I would say that native compilation is usable with very > occasional > > minor annoyances on 64-bit Cygwin. But I doubt if I will ever make it the > > default Cygwin build, simply because I don't want to be inundated with > emails > > from people who haven't read the release announcement. > > Lynn, > > Rereading your earlier message about problems during package installation, I > see > I didn't really respond to that. But it has nothing to do with the present > bug, > so please make a fresh bug report and give full details. And please follow the > instructions in the announcement I cited. If you're working in your own build > of Cygwin emacs that you haven't installed, you might also have to add its > native-lisp directory to > > /var/lib/rebase/userpath.d/<username> > > > I am doing exactly what you surmised, running a build I haven't installed - in > fact that I built with --prefix=/does/not/exist/ to ensure system installed > site-lisp files will not get injected into the load-path while doing do. So > I'll try that first. Although I think the packages generating the fork failures > should be going into the cache in my home directory. That's true, but Cygwin's autorebase facility needs to know about *all* .eln files that might be used, in order to try to maintain a conflict-free set of base addresses. And I forgot to say that after you've created /var/lib/rebase/userpath.d/<username> with the appropriate paths, you should shut down all Cygwin processes and run Cygwin's setup program. (You don't have to install anything; this is just to let the autorebase postinstall script run.) > If there are still issues, did you mean to log a bug with cygwin or emacs? I meant emacs. Thanks. Ken ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-11 13:37 ` Ken Brown @ 2022-07-11 13:56 ` Eli Zaretskii 2022-07-11 17:19 ` Ken Brown 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-07-11 13:56 UTC (permalink / raw) To: Ken Brown; +Cc: owinebar, stephen_leake, emacs-devel, Stromeko > Date: Mon, 11 Jul 2022 09:37:35 -0400 > Cc: Eli Zaretskii <eliz@gnu.org>, > Stephen Leake <stephen_leake@stephe-leake.org>, > emacs-devel <emacs-devel@gnu.org>, Achim Gratz <Stromeko@nexgo.de> > From: Ken Brown <kbrown@cornell.edu> > > > Will do, but could you include the details of the announcement in the emacs > > source distribution somewhere, as is done for the other variants with specific > > instructions? I'm only incidentally building it in a cygwin environment - it > > didn't even occur to me to check the general cygwin mailing list. > > Yes, I'll add something to etc/PROBLEMS unless you or Eli can suggest a better > place. PROBLEMS is fine for this kind of information. But please add that to the release branch, as it is relevant to Emacs 28. Thanks. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-11 13:56 ` Eli Zaretskii @ 2022-07-11 17:19 ` Ken Brown 0 siblings, 0 replies; 18+ messages in thread From: Ken Brown @ 2022-07-11 17:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: owinebar, stephen_leake, emacs-devel, Stromeko On 7/11/2022 9:56 AM, Eli Zaretskii wrote: >> Date: Mon, 11 Jul 2022 09:37:35 -0400 >> From: Ken Brown <kbrown@cornell.edu> >> Yes, I'll add something to etc/PROBLEMS unless you or Eli can suggest a better >> place. > > PROBLEMS is fine for this kind of information. But please add that to > the release branch, as it is relevant to Emacs 28. OK, I've done this. Lynn, I hope this is helpful for you. If you still have problems when installing/updating several packages, we'll have to think harder about a fix or workaround. Or we might just have to add that to etc/PROBLEMS as a known limitation of native compilation on Cygwin. Ken ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-09 16:49 disable automatic native-compilation? Stephen Leake 2022-07-09 17:23 ` Eli Zaretskii @ 2022-07-09 22:36 ` Tor Kringeland 2022-07-10 8:58 ` Philip Kaludercic 2022-07-11 12:54 ` Andrea Corallo 2022-08-06 15:32 ` Lynn Winebarger 2 siblings, 2 replies; 18+ messages in thread From: Tor Kringeland @ 2022-07-09 22:36 UTC (permalink / raw) To: Stephen Leake, emacs-devel Stephen Leake <stephen_leake@stephe-leake.org> writes: > - There should be a simple way to completely disable native compilation; > Emacs should never do anything that I can't control. If setting > native-comp-deferred-compilation nil is the right way to do this, it > should be documented in the native compilation section of the elisp > manual. Doesn't setting (setq native-comp-speed -1) disable native compilation? ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-09 22:36 ` Tor Kringeland @ 2022-07-10 8:58 ` Philip Kaludercic 2022-07-11 12:54 ` Andrea Corallo 1 sibling, 0 replies; 18+ messages in thread From: Philip Kaludercic @ 2022-07-10 8:58 UTC (permalink / raw) To: Tor Kringeland; +Cc: Stephen Leake, emacs-devel Tor Kringeland <tor.kringeland@ntnu.no> writes: > Stephen Leake <stephen_leake@stephe-leake.org> writes: > >> - There should be a simple way to completely disable native compilation; >> Emacs should never do anything that I can't control. If setting >> native-comp-deferred-compilation nil is the right way to do this, it >> should be documented in the native compilation section of the elisp >> manual. > > Doesn't setting > > (setq native-comp-speed -1) > > disable native compilation? The docstring says it does, but it certainly is not an intuitive option if you are looking for a way to disable native comp. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-09 22:36 ` Tor Kringeland 2022-07-10 8:58 ` Philip Kaludercic @ 2022-07-11 12:54 ` Andrea Corallo 2022-07-12 11:04 ` Tor Kringeland 1 sibling, 1 reply; 18+ messages in thread From: Andrea Corallo @ 2022-07-11 12:54 UTC (permalink / raw) To: Tor Kringeland; +Cc: Stephen Leake, emacs-devel Tor Kringeland <tor.kringeland@ntnu.no> writes: > Stephen Leake <stephen_leake@stephe-leake.org> writes: > >> - There should be a simple way to completely disable native compilation; >> Emacs should never do anything that I can't control. If setting >> native-comp-deferred-compilation nil is the right way to do this, it >> should be documented in the native compilation section of the elisp >> manual. > > Doesn't setting > > (setq native-comp-speed -1) > > disable native compilation? Not "completely". `native-comp-speed' works at function per function level. A function copiled with native-comp-speed -1 will still be enclosed in the produced .eln file but in bytecode form. Indeed setting it globally will have as result the production of the same .eln files but those will include the bytecode definition of the compiled functions. BR Andrea ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-11 12:54 ` Andrea Corallo @ 2022-07-12 11:04 ` Tor Kringeland 2022-07-12 11:27 ` Tor Kringeland 0 siblings, 1 reply; 18+ messages in thread From: Tor Kringeland @ 2022-07-12 11:04 UTC (permalink / raw) To: Andrea Corallo; +Cc: Stephen Leake, emacs-devel Andrea Corallo <akrl@sdf.org> writes: > Not "completely". `native-comp-speed' works at function per function > level. A function copiled with native-comp-speed -1 will still be > enclosed in the produced .eln file but in bytecode form. Indeed setting > it globally will have as result the production of the same .eln files > but those will include the bytecode definition of the compiled > functions. I see. Maybe this could be mentioned explicitly in the manual? What the manual says now is consistent with what you say, but when I read it I got the impression that setting 'native-comp-speed' to -1 in early-init.el would completely disable native compilation/wouldn't generate the .eln files at all. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-12 11:04 ` Tor Kringeland @ 2022-07-12 11:27 ` Tor Kringeland 2022-07-12 13:29 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Tor Kringeland @ 2022-07-12 11:27 UTC (permalink / raw) To: Andrea Corallo; +Cc: Stephen Leake, emacs-devel Tor Kringeland <tor.kringeland@ntnu.no> writes: > I see. Maybe this could be mentioned explicitly in the manual? What > the manual says now is consistent with what you say, but when I read it > I got the impression that setting 'native-comp-speed' to -1 in > early-init.el would completely disable native compilation/wouldn't > generate the .eln files at all. Nevermind, it seems like Eli Zaretskii thought of the same and already changed the manual and doc string to be more explicit about this. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-12 11:27 ` Tor Kringeland @ 2022-07-12 13:29 ` Eli Zaretskii 0 siblings, 0 replies; 18+ messages in thread From: Eli Zaretskii @ 2022-07-12 13:29 UTC (permalink / raw) To: Tor Kringeland; +Cc: akrl, stephen_leake, emacs-devel > From: Tor Kringeland <tor.kringeland@ntnu.no> > CC: Stephen Leake <stephen_leake@stephe-leake.org>, emacs-devel > <emacs-devel@gnu.org> > Date: Tue, 12 Jul 2022 11:27:29 +0000 > > Tor Kringeland <tor.kringeland@ntnu.no> writes: > > > I see. Maybe this could be mentioned explicitly in the manual? What > > the manual says now is consistent with what you say, but when I read it > > I got the impression that setting 'native-comp-speed' to -1 in > > early-init.el would completely disable native compilation/wouldn't > > generate the .eln files at all. > > Nevermind, it seems like Eli Zaretskii thought of the same and already > changed the manual and doc string to be more explicit about this. You are welcome ;-) ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: disable automatic native-compilation? 2022-07-09 16:49 disable automatic native-compilation? Stephen Leake 2022-07-09 17:23 ` Eli Zaretskii 2022-07-09 22:36 ` Tor Kringeland @ 2022-08-06 15:32 ` Lynn Winebarger 2 siblings, 0 replies; 18+ messages in thread From: Lynn Winebarger @ 2022-08-06 15:32 UTC (permalink / raw) To: Stephen Leake; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 240 bytes --] On Sat, Jul 9, 2022, 12:51 PM Stephen Leake <stephen_leake@stephe-leake.org> wrote: > The elisp manual section on native compilation does not say how to > disable it. > I set native-comp-deferred-compilation-deny-list to '("/.*/"). Lynn [-- Attachment #2: Type: text/html, Size: 829 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-08-06 15:32 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-07-09 16:49 disable automatic native-compilation? Stephen Leake 2022-07-09 17:23 ` Eli Zaretskii 2022-07-10 15:10 ` Lynn Winebarger 2022-07-10 15:39 ` Eli Zaretskii 2022-07-10 18:32 ` Lynn Winebarger 2022-07-10 21:54 ` Ken Brown 2022-07-11 1:52 ` Ken Brown 2022-07-11 2:39 ` Lynn Winebarger 2022-07-11 13:37 ` Ken Brown 2022-07-11 13:56 ` Eli Zaretskii 2022-07-11 17:19 ` Ken Brown 2022-07-09 22:36 ` Tor Kringeland 2022-07-10 8:58 ` Philip Kaludercic 2022-07-11 12:54 ` Andrea Corallo 2022-07-12 11:04 ` Tor Kringeland 2022-07-12 11:27 ` Tor Kringeland 2022-07-12 13:29 ` Eli Zaretskii 2022-08-06 15:32 ` Lynn Winebarger
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.