|
From: | GNU bug Tracking System |
Subject: | bug#41242: closed (Port feature/native-comp to Windows) |
Date: | Sat, 06 Jun 2020 21:42:02 +0000 |
Your message dated Sat, 06 Jun 2020 21:41:24 +0000 with message-id <xjf3677g9dn.fsf@sdf.org> and subject line Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. has caused the debbugs.gnu.org bug report #41242, regarding Port feature/native-comp to Windows to be marked as done. (If you believe you have received this mail in error, please contact help-debbugs@gnu.org.) -- 41242: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=41242 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems
--- Begin Message ---Subject: Port feature/native-comp to Windows Date: Wed, 13 May 2020 16:26:57 -0300 The attached patches contain changes to make the feature/native-comp branch work on Windows. There are a few remaining issues: * The loading process is very slow. This is especially annoying when coupled with autoloading. For example, autoloading Helm may stall Emacs for 5 seconds in my machine. I have thought a possible solution to this problem: load the byte-compiled file and put the native-compiled version in a list. Then load that list one by one on an idle-timer, that way the UI freezes should be minimized. This could reuse the "late loading" machinery implemented for deferred compilation. * `package-delete` fails because it tries to delete the .eln file via `delete-file`. This is impossible in Windows because it's generally impossible to delete files that have an open HANDLE in the system. Three solutions have crossed my mind: - Edit `package-delete` to put the eln on a list of files that should be deleted when Emacs is closed. - Implement an unloading mechanism for native-compiled files. - Copy eln files to temporary files and load those temporary files instead. This means that deleting the original eln file is possible. I'd prefer the second option, but I have a semi-working patch for the third option. * The `emacs_dir` environment variable needs to be set when loading the dump file. It is necessary for `expand-file-name`, which calls emacs_root_dir(). I haven't investigated why this is necessary yet. One workaround would be to use GetModuleFileName() to get the path to emacs.exe when `emacs_dir` is not set.0001-HACK-Ensure-the-emacs_root_dir-function-does-not-cra.patch
Description: Binary data0002-Do-not-block-SIGIO-in-platforms-that-don-t-have-it.patch
Description: Binary data0003-Handle-setjmp-taking-two-arguments-in-Windows.patch
Description: Binary data0004-Handle-LISP_WORDS_ARE_POINTERS-and-CHECK_LISP_OBJECT.patch
Description: Binary data0005-Remove-a-layer-of-indirection-for-access-to-pure-sto.patch
Description: Binary data0006-Workaround-the-32768-chars-command-line-limit-in-Win.patch
Description: Binary data0007-Load-libgccjit-dynamically-in-Windows.patch
Description: Binary data0008-Windows-Use-NUMBER_OF_PROCESSORS-environment-variabl.patch
Description: Binary data
--- End Message ---
--- Begin Message ---Subject: Re: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file. Date: Sat, 06 Jun 2020 21:41:24 +0000 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) I did the suggested style modification myself and applied the patch as e38678b268. Thanks I'm closing this. Andrea -- akrl@sdf.org
--- End Message ---
[Prev in Thread] | Current Thread | [Next in Thread] |