* bug#65908: 29.1.50; Emacs 29 regresses on macOS @ 2023-09-13 6:47 Zhang Haijun 2023-10-04 5:44 ` Gerd Möllmann 0 siblings, 1 reply; 45+ messages in thread From: Zhang Haijun @ 2023-09-13 6:47 UTC (permalink / raw) To: 65908 [-- Attachment #1: Type: text/plain, Size: 2426 bytes --] 1. emacs -Q 2. paste the following code to scratch buffer and execute it for saveral times (benchmark-progn (setq enable-dir-local-variables nil enable-local-variables nil) (let* ((test-dir "~/source/emacs-git/lisp") (file-list (directory-files test-dir t "\\`[fsw].*[.]el\\'" t)) (start-tm (current-time)) end-tm buf buf-list) (dolist (test-file file-list) (setq buf (find-file-noselect test-file)) (with-current-buffer buf (goto-char (point-min)) (while (not (eobp)) (end-of-defun))) (setq buf-list (cons buf buf-list))) (setq end-tm (current-time)) (dolist (buf buf-list) (kill-buffer buf)) (let ((delta (time-subtract end-tm start-tm))) (message "--- files: %d, delta: %s" (length file-list) (float-time delta))))) ======== Result for Emacs 27: ====== --- files: 61, delta: 3.021547 Elapsed time: 3.030485s (0.173305s in 14 GCs) "--- files: 61, delta: 3.021547" --- files: 61, delta: 3.1373 Elapsed time: 3.145406s (0.181551s in 14 GCs) "--- files: 61, delta: 3.1373" --- files: 61, delta: 3.093033 Elapsed time: 3.100581s (0.162783s in 13 GCs) "--- files: 61, delta: 3.093033" ======== Result for Emacs 29: ======= --- files: 61, delta: 5.271817 Elapsed time: 5.278284s (0.174266s in 13 GCs) "--- files: 61, delta: 5.271817" --- files: 61, delta: 4.919798 Elapsed time: 4.923492s (0.162042s in 13 GCs) "--- files: 61, delta: 4.919798" --- files: 61, delta: 5.127965 Elapsed time: 5.131604s (0.154718s in 12 GCs) "--- files: 61, delta: 5.127965" --- files: 61, delta: 4.978964 Elapsed time: 4.982757s (0.149401s in 12 GCs) "--- files: 61, delta: 4.978964" Time used in Emacs 29 is 1.6x than in Emacs 27. They are all built with "-O2". I also tested on Linux. There is no such big regress. [-- Attachment #2: Type: text/html, Size: 6104 bytes --] ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-09-13 6:47 bug#65908: 29.1.50; Emacs 29 regresses on macOS Zhang Haijun @ 2023-10-04 5:44 ` Gerd Möllmann 2023-10-04 7:38 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-04 5:44 UTC (permalink / raw) To: Zhang Haijun; +Cc: 65908 Zhang Haijun <ccsmile2008@outlook.com> writes: > 1 emacs -Q > 2 paste the following code to scratch buffer and execute it for saveral times > > (benchmark-progn > (setq enable-dir-local-variables nil > enable-local-variables nil) > > (let* ((test-dir "~/source/emacs-git/lisp") > (file-list (directory-files test-dir t > "\\`[fsw].*[.]el\\'" t)) > (start-tm (current-time)) > end-tm buf buf-list) > > (dolist (test-file file-list) > (setq buf (find-file-noselect test-file)) > (with-current-buffer buf > (goto-char (point-min)) > (while (not (eobp)) > (end-of-defun))) > (setq buf-list (cons buf buf-list))) > > (setq end-tm (current-time)) > > (dolist (buf buf-list) > (kill-buffer buf)) > > (let ((delta (time-subtract end-tm start-tm))) > (message "--- files: %d, delta: %s" > (length file-list) (float-time delta))))) (Your mailer does strange things with whitespace...) > Time used in Emacs 29 is 1.6x than in Emacs 27. They are all built with "-O2". > I also tested on Linux. There is no such big regress. Thanks for the report. I can reproduce this on macOS 14.0 (OCLP). emacs-28, HEAD: "--- files: 61, delta: 3.086468" "--- files: 61, delta: 3.106478" "--- files: 61, delta: 3.325344" emacs-29, HEAD: "--- files: 61, delta: 5.052421" "--- files: 61, delta: 5.068663" "--- files: 61, delta: 5.110502" FWIW, master "--- files: 61, delta: 5.124109" "--- files: 61, delta: 5.101217" "--- files: 61, delta: 5.13068" ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 5:44 ` Gerd Möllmann @ 2023-10-04 7:38 ` Eli Zaretskii 2023-10-04 7:50 ` Gerd Möllmann 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2023-10-04 7:38 UTC (permalink / raw) To: Gerd Möllmann; +Cc: 65908, ccsmile2008 > Cc: 65908@debbugs.gnu.org > From: Gerd Möllmann <gerd.moellmann@gmail.com> > Date: Wed, 04 Oct 2023 07:44:33 +0200 > > Zhang Haijun <ccsmile2008@outlook.com> writes: > > > 1 emacs -Q > > 2 paste the following code to scratch buffer and execute it for saveral times > > > > (benchmark-progn > > (setq enable-dir-local-variables nil > > enable-local-variables nil) > > > > (let* ((test-dir "~/source/emacs-git/lisp") > > (file-list (directory-files test-dir t > > "\\`[fsw].*[.]el\\'" t)) > > (start-tm (current-time)) > > end-tm buf buf-list) > > > > (dolist (test-file file-list) > > (setq buf (find-file-noselect test-file)) > > (with-current-buffer buf > > (goto-char (point-min)) > > (while (not (eobp)) > > (end-of-defun))) > > (setq buf-list (cons buf buf-list))) > > > > (setq end-tm (current-time)) > > > > (dolist (buf buf-list) > > (kill-buffer buf)) > > > > (let ((delta (time-subtract end-tm start-tm))) > > (message "--- files: %d, delta: %s" > > (length file-list) (float-time delta))))) > > (Your mailer does strange things with whitespace...) > > > Time used in Emacs 29 is 1.6x than in Emacs 27. They are all built with "-O2". > > I also tested on Linux. There is no such big regress. > > Thanks for the report. > > I can reproduce this on macOS 14.0 (OCLP). > > emacs-28, HEAD: > "--- files: 61, delta: 3.086468" > "--- files: 61, delta: 3.106478" > "--- files: 61, delta: 3.325344" > > emacs-29, HEAD: > "--- files: 61, delta: 5.052421" > "--- files: 61, delta: 5.068663" > "--- files: 61, delta: 5.110502" > > FWIW, master > "--- files: 61, delta: 5.124109" > "--- files: 61, delta: 5.101217" > "--- files: 61, delta: 5.13068" A completely expanded Lisp profile, after loading the Lisp files involved in this as *.el, would be appreciated. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 7:38 ` Eli Zaretskii @ 2023-10-04 7:50 ` Gerd Möllmann 2023-10-04 8:29 ` Stefan Kangas 0 siblings, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-04 7:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 65908, ccsmile2008 On 04.10.23 09:38, Eli Zaretskii wrote: >> Cc: 65908@debbugs.gnu.org >> From: Gerd Möllmann <gerd.moellmann@gmail.com> >> Date: Wed, 04 Oct 2023 07:44:33 +0200 >> >> Zhang Haijun <ccsmile2008@outlook.com> writes: >> >>> 1 emacs -Q >>> 2 paste the following code to scratch buffer and execute it for saveral times >>> >>> (benchmark-progn >>> (setq enable-dir-local-variables nil >>> enable-local-variables nil) >>> >>> (let* ((test-dir "~/source/emacs-git/lisp") >>> (file-list (directory-files test-dir t >>> "\\`[fsw].*[.]el\\'" t)) >>> (start-tm (current-time)) >>> end-tm buf buf-list) >>> >>> (dolist (test-file file-list) >>> (setq buf (find-file-noselect test-file)) >>> (with-current-buffer buf >>> (goto-char (point-min)) >>> (while (not (eobp)) >>> (end-of-defun))) >>> (setq buf-list (cons buf buf-list))) >>> >>> (setq end-tm (current-time)) >>> >>> (dolist (buf buf-list) >>> (kill-buffer buf)) >>> >>> (let ((delta (time-subtract end-tm start-tm))) >>> (message "--- files: %d, delta: %s" >>> (length file-list) (float-time delta))))) >> >> (Your mailer does strange things with whitespace...) >> >>> Time used in Emacs 29 is 1.6x than in Emacs 27. They are all built with "-O2". >>> I also tested on Linux. There is no such big regress. >> >> Thanks for the report. >> >> I can reproduce this on macOS 14.0 (OCLP). >> >> emacs-28, HEAD: >> "--- files: 61, delta: 3.086468" >> "--- files: 61, delta: 3.106478" >> "--- files: 61, delta: 3.325344" >> >> emacs-29, HEAD: >> "--- files: 61, delta: 5.052421" >> "--- files: 61, delta: 5.068663" >> "--- files: 61, delta: 5.110502" >> >> FWIW, master >> "--- files: 61, delta: 5.124109" >> "--- files: 61, delta: 5.101217" >> "--- files: 61, delta: 5.13068" > > A completely expanded Lisp profile, after loading the Lisp files > involved in this as *.el, would be appreciated. I'm trying to bisect this, which turns out to be a bit tedious because many commits on emacs-29 don't build. I'll come back when I have something. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 7:50 ` Gerd Möllmann @ 2023-10-04 8:29 ` Stefan Kangas 2023-10-04 8:32 ` Gerd Möllmann 2023-10-04 9:02 ` Gregory Heytings 0 siblings, 2 replies; 45+ messages in thread From: Stefan Kangas @ 2023-10-04 8:29 UTC (permalink / raw) To: Gerd Möllmann, Eli Zaretskii; +Cc: Gregory Heytings, 65908, ccsmile2008 Gerd Möllmann <gerd.moellmann@gmail.com> writes: > I'm trying to bisect this, which turns out to be a bit tedious because > many commits on emacs-29 don't build. I'll come back when I have something. Does the script admin/git-bisect-start help? Gregory will correct me if I'm wrong, but I think it's okay to add any commits that don't build to the list there. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 8:29 ` Stefan Kangas @ 2023-10-04 8:32 ` Gerd Möllmann 2023-10-04 9:02 ` Gregory Heytings 1 sibling, 0 replies; 45+ messages in thread From: Gerd Möllmann @ 2023-10-04 8:32 UTC (permalink / raw) To: Stefan Kangas, Eli Zaretskii; +Cc: Gregory Heytings, 65908, ccsmile2008 On 04.10.23 10:29, Stefan Kangas wrote: > Gerd Möllmann <gerd.moellmann@gmail.com> writes: > >> I'm trying to bisect this, which turns out to be a bit tedious because >> many commits on emacs-29 don't build. I'll come back when I have something. > > Does the script admin/git-bisect-start help? Yes it helps. Gregory set me on the right path already. I had completely forgotten. > > Gregory will correct me if I'm wrong, but I think it's okay to add any > commits that don't build to the list there. If that's okay, I already have one I could add. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 8:29 ` Stefan Kangas 2023-10-04 8:32 ` Gerd Möllmann @ 2023-10-04 9:02 ` Gregory Heytings 2023-10-04 9:12 ` Gerd Möllmann 2023-10-04 9:12 ` Stefan Kangas 1 sibling, 2 replies; 45+ messages in thread From: Gregory Heytings @ 2023-10-04 9:02 UTC (permalink / raw) To: Stefan Kangas; +Cc: Gerd Möllmann, Eli Zaretskii, 65908, ccsmile2008 > > Gregory will correct me if I'm wrong, but I think it's okay to add any > commits that don't build to the list there. > It's okay in principle, but the idea of that script is to include only commits that don't build on GNU/Linux, with GCC, and with the default build options (just "make"). I try to update the list of failing commits monthly. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 9:02 ` Gregory Heytings @ 2023-10-04 9:12 ` Gerd Möllmann 2023-10-04 9:12 ` Stefan Kangas 1 sibling, 0 replies; 45+ messages in thread From: Gerd Möllmann @ 2023-10-04 9:12 UTC (permalink / raw) To: Gregory Heytings, Stefan Kangas; +Cc: Eli Zaretskii, 65908, ccsmile2008 On 04.10.23 11:02, Gregory Heytings wrote: > >> >> Gregory will correct me if I'm wrong, but I think it's okay to add any >> commits that don't build to the list there. >> > > It's okay in principle, but the idea of that script is to include only > commits that don't build on GNU/Linux, with GCC, and with the default > build options (just "make"). I try to update the list of failing > commits monthly. > That's okay, I can roll my own. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 9:02 ` Gregory Heytings 2023-10-04 9:12 ` Gerd Möllmann @ 2023-10-04 9:12 ` Stefan Kangas 2023-10-04 10:55 ` Gerd Möllmann 2023-10-05 8:58 ` Gregory Heytings 1 sibling, 2 replies; 45+ messages in thread From: Stefan Kangas @ 2023-10-04 9:12 UTC (permalink / raw) To: Gregory Heytings; +Cc: Gerd Möllmann, Eli Zaretskii, 65908, ccsmile2008 Gregory Heytings <gregory@heytings.org> writes: >> Gregory will correct me if I'm wrong, but I think it's okay to add any >> commits that don't build to the list there. > > It's okay in principle, but the idea of that script is to include only > commits that don't build on GNU/Linux, with GCC, and with the default > build options (just "make"). Thanks, I now see that explained a bit further down in the file. Perhaps that explanation could be moved to the very top of the file? > I try to update the list of failing commits monthly. Thanks for maintaining that script. We need more people showing that kind of initiative and drive. BTW, if you have any scripts that you use to update the list, it might be useful to add them to emacs.git. Perhaps just as a comment to git-bisect-start, depending on how long it is. That would decrease the bus factor. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 9:12 ` Stefan Kangas @ 2023-10-04 10:55 ` Gerd Möllmann 2023-10-04 12:43 ` Gerd Möllmann 2023-10-05 8:58 ` Gregory Heytings 1 sibling, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-04 10:55 UTC (permalink / raw) To: Stefan Kangas Cc: Gregory Heytings, 65908, Eli Zaretskii, Alan Third, ccsmile2008 Stefan Kangas <stefankangas@gmail.com> writes: >> I try to update the list of failing commits monthly. > > Thanks for maintaining that script. We need more people showing that > kind of initiative and drive. +1 And, three weeks later, the culprit is commit 058c012f73d4abe014ace44b46c23babd48aebbc (HEAD) Author: Alan Third <alan@idiocy.org> Date: Sun Nov 14 15:09:43 2021 +0000 Only set LANG if the ID is valid * src/nsterm.m (ns_init_locale): Check the provided locale identifier is available before trying to use it. But don't ask me how that comes into play here because that function seems to be called from main only. Maybe it's because LANG is now not always set, but used somewhere else? Added Alan Third to the CC. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 10:55 ` Gerd Möllmann @ 2023-10-04 12:43 ` Gerd Möllmann 2023-10-04 21:16 ` Alan Third 0 siblings, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-04 12:43 UTC (permalink / raw) To: Stefan Kangas Cc: ccsmile2008, Gregory Heytings, 65908, Eli Zaretskii, Alan Third Gerd Möllmann <gerd.moellmann@gmail.com> writes: > Stefan Kangas <stefankangas@gmail.com> writes: > >>> I try to update the list of failing commits monthly. >> >> Thanks for maintaining that script. We need more people showing that >> kind of initiative and drive. > > +1 > > And, three weeks later, the culprit is > > commit 058c012f73d4abe014ace44b46c23babd48aebbc (HEAD) > Author: Alan Third <alan@idiocy.org> > Date: Sun Nov 14 15:09:43 2021 +0000 > > Only set LANG if the ID is valid > > * src/nsterm.m (ns_init_locale): Check the provided locale identifier > is available before trying to use it. > > But don't ask me how that comes into play here because that function > seems to be called from main only. Maybe it's because LANG is now not > always set, but used somewhere else? > > Added Alan Third to the CC. As an experiment, I evaluated this in *scratch*: (setenv "LANG" "") (setenv "LC_COLLATE" "C") (setenv "LC_CTYPE" "UTF-8") (setenv "LC_MESSAGES" "C") (setenv "LC_MONETARY" "C") (setenv "LC_NUMERIC" "C") (setenv "LC_TIME" "C") which is the output of 'locale' in a terminal, translated to Elisp. With these settings, the slowdown is gone, without changing the code. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 12:43 ` Gerd Möllmann @ 2023-10-04 21:16 ` Alan Third 2023-10-05 5:41 ` Eli Zaretskii 2023-10-05 5:55 ` Gerd Möllmann 0 siblings, 2 replies; 45+ messages in thread From: Alan Third @ 2023-10-04 21:16 UTC (permalink / raw) To: Gerd Möllmann Cc: Gregory Heytings, 65908, Eli Zaretskii, Stefan Kangas, ccsmile2008 On Wed, Oct 04, 2023 at 02:43:05PM +0200, Gerd Möllmann wrote: > Gerd Möllmann <gerd.moellmann@gmail.com> writes: > > > Stefan Kangas <stefankangas@gmail.com> writes: > > > >>> I try to update the list of failing commits monthly. > >> > >> Thanks for maintaining that script. We need more people showing that > >> kind of initiative and drive. > > > > +1 > > > > And, three weeks later, the culprit is > > > > commit 058c012f73d4abe014ace44b46c23babd48aebbc (HEAD) > > Author: Alan Third <alan@idiocy.org> > > Date: Sun Nov 14 15:09:43 2021 +0000 > > > > Only set LANG if the ID is valid > > > > * src/nsterm.m (ns_init_locale): Check the provided locale identifier > > is available before trying to use it. > > > > But don't ask me how that comes into play here because that function > > seems to be called from main only. Maybe it's because LANG is now not > > always set, but used somewhere else? AFAIK LANG isn't used by Emacs at all. That code is just there to help set up a default environment for running shell commands. > As an experiment, I evaluated this in *scratch*: > > (setenv "LANG" "") > (setenv "LC_COLLATE" "C") > (setenv "LC_CTYPE" "UTF-8") > (setenv "LC_MESSAGES" "C") > (setenv "LC_MONETARY" "C") > (setenv "LC_NUMERIC" "C") > (setenv "LC_TIME" "C") > > which is the output of 'locale' in a terminal, translated to Elisp. > With these settings, the slowdown is gone, without changing the code. So is Emacs run in the terminal with a LANG of something like en_GB.UTF-8 slower too? Because iirc my mac's terminal doesn't default to 'C' and I don't see anything GUI specific in the test code... FWIW I don't see any meaningful difference using different locale settings on my Debian box, which makes me wonder if there is some low-level darwin code that reads the locale from the environment. Any idea if it's loading the files or stepping through the defuns that's slower, or both? Long story short: I have no idea what's going on here. -- Alan Third ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 21:16 ` Alan Third @ 2023-10-05 5:41 ` Eli Zaretskii 2023-10-05 5:55 ` Gerd Möllmann 1 sibling, 0 replies; 45+ messages in thread From: Eli Zaretskii @ 2023-10-05 5:41 UTC (permalink / raw) To: Alan Third; +Cc: gerd.moellmann, gregory, 65908, stefankangas, ccsmile2008 > Date: Wed, 4 Oct 2023 22:16:22 +0100 > From: Alan Third <alan@idiocy.org> > Cc: Stefan Kangas <stefankangas@gmail.com>, > Gregory Heytings <gregory@heytings.org>, 65908@debbugs.gnu.org, > Eli Zaretskii <eliz@gnu.org>, ccsmile2008@outlook.com > > On Wed, Oct 04, 2023 at 02:43:05PM +0200, Gerd Möllmann wrote: > > Gerd Möllmann <gerd.moellmann@gmail.com> writes: > > > > > Stefan Kangas <stefankangas@gmail.com> writes: > > > > > >>> I try to update the list of failing commits monthly. > > >> > > >> Thanks for maintaining that script. We need more people showing that > > >> kind of initiative and drive. > > > > > > +1 > > > > > > And, three weeks later, the culprit is > > > > > > commit 058c012f73d4abe014ace44b46c23babd48aebbc (HEAD) > > > Author: Alan Third <alan@idiocy.org> > > > Date: Sun Nov 14 15:09:43 2021 +0000 > > > > > > Only set LANG if the ID is valid > > > > > > * src/nsterm.m (ns_init_locale): Check the provided locale identifier > > > is available before trying to use it. > > > > > > But don't ask me how that comes into play here because that function > > > seems to be called from main only. Maybe it's because LANG is now not > > > always set, but used somewhere else? > > AFAIK LANG isn't used by Emacs at all. That code is just there to help > set up a default environment for running shell commands. > > > As an experiment, I evaluated this in *scratch*: > > > > (setenv "LANG" "") > > (setenv "LC_COLLATE" "C") > > (setenv "LC_CTYPE" "UTF-8") > > (setenv "LC_MESSAGES" "C") > > (setenv "LC_MONETARY" "C") > > (setenv "LC_NUMERIC" "C") > > (setenv "LC_TIME" "C") > > > > which is the output of 'locale' in a terminal, translated to Elisp. > > With these settings, the slowdown is gone, without changing the code. > > So is Emacs run in the terminal with a LANG of something like > en_GB.UTF-8 slower too? Because iirc my mac's terminal doesn't default > to 'C' and I don't see anything GUI specific in the test code... > > FWIW I don't see any meaningful difference using different locale > settings on my Debian box, which makes me wonder if there is some > low-level darwin code that reads the locale from the environment. Any > idea if it's loading the files or stepping through the defuns that's > slower, or both? > > Long story short: I have no idea what's going on here. Crystal ball says that the UTF-8 locale turns on some expensive processing where it doesn't happen with the C locale. One potential place is case-insensitive comparisons and such likes. Selectively setting only some of the LC_* variables limits the expensive processing only to some operations. In general, Emacs only needs to locale's settings to decide which locale-environment and language-environment to turn on, all the rest we do by ourselves. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 21:16 ` Alan Third 2023-10-05 5:41 ` Eli Zaretskii @ 2023-10-05 5:55 ` Gerd Möllmann 2023-10-05 6:08 ` Eli Zaretskii 1 sibling, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 5:55 UTC (permalink / raw) To: Alan Third Cc: Gregory Heytings, 65908, Eli Zaretskii, Stefan Kangas, ccsmile2008 Alan Third <alan@idiocy.org> writes: >> which is the output of 'locale' in a terminal, translated to Elisp. >> With these settings, the slowdown is gone, without changing the code. > > So is Emacs run in the terminal with a LANG of something like > en_GB.UTF-8 slower too? Because iirc my mac's terminal doesn't default > to 'C' and I don't see anything GUI specific in the test code... > > FWIW I don't see any meaningful difference using different locale > settings on my Debian box, which makes me wonder if there is some > low-level darwin code that reads the locale from the environment. Any > idea if it's loading the files or stepping through the defuns that's > slower, or both? > > Long story short: I have no idea what's going on here. Me neither. I tried to find something definitive about locales+bundles Apple's docs, and on the Internet in general, but failed miserably. What a mess. Anyway, something is odd here, I think. When I start 058c012f73d4abe014ace44b46c23babd48aebbc by double-clicking Emacs.app, then M-x shell, I get $ locale LANG="" LC_COLLATE="C" LC_CTYPE="C" LC_MESSAGES="C" LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL= That can't be right, or is it? The same, one commit before that: $ locale LANG="en_DE.UTF-8" LC_COLLATE="C" LC_CTYPE="C" LC_MESSAGES="C" LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL= At least LANG looks correct to me (I'm using an English UI, in DE.). The LC_* are odd, though. As an aside - vscode sets all of these vars to "en_US.UTF-8" which is looks wrong, and the Zed editor does the same, except for LANG which it set to "". I must admit that I can't come to a conclusion here. Maybe the right thing would be LANG="en_DE.UTF-8" plus setting LC_ALL=$LANG like vscode? ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 5:55 ` Gerd Möllmann @ 2023-10-05 6:08 ` Eli Zaretskii 2023-10-05 8:52 ` Gerd Möllmann 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2023-10-05 6:08 UTC (permalink / raw) To: Gerd Möllmann; +Cc: alan, gregory, 65908, stefankangas, ccsmile2008 > From: Gerd Möllmann <gerd.moellmann@gmail.com> > Cc: Stefan Kangas <stefankangas@gmail.com>, Gregory Heytings > <gregory@heytings.org>, 65908@debbugs.gnu.org, Eli Zaretskii > <eliz@gnu.org>, ccsmile2008@outlook.com > Date: Thu, 05 Oct 2023 07:55:55 +0200 > > When I start 058c012f73d4abe014ace44b46c23babd48aebbc by double-clicking > Emacs.app, then M-x shell, I get > > $ locale > LANG="" > LC_COLLATE="C" > LC_CTYPE="C" > LC_MESSAGES="C" > LC_MONETARY="C" > LC_NUMERIC="C" > LC_TIME="C" > LC_ALL= > > That can't be right, or is it? > > The same, one commit before that: > > $ locale > LANG="en_DE.UTF-8" > LC_COLLATE="C" > LC_CTYPE="C" > LC_MESSAGES="C" > LC_MONETARY="C" > LC_NUMERIC="C" > LC_TIME="C" > LC_ALL= > > At least LANG looks correct to me (I'm using an English UI, in DE.). > The LC_* are odd, though. Emacs forces LC_ALL= and LC_NUMERIC=C, to properly localize the initial error messages and format numbers as in the "C" locale, see 'main' (which also has an NS-specific code). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 6:08 ` Eli Zaretskii @ 2023-10-05 8:52 ` Gerd Möllmann 2023-10-05 9:48 ` Alan Third 0 siblings, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 8:52 UTC (permalink / raw) To: Eli Zaretskii; +Cc: alan, gregory, 65908, stefankangas, ccsmile2008 Eli Zaretskii <eliz@gnu.org> writes: >> From: Gerd Möllmann <gerd.moellmann@gmail.com> >> Cc: Stefan Kangas <stefankangas@gmail.com>, Gregory Heytings >> <gregory@heytings.org>, 65908@debbugs.gnu.org, Eli Zaretskii >> <eliz@gnu.org>, ccsmile2008@outlook.com >> Date: Thu, 05 Oct 2023 07:55:55 +0200 >> >> When I start 058c012f73d4abe014ace44b46c23babd48aebbc by double-clicking >> Emacs.app, then M-x shell, I get >> >> $ locale >> LANG="" >> LC_COLLATE="C" >> LC_CTYPE="C" >> LC_MESSAGES="C" >> LC_MONETARY="C" >> LC_NUMERIC="C" >> LC_TIME="C" >> LC_ALL= >> >> That can't be right, or is it? >> >> The same, one commit before that: >> >> $ locale >> LANG="en_DE.UTF-8" >> LC_COLLATE="C" >> LC_CTYPE="C" >> LC_MESSAGES="C" >> LC_MONETARY="C" >> LC_NUMERIC="C" >> LC_TIME="C" >> LC_ALL= >> >> At least LANG looks correct to me (I'm using an English UI, in DE.). >> The LC_* are odd, though. > > Emacs forces LC_ALL= and LC_NUMERIC=C, to properly localize the > initial error messages and format numbers as in the "C" locale, see > 'main' (which also has an NS-specific code). Thanks for the hint, Eli. I've meanwhile found out something. Not yet sure what to make of this, but anyway: 1. In ns_init_locale, [locale localeIdentifier] returns "en_DE" on my system, which is, I think, a consequence of my system settings, as I mentioned (English UI in Germany). 2. man setlocale(3) says this An argument of "" will determine the name of the new locale taking into account the environment variables LANG and LC_*. So, the setlocale (LC_ALL, "") in main should initialize LC_* according to LANG, if set. (Another question might be if that is what was intended here, when I read the comment above that code, but be that as it may.) And another thing - any setlocale in ns_init_locale is moot because it will be undone in main. 4. When I setenv LANG="en_DE.UTF-8" in ns_init_locale, the setlocale (LC_ALL, "") returns NULL, indicating that LANG is invalid. And, indeed $ locale -a | grep de de_CH de_DE.UTF-8 de_AT.ISO8859-1 de_AT.UTF-8 de_AT.ISO8859-15 de_DE.ISO8859-15 de_CH.UTF-8 de_CH.ISO8859-15 de_DE.ISO8859-1 de_CH.ISO8859-1 de_AT de_DE There is no en_DE... 5. When I don't use localeIndentifier, but "en_US.UTF-8", for instance, the setlocale (LC_ALL, "") in main works like expected, and in a shell buffer: $ ~/emacs/master/src/ > locale LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL= That's all not very nice :-). Conclusion so far, for me, - don't selocale in ns_init_locale, only setenv LANG, or set LC_CTYPE, maybe. - localeIndentifier is wrong for mixed cases like "en_DE". ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 8:52 ` Gerd Möllmann @ 2023-10-05 9:48 ` Alan Third 2023-10-05 11:12 ` Gerd Möllmann 0 siblings, 1 reply; 45+ messages in thread From: Alan Third @ 2023-10-05 9:48 UTC (permalink / raw) To: Gerd Möllmann Cc: Eli Zaretskii, gregory, 65908, stefankangas, ccsmile2008 On Thu, Oct 05, 2023 at 10:52:21AM +0200, Gerd Möllmann wrote: > Conclusion so far, for me, > > - don't selocale in ns_init_locale, only setenv LANG, or set LC_CTYPE, > maybe. setlocale in ns_init_locale is only there to check if the locale is valid, it resets it back to its initial value at the end. > - localeIndentifier is wrong for mixed cases like "en_DE". There was some trouble with warning messages in the terminal when using an invalid locale ID (see bug#51321), but that may only be because Daniel had changed the code to set LC_ALL instead of LANG. I preferred setting LANG anyway because it acts as a fallback, and this is pretty much intended as a fallback, anything else explicitly set will override it. Out of interest, when is it slow? Is it when we have an invalid locale ID? -- Alan Third ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 9:48 ` Alan Third @ 2023-10-05 11:12 ` Gerd Möllmann 2023-10-05 13:18 ` Gerd Möllmann ` (2 more replies) 0 siblings, 3 replies; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 11:12 UTC (permalink / raw) To: Alan Third; +Cc: Eli Zaretskii, gregory, 65908, stefankangas, ccsmile2008 Alan Third <alan@idiocy.org> writes: > On Thu, Oct 05, 2023 at 10:52:21AM +0200, Gerd Möllmann wrote: >> Conclusion so far, for me, >> >> - don't selocale in ns_init_locale, only setenv LANG, or set LC_CTYPE, >> maybe. > > setlocale in ns_init_locale is only there to check if the locale is > valid, it resets it back to its initial value at the end. That's okay. What I meant was setting the old locale at the end. >> - localeIndentifier is wrong for mixed cases like "en_DE". > > There was some trouble with warning messages in the terminal when > using an invalid locale ID (see bug#51321), but that may only be > because Daniel had changed the code to set LC_ALL instead of LANG. Thanks, I'll take a look. > > I preferred setting LANG anyway because it acts as a fallback, and > this is pretty much intended as a fallback, anything else explicitly > set will override it. I think that's TRT, indeed. > > Out of interest, when is it slow? Is it when we have an invalid locale > ID? That's an interesting question--whatever I do on master, it's almost equally slow :-). It would be nice if I could get at least the right character encoding on my system... On the plus side, I at least know now what's happening, although I don't know what to do. BTW, @ccsmile: What are your locale settings? Aprt from that, I'm currently trying to get profiling working on my old Macbook Pro, to compare the profiles of the 2 commits on emacs-29 which show the difference. That could maybe answer your question. Buhut... I can't currently get Instruments to work, which might be related to the fact that I've updated my unsupported by Apple Macbook to Sonoma with OCLP. Buhut -- maybe the new thunderbolt/magsafe cable for my display arrives soon, so that I can use my Mac mini again. A lot of construction sites ahead :-). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 11:12 ` Gerd Möllmann @ 2023-10-05 13:18 ` Gerd Möllmann 2023-10-05 16:11 ` Eli Zaretskii 2023-10-05 13:51 ` Alan Third 2023-10-05 13:56 ` Gerd Möllmann 2 siblings, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 13:18 UTC (permalink / raw) To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas [-- Attachment #1: Type: text/plain, Size: 686 bytes --] Gerd Möllmann <gerd.moellmann@gmail.com> writes: > It would be nice if I could get at least the right character encoding on > my system... On the plus side, I at least know now what's happening, > although I don't know what to do. I'd like to propose the attached patch for problem of invalid LANG setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid, or something valid can't be deduced from the locale. I find this acceptable even in my setting ("en_DE") because even Apple's Terminal doesn't get this right. A closer looks at what is set in the locale in Terminal shows that, for instance, date format and thousands separator are en_US anyway. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: ns_init_locale --] [-- Type: text/x-patch, Size: 2370 bytes --] From 93457632cd5f17de01ec291d888d2d2fb0acffdf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd@gnu.org> Date: Thu, 5 Oct 2023 15:12:40 +0200 Subject: [PATCH] Handle LANG on macOS differntly (bug#bug#65908) * src/nsterm.m (ns_init_locale): If LANG is set, try to use that, otherwise try to deduce what LANG should be. Check is the result is valid, and use LANG="en_US.UTF-8" if not. --- src/nsterm.m | 32 ++++++++++++++------------------ 1 file changed, 14 insertions(+), 18 deletions(-) diff --git a/src/nsterm.m b/src/nsterm.m index 4e0dfa58c63..09cb7236b6e 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -554,29 +554,25 @@ - (unsigned long)unsignedLong /* macOS doesn't set any environment variables for the locale when run from the GUI. Get the locale from the OS and set LANG. */ { - NSLocale *locale = [NSLocale currentLocale]; - NSTRACE ("ns_init_locale"); - /* If we were run from a terminal then assume an unset LANG variable - is intentional and don't try to "fix" it. */ - if (!isatty (STDIN_FILENO)) + const char *lang = getenv ("LANG"); + if (lang == NULL) { - char *oldLocale = setlocale (LC_ALL, NULL); - /* It seems macOS should probably use UTF-8 everywhere. - 'localeIdentifier' does not specify the encoding, and I can't - find any way to get the OS to tell us which encoding to use, - so hard-code '.UTF-8'. */ - NSString *localeID = [NSString stringWithFormat:@"%@.UTF-8", - [locale localeIdentifier]]; + const NSLocale *locale = [NSLocale currentLocale]; + const NSString *localeID = [NSString stringWithFormat:@"%@.UTF-8", + [locale localeIdentifier]]; + lang = [localeID UTF8String]; + } - /* Check the locale ID is valid and if so set LANG, but not if - it is already set. */ - if (setlocale (LC_ALL, [localeID UTF8String])) - setenv("LANG", [localeID UTF8String], 0); + /* Check if LANG can be used for initializing the locale. If not, + use a default setting. Note that Emacs' main will undo the + setlocale below, initializing the locale from the + environment. */ + if (setlocale (LC_ALL, lang) == NULL) + lang = "en_US.UTF-8"; - setlocale (LC_ALL, oldLocale); - } + setenv ("LANG", lang, 1); } -- 2.39.3 (Apple Git-145) ^ permalink raw reply related [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 13:18 ` Gerd Möllmann @ 2023-10-05 16:11 ` Eli Zaretskii 2023-10-05 16:33 ` Alan Third 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2023-10-05 16:11 UTC (permalink / raw) To: Gerd Möllmann; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas > From: Gerd Möllmann <gerd.moellmann@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com > Date: Thu, 05 Oct 2023 15:18:42 +0200 > > I'd like to propose the attached patch for problem of invalid LANG > setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid, > or something valid can't be deduced from the locale. Why is it reasonable to force the UTF-8 codeset as the fallback? What about having a variable exposed to Lisp that allows the users to control the fallback value of LANG? ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 16:11 ` Eli Zaretskii @ 2023-10-05 16:33 ` Alan Third 2023-10-05 16:38 ` Gerd Möllmann 2023-10-05 17:02 ` Eli Zaretskii 0 siblings, 2 replies; 45+ messages in thread From: Alan Third @ 2023-10-05 16:33 UTC (permalink / raw) To: Eli Zaretskii Cc: Gerd Möllmann, gregory, 65908, stefankangas, ccsmile2008 On Thu, Oct 05, 2023 at 07:11:01PM +0300, Eli Zaretskii wrote: > > From: Gerd Möllmann <gerd.moellmann@gmail.com> > > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, > > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com > > Date: Thu, 05 Oct 2023 15:18:42 +0200 > > > > I'd like to propose the attached patch for problem of invalid LANG > > setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid, > > or something valid can't be deduced from the locale. > > Why is it reasonable to force the UTF-8 codeset as the fallback? Both the macOS terminals I have access to use UTF-8 as their default, and I'm not sure if they even let you change it. Therefore it seemed reasonable to me that the default for Emacs should also be UTF-8. > What about having a variable exposed to Lisp that allows the users to > control the fallback value of LANG? Is this not too early in startup for that? If not then couldn't the user just use setenv and avoid this whole thing? -- Alan Third ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 16:33 ` Alan Third @ 2023-10-05 16:38 ` Gerd Möllmann 2023-10-05 17:02 ` Eli Zaretskii 1 sibling, 0 replies; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 16:38 UTC (permalink / raw) To: Alan Third; +Cc: Eli Zaretskii, 65908, stefankangas, gregory, ccsmile2008 Alan Third <alan@idiocy.org> writes: > On Thu, Oct 05, 2023 at 07:11:01PM +0300, Eli Zaretskii wrote: >> > From: Gerd Möllmann <gerd.moellmann@gmail.com> >> > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, >> > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com >> > Date: Thu, 05 Oct 2023 15:18:42 +0200 >> > >> > I'd like to propose the attached patch for problem of invalid LANG >> > setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid, >> > or something valid can't be deduced from the locale. >> >> Why is it reasonable to force the UTF-8 codeset as the fallback? > > Both the macOS terminals I have access to use UTF-8 as their default, > and I'm not sure if they even let you change it. Therefore it seemed > reasonable to me that the default for Emacs should also be UTF-8. Agree. >> What about having a variable exposed to Lisp that allows the users to >> control the fallback value of LANG? > > Is this not too early in startup for that? If not then couldn't the > user just use setenv and avoid this whole thing? I wonder that, too. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 16:33 ` Alan Third 2023-10-05 16:38 ` Gerd Möllmann @ 2023-10-05 17:02 ` Eli Zaretskii 2023-10-05 17:15 ` Alan Third 1 sibling, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2023-10-05 17:02 UTC (permalink / raw) To: Alan Third; +Cc: gerd.moellmann, gregory, 65908, stefankangas, ccsmile2008 > Date: Thu, 5 Oct 2023 17:33:56 +0100 > From: Alan Third <alan@idiocy.org> > Cc: Gerd Möllmann <gerd.moellmann@gmail.com>, > ccsmile2008@outlook.com, 65908@debbugs.gnu.org, > gregory@heytings.org, stefankangas@gmail.com > > On Thu, Oct 05, 2023 at 07:11:01PM +0300, Eli Zaretskii wrote: > > > From: Gerd Möllmann <gerd.moellmann@gmail.com> > > > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, > > > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com > > > Date: Thu, 05 Oct 2023 15:18:42 +0200 > > > > > > I'd like to propose the attached patch for problem of invalid LANG > > > setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid, > > > or something valid can't be deduced from the locale. > > > > Why is it reasonable to force the UTF-8 codeset as the fallback? > > Both the macOS terminals I have access to use UTF-8 as their default, > and I'm not sure if they even let you change it. Therefore it seemed > reasonable to me that the default for Emacs should also be UTF-8. Are you saying that macOS doesn't support non-UTF-8 encodings? > > What about having a variable exposed to Lisp that allows the users to > > control the fallback value of LANG? > > Is this not too early in startup for that? If not then couldn't the > user just use setenv and avoid this whole thing? Maybe that's fine, I just asked a question. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 17:02 ` Eli Zaretskii @ 2023-10-05 17:15 ` Alan Third 0 siblings, 0 replies; 45+ messages in thread From: Alan Third @ 2023-10-05 17:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: gerd.moellmann, gregory, 65908, stefankangas, ccsmile2008 On Thu, Oct 05, 2023 at 08:02:41PM +0300, Eli Zaretskii wrote: > > Date: Thu, 5 Oct 2023 17:33:56 +0100 > > From: Alan Third <alan@idiocy.org> > > Cc: Gerd Möllmann <gerd.moellmann@gmail.com>, > > ccsmile2008@outlook.com, 65908@debbugs.gnu.org, > > gregory@heytings.org, stefankangas@gmail.com > > > > On Thu, Oct 05, 2023 at 07:11:01PM +0300, Eli Zaretskii wrote: > > > > From: Gerd Möllmann <gerd.moellmann@gmail.com> > > > > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, > > > > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com > > > > Date: Thu, 05 Oct 2023 15:18:42 +0200 > > > > > > > > I'd like to propose the attached patch for problem of invalid LANG > > > > setting. This simply falls back to "en_US.UTF-8" if LANG isn't valid, > > > > or something valid can't be deduced from the locale. > > > > > > Why is it reasonable to force the UTF-8 codeset as the fallback? > > > > Both the macOS terminals I have access to use UTF-8 as their default, > > and I'm not sure if they even let you change it. Therefore it seemed > > reasonable to me that the default for Emacs should also be UTF-8. > > Are you saying that macOS doesn't support non-UTF-8 encodings? No, because of the slightly unusual way macOS works, where any graphical application doesn't inherit much of an environment the terminals have to set it up. I was just copying what the terminals do by default. When I say I don't know if they let you change it, I mean in their settings. You can change it in the shell and the locale command here shows, for example: # locale -a | grep en_GB en_GB.ISO8859-1 en_GB.UTF-8 en_GB.US-ASCII en_GB en_GB.ISO8859-15 So we could skip the UTF-8 part if it's the wrong thing to do, but since everything else in macOS is unicode aware, I suspect we should keep it. -- Alan Third ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 11:12 ` Gerd Möllmann 2023-10-05 13:18 ` Gerd Möllmann @ 2023-10-05 13:51 ` Alan Third 2023-10-05 14:01 ` Gerd Möllmann 2023-10-05 14:09 ` Gerd Möllmann 2023-10-05 13:56 ` Gerd Möllmann 2 siblings, 2 replies; 45+ messages in thread From: Alan Third @ 2023-10-05 13:51 UTC (permalink / raw) To: Gerd Möllmann Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas On Thu, Oct 05, 2023 at 01:12:10PM +0200, Gerd Möllmann wrote: > Alan Third <alan@idiocy.org> writes: > > > On Thu, Oct 05, 2023 at 10:52:21AM +0200, Gerd Möllmann wrote: > >> Conclusion so far, for me, > >> > >> - don't selocale in ns_init_locale, only setenv LANG, or set LC_CTYPE, > >> maybe. > > > > setlocale in ns_init_locale is only there to check if the locale is > > valid, it resets it back to its initial value at the end. > > That's okay. What I meant was setting the old locale at the end. I've managed to reproduce this, and the time difference on my machine is ridiculous. From 4 seconds without the setlocale calls to 24 seconds with. And that's with a legitimate, installed, locale ID in both cases. I wonder if this is why some people report Emacs 29 on macOS to be noticeably slower. They, of course, blame the graphics changes, but with that sort of variation in time... > > Out of interest, when is it slow? Is it when we have an invalid locale > > ID? > > That's an interesting question--whatever I do on master, it's almost > equally slow :-). > > It would be nice if I could get at least the right character encoding on > my system... On the plus side, I at least know now what's happening, > although I don't know what to do. Indeed. I'm tempted to say we should revert the change since I now suspect I misunderstood how setlocale works when I wrote this and I'm not sure it's actually improving anything. OTOH, it would be good if we could get this to actually work and generate correct locale ID's for the system... But then, I don't know what *is* a correct locale ID for a system like yours... > Aprt from that, I'm currently trying to get profiling working on my old > Macbook Pro, to compare the profiles of the 2 commits on emacs-29 which > show the difference. That could maybe answer your question. > > Buhut... I can't currently get Instruments to work, which might be > related to the fact that I've updated my unsupported by Apple Macbook to > Sonoma with OCLP. Buhut -- maybe the new thunderbolt/magsafe cable for > my display arrives soon, so that I can use my Mac mini again. A lot of > construction sites ahead :-). I couldn't even get the old commit to build, I had to use the current master and just revert to see the difference. So best of luck! :) -- Alan Third ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 13:51 ` Alan Third @ 2023-10-05 14:01 ` Gerd Möllmann 2023-10-05 14:09 ` Gerd Möllmann 1 sibling, 0 replies; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 14:01 UTC (permalink / raw) To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas Alan Third <alan@idiocy.org> writes: >> That's okay. What I meant was setting the old locale at the end. > > I've managed to reproduce this, and the time difference on my machine > is ridiculous. From 4 seconds without the setlocale calls to 24 > seconds with. > Holy cow! You mean you removed the setlocale at the end, or what did you do? > And that's with a legitimate, installed, locale ID in both cases. > > I wonder if this is why some people report Emacs 29 on macOS to be > noticeably slower. They, of course, blame the graphics changes, but > with that sort of variation in time... > >> > Out of interest, when is it slow? Is it when we have an invalid locale >> > ID? >> >> That's an interesting question--whatever I do on master, it's almost >> equally slow :-). >> >> It would be nice if I could get at least the right character encoding on >> my system... On the plus side, I at least know now what's happening, >> although I don't know what to do. > > Indeed. I'm tempted to say we should revert the change since I now > suspect I misunderstood how setlocale works when I wrote this and I'm > not sure it's actually improving anything. > > OTOH, it would be good if we could get this to actually work and > generate correct locale ID's for the system... But then, I don't know > what *is* a correct locale ID for a system like yours... Yeah :-(. AS I wrote in a different mail, even Terminal doesn't do it "right". And I can't even find anywhere what would be Apple's preferred way of doing this. >> Aprt from that, I'm currently trying to get profiling working on my old >> Macbook Pro, to compare the profiles of the 2 commits on emacs-29 which >> show the difference. That could maybe answer your question. >> >> Buhut... I can't currently get Instruments to work, which might be >> related to the fact that I've updated my unsupported by Apple Macbook to >> Sonoma with OCLP. Buhut -- maybe the new thunderbolt/magsafe cable for >> my display arrives soon, so that I can use my Mac mini again. A lot of >> construction sites ahead :-). > > I couldn't even get the old commit to build, I had to use the current > master and just revert to see the difference. So best of luck! :) Thanks :-). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 13:51 ` Alan Third 2023-10-05 14:01 ` Gerd Möllmann @ 2023-10-05 14:09 ` Gerd Möllmann 2023-10-05 14:58 ` Alan Third 1 sibling, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 14:09 UTC (permalink / raw) To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas Alan Third <alan@idiocy.org> writes: > Indeed. I'm tempted to say we should revert the change since I now > suspect I misunderstood how setlocale works when I wrote this and I'm > not sure it's actually improving anything. I hadn't checked this before, but with the patch I sent, the slowness is indeed gone. What a bloody mess, this stuff :-). ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 14:09 ` Gerd Möllmann @ 2023-10-05 14:58 ` Alan Third 2023-10-05 15:11 ` Gerd Möllmann 0 siblings, 1 reply; 45+ messages in thread From: Alan Third @ 2023-10-05 14:58 UTC (permalink / raw) To: Gerd Möllmann Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas On Thu, Oct 05, 2023 at 04:09:36PM +0200, Gerd Möllmann wrote: > Alan Third <alan@idiocy.org> writes: > > > Indeed. I'm tempted to say we should revert the change since I now > > suspect I misunderstood how setlocale works when I wrote this and I'm > > not sure it's actually improving anything. > > I hadn't checked this before, but with the patch I sent, the slowness is > indeed gone. What a bloody mess, this stuff :-). Yeah. To answer your question in the other email, I saw the improvement only by removing the setlocale in the "if" statement. Your code has something similar, but it shows the speed improvement anyway, so I'm not sure what's happening differently. I've gone over the NSLocale documentation and it appears it explicitly supports locales like en_DE, but the "UNIX" side of macOS doesn't. I suppose it should be possible to generate your own en_DE locale, but that's a bit much, really. I also prodded at the fallback "system" locale, but it doesn't even provide a locale ID, so it's useless. There's a couple of typos in your commit message. Handle LANG on macOS differntly (bug#bug#65908) ^e ^ -- Alan Third ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 14:58 ` Alan Third @ 2023-10-05 15:11 ` Gerd Möllmann 2023-10-05 16:29 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 15:11 UTC (permalink / raw) To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas Alan Third <alan@idiocy.org> writes: > On Thu, Oct 05, 2023 at 04:09:36PM +0200, Gerd Möllmann wrote: >> Alan Third <alan@idiocy.org> writes: >> >> > Indeed. I'm tempted to say we should revert the change since I now >> > suspect I misunderstood how setlocale works when I wrote this and I'm >> > not sure it's actually improving anything. >> >> I hadn't checked this before, but with the patch I sent, the slowness is >> indeed gone. What a bloody mess, this stuff :-). > > Yeah. > > To answer your question in the other email, I saw the improvement only > by removing the setlocale in the "if" statement. Your code has > something similar, but it shows the speed improvement anyway, so I'm > not sure what's happening differently. I'm actually no longer sure I want to know :-). > I've gone over the NSLocale documentation and it appears it explicitly > supports locales like en_DE, but the "UNIX" side of macOS doesn't. I > suppose it should be possible to generate your own en_DE locale, but > that's a bit much, really. Agree. If someone wants to do this for some reason, more power to them. They could then set LANG to it. I won't do it for my case because I don't have TUI appls that require it, AFAIK. > I also prodded at the fallback "system" locale, but it doesn't even > provide a locale ID, so it's useless. > > > There's a couple of typos in your commit message. > > Handle LANG on macOS differntly (bug#bug#65908) > ^e ^ Oops, thanks for spotting this. Remains the question if that should go into emacs-29? I'm for not rocking the boat too much. Although... ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 15:11 ` Gerd Möllmann @ 2023-10-05 16:29 ` Eli Zaretskii 2023-10-05 16:39 ` Gerd Möllmann 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2023-10-05 16:29 UTC (permalink / raw) To: Gerd Möllmann; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas > From: Gerd Möllmann <gerd.moellmann@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com > Date: Thu, 05 Oct 2023 17:11:09 +0200 > > Remains the question if that should go into emacs-29? I'm for not > rocking the boat too much. Although... Let's see the final patch, and decide then. Thanks. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 16:29 ` Eli Zaretskii @ 2023-10-05 16:39 ` Gerd Möllmann 2023-10-05 17:06 ` Eli Zaretskii 0 siblings, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 16:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas [-- Attachment #1: Type: text/plain, Size: 502 bytes --] Eli Zaretskii <eliz@gnu.org> writes: >> From: Gerd Möllmann <gerd.moellmann@gmail.com> >> Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, >> 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com >> Date: Thu, 05 Oct 2023 17:11:09 +0200 >> >> Remains the question if that should go into emacs-29? I'm for not >> rocking the boat too much. Although... > > Let's see the final patch, and decide then. Please find attached. Not much gas changed, though. [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: LANG patch --] [-- Type: text/x-patch, Size: 2621 bytes --] From f1ba5bbbd9526197052949525d2ac680337b6d6b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd@gnu.org> Date: Thu, 5 Oct 2023 17:29:17 +0200 Subject: [PATCH] Handle LANG on macOS differently (bug#65908) * src/nsterm.m (ns_init_locale): If LANG is set, try to use that, otherwise try to deduce what LANG should be. Check is the result is valid, and use LANG="en_US.UTF-8" if not. --- src/nsterm.m | 39 +++++++++++++++++++++------------------ 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/src/nsterm.m b/src/nsterm.m index 4e0dfa58c63..56865987b93 100644 --- a/src/nsterm.m +++ b/src/nsterm.m @@ -554,29 +554,32 @@ - (unsigned long)unsignedLong /* macOS doesn't set any environment variables for the locale when run from the GUI. Get the locale from the OS and set LANG. */ { - NSLocale *locale = [NSLocale currentLocale]; - NSTRACE ("ns_init_locale"); - /* If we were run from a terminal then assume an unset LANG variable - is intentional and don't try to "fix" it. */ - if (!isatty (STDIN_FILENO)) + /* Either use LANG, if set, or try to construct LANG from + NSLocale. */ + const char *lang = getenv ("LANG"); + if (lang == NULL) { - char *oldLocale = setlocale (LC_ALL, NULL); - /* It seems macOS should probably use UTF-8 everywhere. - 'localeIdentifier' does not specify the encoding, and I can't - find any way to get the OS to tell us which encoding to use, - so hard-code '.UTF-8'. */ - NSString *localeID = [NSString stringWithFormat:@"%@.UTF-8", - [locale localeIdentifier]]; - - /* Check the locale ID is valid and if so set LANG, but not if - it is already set. */ - if (setlocale (LC_ALL, [localeID UTF8String])) - setenv("LANG", [localeID UTF8String], 0); + const NSLocale *locale = [NSLocale currentLocale]; + const NSString *localeID = [NSString stringWithFormat:@"%@.UTF-8", + [locale localeIdentifier]]; + lang = [localeID UTF8String]; + } - setlocale (LC_ALL, oldLocale); + /* Check if LANG can be used for initializing the locale. If not, + use a default setting. Note that Emacs' main will undo the + setlocale below, initializing the locale from the + environment. */ + if (setlocale (LC_ALL, lang) == NULL) + { + const char *const default_lang = "en_US.UTF-8"; + fprintf (stderr, "LANG=%s cannot be used, using %s instead.\n", + lang, default_lang); + lang = default_lang; } + + setenv ("LANG", lang, 1); } -- 2.39.3 (Apple Git-145) ^ permalink raw reply related [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 16:39 ` Gerd Möllmann @ 2023-10-05 17:06 ` Eli Zaretskii 2023-10-05 18:08 ` Stefan Kangas 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2023-10-05 17:06 UTC (permalink / raw) To: stefankangas, Gerd Möllmann; +Cc: alan, 65908, gregory, ccsmile2008 > From: Gerd Möllmann <gerd.moellmann@gmail.com> > Cc: alan@idiocy.org, gregory@heytings.org, 65908@debbugs.gnu.org, > stefankangas@gmail.com, ccsmile2008@outlook.com > Date: Thu, 05 Oct 2023 18:39:56 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> From: Gerd Möllmann <gerd.moellmann@gmail.com> > >> Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, > >> 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com > >> Date: Thu, 05 Oct 2023 17:11:09 +0200 > >> > >> Remains the question if that should go into emacs-29? I'm for not > >> rocking the boat too much. Although... > > > > Let's see the final patch, and decide then. > > Please find attached. Not much gas changed, though. If you-two consider this safe for Emacs 29.2, I don't mind. Stefan? ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 17:06 ` Eli Zaretskii @ 2023-10-05 18:08 ` Stefan Kangas 0 siblings, 0 replies; 45+ messages in thread From: Stefan Kangas @ 2023-10-05 18:08 UTC (permalink / raw) To: Eli Zaretskii, Gerd Möllmann; +Cc: alan, 65908, gregory, ccsmile2008 Eli Zaretskii <eliz@gnu.org> writes: > If you-two consider this safe for Emacs 29.2, I don't mind. > > Stefan? No objections here, thanks. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 11:12 ` Gerd Möllmann 2023-10-05 13:18 ` Gerd Möllmann 2023-10-05 13:51 ` Alan Third @ 2023-10-05 13:56 ` Gerd Möllmann 2023-10-05 16:19 ` Eli Zaretskii 2 siblings, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 13:56 UTC (permalink / raw) To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas [-- Attachment #1: Type: text/plain, Size: 476 bytes --] Gerd Möllmann <gerd.moellmann@gmail.com> writes: > Aprt from that, I'm currently trying to get profiling working on my old > Macbook Pro, to compare the profiles of the 2 commits on emacs-29 which > show the difference. That could maybe answer your question. To the question of profiling. I've now used the built-in profiler on the two commits, but I must say that I don't see where the difference comes from. These are debug builds, 5 runs of the benchmark. [-- Attachment #2: slow case --] [-- Type: text/plain, Size: 18160 bytes --] 6446 92% - command-execute 6446 92% - call-interactively 6287 90% - funcall-interactively 6268 89% - eval-print-last-sexp 6268 89% - eval-last-sexp 6268 89% - elisp--eval-last-sexp 6264 89% - eval 6264 89% - progn 6264 89% - let 6257 89% - progn 6257 89% - let* 6247 89% - let 6247 89% - while 6247 89% - let 3680 52% - save-current-buffer 3678 52% - while 3662 52% - end-of-defun 2494 35% - beginning-of-defun-raw 2392 34% - syntax-ppss 1 0% #<compiled 0x8a30a7d371919be> 1107 15% - #<compiled 0x1f5ce039ca16> 1084 15% forward-sexp 7 0% #<compiled -0x1367a2fd14e17470> 1 0% not 2553 36% - setq 2553 36% - find-file-noselect 1962 28% - find-file-noselect-1 1583 22% - after-find-file 1493 21% - run-hooks 1493 21% - vc-refresh-state 650 9% - vc-backend 650 9% - vc-registered 648 9% - mapc 648 9% - #<compiled 0x97a1a3d44aacb78> 648 9% - vc-call-backend 648 9% - apply 340 4% - vc-git-registered 157 2% - cd 151 2% - locate-file 150 2% - locate-file-internal 150 2% #<compiled -0x52006ec4d330c6b> 6 0% cd-absolute 77 1% file-relative-name 59 0% - vc-git--out-ok 59 0% - apply 59 0% - vc-git--call 59 0% - apply 59 0% - process-file 59 0% - apply 1 0% call-process 28 0% - vc-git-root 28 0% - vc-find-root 28 0% - locate-dominating-file 1 0% abbreviate-file-name 19 0% - if 19 0% - progn 16 0% - load 10 0% - require 3 0% - byte-code 2 0% require 1 0% - byte-code 1 0% require 2 0% - vc-git-registered 1 0% - vc-git-root 1 0% - vc-find-root 1 0% - locate-dominating-file 1 0% abbreviate-file-name 1 0% - vc-git--out-ok 1 0% - apply 1 0% - vc-git--call 1 0% - apply 1 0% - process-file 1 0% apply 252 3% - vc-rcs-registered 252 3% - vc-default-registered 252 3% - vc-check-master-templates 252 3% - mapcar 252 3% #<compiled -0x14b119dcda574f9a> 24 0% - vc-bzr-registered 24 0% - if 24 0% - vc-find-root 24 0% - locate-dominating-file 2 0% abbreviate-file-name 17 0% - vc-svn-registered 17 0% - let 17 0% - if 17 0% - vc-find-root 17 0% - locate-dominating-file 6 0% abbreviate-file-name 6 0% - vc-cvs-registered 6 0% if 3 0% - vc-src-registered 3 0% - vc-default-registered 3 0% - vc-check-master-templates 3 0% - mapcar 3 0% #<compiled 0x9df477c7900869f> 3 0% - vc-mtn-registered 3 0% - if 3 0% - vc-find-root 3 0% - locate-dominating-file 1 0% abbreviate-file-name 2 0% - vc-sccs-registered 2 0% - vc-default-registered 2 0% - vc-check-master-templates 2 0% - mapcar 2 0% #<compiled -0x162bb36be296685a> 1 0% - vc-hg-registered 1 0% - if 1 0% - vc-find-root 1 0% locate-dominating-file 1 0% vc-file-getprop 556 7% - vc-mode-line 358 5% - vc-call-backend 358 5% - apply 358 5% - vc-git-mode-line-string 264 3% - vc-working-revision 264 3% - vc-call-backend 264 3% - apply 264 3% - vc-git-working-revision 264 3% - vc-git--rev-parse 264 3% - vc-git--out-ok 264 3% - apply 264 3% - vc-git--call 264 3% - apply 264 3% - process-file 264 3% apply 94 1% - vc-git--symbolic-ref 93 1% - vc-git--run-command-string 93 1% - apply 93 1% - vc-git--out-ok 93 1% - apply 93 1% - vc-git--call 93 1% - apply 93 1% - process-file 93 1% apply 286 4% - vc-call-backend 286 4% - apply 286 4% - vc-git-find-file-hook 286 4% - vc-state 286 4% - vc-state-refresh 286 4% - vc-call-backend 286 4% - apply 286 4% - vc-git-state 286 4% - apply 286 4% - vc-git--run-command-string 167 2% file-relative-name 118 1% - apply 118 1% - vc-git--out-ok 118 1% - apply 116 1% - vc-git--call 116 1% - apply 112 1% - process-file 112 1% apply 1 0% generate-new-buffer 1 0% vc-file-clearprops 62 0% - normal-mode 60 0% - set-auto-mode 60 0% - set-auto-mode--apply-alist 27 0% - set-auto-mode-0 27 0% - emacs-lisp-mode 24 0% - run-mode-hooks 16 0% - hack-local-variables 12 0% - hack-local-variables-prop-line 11 0% - set-auto-mode-1 11 0% - inhibit-local-variables-p 1 0% file-name-sans-versions 2 0% - hack-local-variables--find-variables 1 0% - #<compiled -0x1c1d2016f82fdd9b> 1 0% kill-buffer 8 0% - run-hooks 7 0% - global-font-lock-mode-enable-in-buffers 6 0% - turn-on-font-lock-if-desired 6 0% - turn-on-font-lock 6 0% - font-lock-mode 6 0% - font-lock-default-function 6 0% - font-lock-mode-internal 5 0% - font-lock-turn-on-thing-lock 3 0% - jit-lock-register 3 0% - jit-lock-mode 1 0% jit-lock-refontify 1 0% remove-hook 1 0% - font-lock-set-defaults 1 0% - font-lock-add-keywords 1 0% font-lock-remove-keywords 1 0% - global-eldoc-mode-enable-in-buffers 1 0% - turn-on-eldoc-mode 1 0% - eldoc-mode 1 0% run-hooks 2 0% - lisp-data-mode 2 0% - prog-mode 1 0% - kill-all-local-variables 1 0% global-eldoc-mode-cmhh 8 0% assoc-default 2 0% - font-lock-mode 2 0% - font-lock-default-function 2 0% - font-lock-mode-internal 2 0% - font-lock-turn-on-thing-lock 1 0% - jit-lock-register 1 0% - jit-lock-mode 1 0% jit-lock-refontify 67 0% - file-truename 57 0% - file-truename 50 0% - file-truename 35 0% - file-truename 20 0% - file-truename 10 0% file-truename 11 0% - insert-file-contents 11 0% - set-auto-coding 11 0% - find-auto-coding 10 0% auto-coding-alist-lookup 5 0% abbreviate-file-name 286 4% - find-buffer-visiting 23 0% - file-truename 18 0% - file-truename 11 0% - file-truename 10 0% - file-truename 7 0% - file-truename 2 0% file-truename 3 0% abbreviate-file-name 254 3% abbreviate-file-name 28 0% - file-truename 15 0% - file-truename 12 0% - file-truename 7 0% - file-truename 5 0% - file-truename 3 0% file-truename 4 0% - create-file-buffer 4 0% - apply 4 0% - uniquify--create-file-buffer-advice 3 0% - uniquify-rationalize-file-buffer-names 1 0% - uniquify-rationalize 1 0% uniquify-rationalize-a-list 7 0% - message 7 0% - float-time 3 0% - time-since 3 0% - byte-code 1 0% require 1 0% - elisp--preceding-sexp 1 0% forward-sexp 7 0% - previous-line 7 0% - line-move 4 0% line-move-visual 7 0% - execute-extended-command 7 0% - command-execute 7 0% - call-interactively 7 0% - funcall-interactively 7 0% profiler-report 4 0% - next-line 4 0% - line-move 2 0% line-move-visual 1 0% - default-line-height 1 0% default-font-height 1 0% - move-end-of-line 1 0% - line-move 1 0% line-move-1 159 2% - byte-code 159 2% - read-extended-command 159 2% - completing-read 159 2% - completing-read-default 36 0% - read-from-minibuffer 15 0% - command-execute 15 0% - call-interactively 15 0% - funcall-interactively 15 0% - minibuffer-complete 15 0% - completion-in-region 15 0% - completion--in-region 15 0% - #<compiled -0x1b9ffa9feb95062> 15 0% - apply 15 0% - #<compiled 0xdedd3f31b64fd0> 15 0% - completion--in-region-1 15 0% - completion--do-completion 7 0% - completion-try-completion 7 0% - completion--nth-completion 7 0% - completion--some 7 0% - #<compiled 0x1b6e37e38eac17b5> 7 0% - completion-basic-try-completion 7 0% - try-completion 7 0% - #<compiled 0x523b6c540a44927> 7 0% complete-with-action 7 0% - minibuffer-completion-help 4 0% - temp-buffer-window-show 4 0% - display-buffer 4 0% - display-buffer-at-bottom 3 0% - window--display-buffer 2 0% fit-window-to-buffer 1 0% - #<compiled -0x189b606b4eedbb15> 1 0% - display-completion-list 1 0% - run-hooks 1 0% - completion-setup-function 1 0% substitute-command-keys 1 0% - walk-window-tree 1 0% - walk-window-tree-1 1 0% - #<compiled -0xc246f5dbd4eb22b> 1 0% window-in-direction 3 0% - completion-all-completions 3 0% - completion--nth-completion 3 0% - completion--some 3 0% - #<compiled 0xaf1c20e12870063> 3 0% - completion-basic-all-completions 3 0% - completion-pcm--all-completions 3 0% - all-completions 3 0% - #<compiled 0x523b6c540a44927> 3 0% complete-with-action 1 0% - minibuffer-hide-completions 1 0% - bury-buffer 1 0% - window--delete 1 0% delete-window 522 7% + ... 12 0% + timer-event-handler 5 0% + redisplay_internal (C function) [-- Attachment #3: fast case --] [-- Type: text/plain, Size: 16803 bytes --] 6199 91% - command-execute 6199 91% - call-interactively 6066 89% - funcall-interactively 6040 88% - eval-print-last-sexp 6040 88% - eval-last-sexp 6040 88% - elisp--eval-last-sexp 6034 88% - eval 6034 88% - progn 6034 88% - let 6028 88% - progn 6028 88% - let* 6016 88% - let 6016 88% - while 6016 88% - let 3547 52% - save-current-buffer 3546 52% - while 3539 52% - end-of-defun 2440 35% - beginning-of-defun-raw 2334 34% - syntax-ppss 1 0% #<compiled 0x8a3336d7832903e> 1033 15% - #<compiled 0x1f5ce1910a16> 1009 14% forward-sexp 5 0% #<compiled -0x1367a2fddcb57470> 2453 36% - setq 2453 36% - find-file-noselect 1864 27% - find-file-noselect-1 1486 21% - after-find-file 1396 20% - run-hooks 1396 20% - vc-refresh-state 640 9% - vc-backend 640 9% - vc-registered 638 9% - mapc 638 9% - #<compiled 0x97a6b2bf5b90b78> 638 9% - vc-call-backend 638 9% - apply 338 4% - vc-git-registered 168 2% - cd 165 2% - locate-file 164 2% - locate-file-internal 164 2% #<compiled -0x52006ec4d330c6b> 3 0% cd-absolute 68 1% file-relative-name 49 0% - vc-git--out-ok 49 0% - apply 49 0% - vc-git--call 49 0% - apply 49 0% - process-file 49 0% apply 33 0% - vc-git-root 33 0% - vc-find-root 33 0% - locate-dominating-file 2 0% abbreviate-file-name 18 0% - if 18 0% - progn 17 0% - load 9 0% - require 4 0% - byte-code 2 0% require 1 0% - byte-code 1 0% require 1 0% - vc-git-registered 1 0% - vc-git--out-ok 1 0% - apply 1 0% - vc-git--call 1 0% - apply 1 0% - process-file 1 0% apply 1 0% - #<compiled -0x1c1ed57c55005f9b> 1 0% kill-buffer 257 3% - vc-rcs-registered 257 3% - vc-default-registered 256 3% - vc-check-master-templates 256 3% - mapcar 256 3% #<compiled -0x117f5e38d4b1020e> 19 0% - vc-svn-registered 19 0% - let 19 0% - if 19 0% - vc-find-root 19 0% - locate-dominating-file 8 0% abbreviate-file-name 11 0% - vc-bzr-registered 11 0% - if 11 0% - vc-find-root 11 0% locate-dominating-file 5 0% - vc-sccs-registered 5 0% - vc-default-registered 5 0% - vc-check-master-templates 5 0% - mapcar 5 0% #<compiled 0xc73f4e04c5b42f1> 4 0% - vc-src-registered 4 0% - vc-default-registered 4 0% - vc-check-master-templates 4 0% - mapcar 4 0% #<compiled -0x1827ab73baee87a5> 2 0% - vc-mtn-registered 2 0% - if 2 0% - vc-find-root 2 0% locate-dominating-file 1 0% - vc-cvs-registered 1 0% if 1 0% - vc-hg-registered 1 0% - if 1 0% - vc-find-root 1 0% locate-dominating-file 472 6% - vc-mode-line 338 4% - vc-call-backend 338 4% - apply 338 4% - vc-git-mode-line-string 281 4% - vc-working-revision 281 4% - vc-call-backend 281 4% - apply 281 4% - vc-git-working-revision 281 4% - vc-git--rev-parse 281 4% - vc-git--out-ok 281 4% - apply 281 4% - vc-git--call 281 4% - apply 281 4% - process-file 281 4% apply 56 0% - vc-git--symbolic-ref 55 0% - vc-git--run-command-string 55 0% - apply 55 0% - vc-git--out-ok 55 0% - apply 55 0% - vc-git--call 55 0% - apply 55 0% - process-file 55 0% apply 283 4% - vc-call-backend 283 4% - apply 283 4% - vc-git-find-file-hook 283 4% - vc-state 283 4% - vc-state-refresh 283 4% - vc-call-backend 283 4% - apply 283 4% - vc-git-state 281 4% - apply 280 4% - vc-git--run-command-string 178 2% - apply 177 2% - vc-git--out-ok 177 2% - apply 177 2% - vc-git--call 177 2% - apply 173 2% - process-file 172 2% apply 102 1% file-relative-name 1 0% - vc-git--program-version 1 0% - vc-git--run-command-string 1 0% - apply 1 0% - vc-git--out-ok 1 0% - apply 1 0% - vc-git--call 1 0% - apply 1 0% - process-file 1 0% apply 1 0% version<= 56 0% - normal-mode 52 0% - set-auto-mode 52 0% - set-auto-mode--apply-alist 25 0% - set-auto-mode-0 25 0% - emacs-lisp-mode 16 0% - run-mode-hooks 13 0% - hack-local-variables 9 0% - hack-local-variables-prop-line 6 0% - set-auto-mode-1 5 0% inhibit-local-variables-p 2 0% file-remote-p 3 0% - run-hooks 3 0% - global-font-lock-mode-enable-in-buffers 3 0% - turn-on-font-lock-if-desired 3 0% - turn-on-font-lock 3 0% - font-lock-mode 3 0% - font-lock-default-function 3 0% - font-lock-mode-internal 3 0% - font-lock-turn-on-thing-lock 3 0% - jit-lock-register 2 0% - jit-lock-mode 1 0% add-hook 7 0% - lisp-data-mode 4 0% - prog-mode 2 0% add-hook 1 0% kill-all-local-variables 2 0% lisp-mode-variables 1 0% add-hook 8 0% assoc-default 4 0% - font-lock-mode 4 0% - font-lock-default-function 3 0% - font-lock-mode-internal 1 0% - font-lock-turn-on-thing-lock 1 0% jit-lock-register 1 0% - add-hook 1 0% - sort 1 0% #<compiled -0x6178706b98d8672> 71 1% - file-truename 55 0% - file-truename 47 0% - file-truename 34 0% - file-truename 21 0% - file-truename 11 0% file-truename 10 0% - insert-file-contents 10 0% - set-auto-coding 10 0% - find-auto-coding 9 0% auto-coding-alist-lookup 1 0% sgml-html-meta-auto-coding-function 4 0% abbreviate-file-name 295 4% - find-buffer-visiting 25 0% - file-truename 16 0% - file-truename 9 0% - file-truename 5 0% - file-truename 1 0% - file-truename 1 0% file-truename 2 0% abbreviate-file-name 256 3% abbreviate-file-name 24 0% - file-truename 17 0% - file-truename 10 0% - file-truename 7 0% - file-truename 4 0% - file-truename 3 0% file-truename 1 0% - create-file-buffer 1 0% - apply 1 0% - uniquify--create-file-buffer-advice 1 0% uniquify-rationalize-file-buffer-names 1 0% - kill-buffer 1 0% process-kill-buffer-query-function 6 0% - message 6 0% - float-time 4 0% - time-since 3 0% - byte-code 1 0% require 3 0% - elisp--preceding-sexp 3 0% forward-sexp 12 0% - minibuffer-complete 12 0% - completion-in-region 12 0% - completion--in-region 12 0% - #<compiled -0x1b9ffa9f1839062> 12 0% - apply 12 0% - #<compiled 0xde9be983a24fd0> 12 0% - completion--in-region-1 12 0% - completion--do-completion 8 0% - minibuffer-completion-help 5 0% - temp-buffer-window-show 5 0% - display-buffer 5 0% - display-buffer-at-bottom 4 0% - window--display-buffer 3 0% - #<compiled -0x189b60680cedbb15> 2 0% - display-completion-list 2 0% - run-hooks 2 0% - completion-setup-function 1 0% substitute-command-keys 1 0% - read-extended-command--affixation 1 0% - mapcar 1 0% #<compiled 0x589b0a2756da0d7> 1 0% fit-window-to-buffer 1 0% - split-window-no-error 1 0% split-window 3 0% - completion-all-completions 3 0% - completion--nth-completion 3 0% - completion--some 3 0% - #<compiled 0x1e98a616a148b8c2> 3 0% - completion-basic-all-completions 3 0% - completion-pcm--all-completions 3 0% - all-completions 3 0% - #<compiled 0x52202314d904927> 3 0% complete-with-action 4 0% - completion-try-completion 4 0% - completion--nth-completion 4 0% - completion--some 4 0% - #<compiled 0x1e98a616b048b8c2> 4 0% - completion-basic-try-completion 4 0% - try-completion 4 0% - #<compiled 0x52202314d904927> 4 0% complete-with-action 8 0% - execute-extended-command 8 0% - command-execute 8 0% - call-interactively 8 0% - funcall-interactively 8 0% profiler-report 6 0% - previous-line 6 0% - line-move 5 0% line-move-visual 133 1% - byte-code 133 1% - read-extended-command 133 1% - completing-read 133 1% - completing-read-default 23 0% read-from-minibuffer 545 8% + ... 38 0% + timer-event-handler 5 0% + redisplay_internal (C function) 1 0% + jit-lock--antiblink-post-command ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 13:56 ` Gerd Möllmann @ 2023-10-05 16:19 ` Eli Zaretskii 2023-10-05 16:26 ` Alan Third 2023-10-05 16:36 ` Gerd Möllmann 0 siblings, 2 replies; 45+ messages in thread From: Eli Zaretskii @ 2023-10-05 16:19 UTC (permalink / raw) To: Gerd Möllmann; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas > From: Gerd Möllmann <gerd.moellmann@gmail.com> > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com > Date: Thu, 05 Oct 2023 15:56:11 +0200 > > To the question of profiling. I've now used the built-in profiler on > the two commits, but I must say that I don't see where the difference > comes from. These are debug builds, 5 runs of the benchmark. Are you sure you haven't profiled the same build? The profiles look almost identical. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 16:19 ` Eli Zaretskii @ 2023-10-05 16:26 ` Alan Third 2023-10-05 16:43 ` Gerd Möllmann 2023-10-05 16:36 ` Gerd Möllmann 1 sibling, 1 reply; 45+ messages in thread From: Alan Third @ 2023-10-05 16:26 UTC (permalink / raw) To: Eli Zaretskii Cc: Gerd Möllmann, gregory, 65908, stefankangas, ccsmile2008 On Thu, Oct 05, 2023 at 07:19:20PM +0300, Eli Zaretskii wrote: > > From: Gerd Möllmann <gerd.moellmann@gmail.com> > > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, > > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com > > Date: Thu, 05 Oct 2023 15:56:11 +0200 > > > > To the question of profiling. I've now used the built-in profiler on > > the two commits, but I must say that I don't see where the difference > > comes from. These are debug builds, 5 runs of the benchmark. > > Are you sure you haven't profiled the same build? The profiles look > almost identical. I'm wondering if that indicates the problem is in an externally called application, like git. I notice VC is being used, and if I copy the lisp directory into a non-VC'd directory and run the test there it's significantly faster. For some reason I can no longer replicate the problem though, so I can't check this idea myself. -- Alan Third ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 16:26 ` Alan Third @ 2023-10-05 16:43 ` Gerd Möllmann 0 siblings, 0 replies; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 16:43 UTC (permalink / raw) To: Alan Third; +Cc: Eli Zaretskii, 65908, stefankangas, gregory, ccsmile2008 Alan Third <alan@idiocy.org> writes: > On Thu, Oct 05, 2023 at 07:19:20PM +0300, Eli Zaretskii wrote: >> > From: Gerd Möllmann <gerd.moellmann@gmail.com> >> > Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, >> > 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com >> > Date: Thu, 05 Oct 2023 15:56:11 +0200 >> > >> > To the question of profiling. I've now used the built-in profiler on >> > the two commits, but I must say that I don't see where the difference >> > comes from. These are debug builds, 5 runs of the benchmark. >> >> Are you sure you haven't profiled the same build? The profiles look >> almost identical. > > I'm wondering if that indicates the problem is in an externally called > application, like git. I notice VC is being used, and if I copy the > lisp directory into a non-VC'd directory and run the test there it's > significantly faster. > > For some reason I can no longer replicate the problem though, so I > can't check this idea myself. It's ca. 50% faster when I copy the files somewhere else. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 16:19 ` Eli Zaretskii 2023-10-05 16:26 ` Alan Third @ 2023-10-05 16:36 ` Gerd Möllmann 2023-10-05 17:04 ` Eli Zaretskii 1 sibling, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 16:36 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas Eli Zaretskii <eliz@gnu.org> writes: >> From: Gerd Möllmann <gerd.moellmann@gmail.com> >> Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, >> 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com >> Date: Thu, 05 Oct 2023 15:56:11 +0200 >> >> To the question of profiling. I've now used the built-in profiler on >> the two commits, but I must say that I don't see where the difference >> comes from. These are debug builds, 5 runs of the benchmark. > > Are you sure you haven't profiled the same build? The profiles look > almost identical. Yes, I'm sure. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 16:36 ` Gerd Möllmann @ 2023-10-05 17:04 ` Eli Zaretskii 2023-10-05 17:15 ` Gerd Möllmann 0 siblings, 1 reply; 45+ messages in thread From: Eli Zaretskii @ 2023-10-05 17:04 UTC (permalink / raw) To: Gerd Möllmann; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas > From: Gerd Möllmann <gerd.moellmann@gmail.com> > Cc: alan@idiocy.org, gregory@heytings.org, 65908@debbugs.gnu.org, > stefankangas@gmail.com, ccsmile2008@outlook.com > Date: Thu, 05 Oct 2023 18:36:15 +0200 > > Eli Zaretskii <eliz@gnu.org> writes: > > >> From: Gerd Möllmann <gerd.moellmann@gmail.com> > >> Cc: Eli Zaretskii <eliz@gnu.org>, gregory@heytings.org, > >> 65908@debbugs.gnu.org, stefankangas@gmail.com, ccsmile2008@outlook.com > >> Date: Thu, 05 Oct 2023 15:56:11 +0200 > >> > >> To the question of profiling. I've now used the built-in profiler on > >> the two commits, but I must say that I don't see where the difference > >> comes from. These are debug builds, 5 runs of the benchmark. > > > > Are you sure you haven't profiled the same build? The profiles look > > almost identical. > > Yes, I'm sure. Then I guess the problem is not with the Emacs Lisp code, but either with the primitives implemented in C or some programs (Git?) invoked by this recipe. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 17:04 ` Eli Zaretskii @ 2023-10-05 17:15 ` Gerd Möllmann 2023-10-05 18:25 ` Alan Third 0 siblings, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 17:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: ccsmile2008, alan, 65908, gregory, stefankangas Eli Zaretskii <eliz@gnu.org> writes: >> > Are you sure you haven't profiled the same build? The profiles look >> > almost identical. >> >> Yes, I'm sure. > > Then I guess the problem is not with the Emacs Lisp code, but either > with the primitives implemented in C or some programs (Git?) invoked > by this recipe. I find Alans's idea pretty compelling. Alas, I don't know enough about git's internals to tell what it does when locales aren't set up right. But it's very plausible, given the profiler output. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 17:15 ` Gerd Möllmann @ 2023-10-05 18:25 ` Alan Third 2023-10-05 18:33 ` Gerd Möllmann 0 siblings, 1 reply; 45+ messages in thread From: Alan Third @ 2023-10-05 18:25 UTC (permalink / raw) To: Gerd Möllmann Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas On Thu, Oct 05, 2023 at 07:15:49PM +0200, Gerd Möllmann wrote: > Eli Zaretskii <eliz@gnu.org> writes: > > >> > Are you sure you haven't profiled the same build? The profiles look > >> > almost identical. > >> > >> Yes, I'm sure. > > > > Then I guess the problem is not with the Emacs Lisp code, but either > > with the primitives implemented in C or some programs (Git?) invoked > > by this recipe. > > I find Alans's idea pretty compelling. Alas, I don't know enough about > git's internals to tell what it does when locales aren't set up > right. But it's very plausible, given the profiler output. OK, with Gerd's latest patch installed, I set my shell thus: export LANG="en_GB.UTF-8" export LC_COLLATE= export LC_CTYPE= export LC_MESSAGES= export LC_MONETARY= export LC_NUMERIC= export LC_TIME= export LC_ALL= and run: LANG=en_DE.UTF-8 src/emacs -Q which prints: LANG=en_DE.UTF-8 cannot be used, using en_US.UTF-8 instead. and sure enough "C-u M-! locale" gives: LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL="en_US.UTF-8" I then run the test script against the lisp directory in the emacs git repo: --- files: 61, delta: 4.428015 Elapsed time: 4.432377s (0.161921s in 13 GCs) "--- files: 61, delta: 4.428015" --- files: 61, delta: 4.416348 Elapsed time: 4.421116s (0.150580s in 12 GCs) "--- files: 61, delta: 4.416348" --- files: 61, delta: 4.391077 Elapsed time: 4.395202s (0.150900s in 12 GCs) "--- files: 61, delta: 4.391077" Then against the same directory copied elsewhere: --- files: 61, delta: 0.882561 Elapsed time: 0.887944s (0.138922s in 11 GCs) "--- files: 61, delta: 0.882561" --- files: 61, delta: 0.882582 Elapsed time: 0.887593s (0.139193s in 11 GCs) "--- files: 61, delta: 0.882582" --- files: 61, delta: 0.866825 Elapsed time: 0.871124s (0.122224s in 10 GCs) "--- files: 61, delta: 0.866825" Then I run: LANG= src/emacs -Q and run the test against the lisp directory in the repo: --- files: 61, delta: 5.87121 Elapsed time: 5.875535s (0.160997s in 13 GCs) "--- files: 61, delta: 5.87121" --- files: 61, delta: 5.867494 Elapsed time: 5.871656s (0.150614s in 12 GCs) "--- files: 61, delta: 5.867494" --- files: 61, delta: 5.83144 Elapsed time: 5.862261s (0.163723s in 13 GCs) "--- files: 61, delta: 5.83144" and the lisp directory not in the lisp repo: --- files: 61, delta: 0.869081 Elapsed time: 0.873759s (0.134711s in 11 GCs) "--- files: 61, delta: 0.869081" --- files: 61, delta: 0.873445 Elapsed time: 0.878768s (0.133343s in 11 GCs) "--- files: 61, delta: 0.873445" --- files: 61, delta: 0.870359 Elapsed time: 0.875465s (0.132767s in 11 GCs) "--- files: 61, delta: 0.870359" So the time with no git repo are near identical, but the times with a git repo vary by over a second. When I do "LANG=" it's trying to set the local to the empty string because we only check if LANG is null, which it's not, it's the empty string (I think) and that's resulting in a locale like (C-u M-! locale): LANG= LC_COLLATE="C" LC_CTYPE="C" LC_MESSAGES="C" LC_MONETARY="C" LC_NUMERIC="C" LC_TIME="C" LC_ALL="C" I don't think this is conclusive proof, but I think that either git or VC have a problem with a slightly broken locale. I'm not saying there's a bug here, it could simply be that we call git many times and it's having to work out the locale each time from the dodgy input I've given it. (I tried en_GB without the UTF-8 coding and the times were pretty much identical to the en_US.UTF-8 times.) -- Alan Third ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 18:25 ` Alan Third @ 2023-10-05 18:33 ` Gerd Möllmann 2023-10-05 18:46 ` Gerd Möllmann 0 siblings, 1 reply; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 18:33 UTC (permalink / raw) To: Alan Third; +Cc: ccsmile2008, Eli Zaretskii, 65908, gregory, stefankangas Alan Third <alan@idiocy.org> writes: > When I do "LANG=" it's trying to set the local to the empty string > because we only check if LANG is null, which it's not, it's the empty > string (I think) and that's resulting in a locale like (C-u M-! locale): > > LANG= > LC_COLLATE="C" > LC_CTYPE="C" > LC_MESSAGES="C" > LC_MONETARY="C" > LC_NUMERIC="C" > LC_TIME="C" > LC_ALL="C" That's a good point. I should also check if LANG is set but empty, because "" changes the meaning of setlocale. I'll commit that in a second :-). > I don't think this is conclusive proof, but I think that either git or > VC have a problem with a slightly broken locale. I'm not saying > there's a bug here, it could simply be that we call git many times and > it's having to work out the locale each time from the dodgy input I've > given it. Yeah, to me that makes a lot of sense. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 18:33 ` Gerd Möllmann @ 2023-10-05 18:46 ` Gerd Möllmann 0 siblings, 0 replies; 45+ messages in thread From: Gerd Möllmann @ 2023-10-05 18:46 UTC (permalink / raw) To: ccsmile2008; +Cc: Alan Third, 65908, Eli Zaretskii, gregory, stefankangas Committed to emacs-29 as aad8b5d78f306ac9ca0c03734524c9f49585bee8. I'll close this bug, please reopen if it's not fixed for you in 29.2. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-04 9:12 ` Stefan Kangas 2023-10-04 10:55 ` Gerd Möllmann @ 2023-10-05 8:58 ` Gregory Heytings 2023-10-05 9:03 ` Gregory Heytings 1 sibling, 1 reply; 45+ messages in thread From: Gregory Heytings @ 2023-10-05 8:58 UTC (permalink / raw) To: Stefan Kangas; +Cc: Gerd Möllmann, Eli Zaretskii, 65908, ccsmile2008 >> It's okay in principle, but the idea of that script is to include only >> commits that don't build on GNU/Linux, with GCC, and with the default >> build options (just "make"). > > Thanks, I now see that explained a bit further down in the file. > > Perhaps that explanation could be moved to the very top of the file? > Done (cfcdb6ec2a). > > BTW, if you have any scripts that you use to update the list, it might > be useful to add them to emacs.git. Perhaps just as a comment to > git-bisect-start, depending on how long it is. That would decrease the > bus factor. > These scripts are almost trivial: for each not yet checked commit, do git checkout, make, and check the result. The only slightly complex part is "for each not yet checked commit": it uses the list of all commits that I already checked (currently 21484, in a 860 KB text file), and I'm not sure adding that big file to emacs.git would be appropriate. ^ permalink raw reply [flat|nested] 45+ messages in thread
* bug#65908: 29.1.50; Emacs 29 regresses on macOS 2023-10-05 8:58 ` Gregory Heytings @ 2023-10-05 9:03 ` Gregory Heytings 0 siblings, 0 replies; 45+ messages in thread From: Gregory Heytings @ 2023-10-05 9:03 UTC (permalink / raw) To: Stefan Kangas; +Cc: Gerd Möllmann, Eli Zaretskii, 65908, ccsmile2008 > > it uses the list of all commits that I already checked (currently 21484, > in a 860 KB text file) > Sorry: (currently 39928, in 1.9 MB text file). ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2023-10-05 18:46 UTC | newest] Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-09-13 6:47 bug#65908: 29.1.50; Emacs 29 regresses on macOS Zhang Haijun 2023-10-04 5:44 ` Gerd Möllmann 2023-10-04 7:38 ` Eli Zaretskii 2023-10-04 7:50 ` Gerd Möllmann 2023-10-04 8:29 ` Stefan Kangas 2023-10-04 8:32 ` Gerd Möllmann 2023-10-04 9:02 ` Gregory Heytings 2023-10-04 9:12 ` Gerd Möllmann 2023-10-04 9:12 ` Stefan Kangas 2023-10-04 10:55 ` Gerd Möllmann 2023-10-04 12:43 ` Gerd Möllmann 2023-10-04 21:16 ` Alan Third 2023-10-05 5:41 ` Eli Zaretskii 2023-10-05 5:55 ` Gerd Möllmann 2023-10-05 6:08 ` Eli Zaretskii 2023-10-05 8:52 ` Gerd Möllmann 2023-10-05 9:48 ` Alan Third 2023-10-05 11:12 ` Gerd Möllmann 2023-10-05 13:18 ` Gerd Möllmann 2023-10-05 16:11 ` Eli Zaretskii 2023-10-05 16:33 ` Alan Third 2023-10-05 16:38 ` Gerd Möllmann 2023-10-05 17:02 ` Eli Zaretskii 2023-10-05 17:15 ` Alan Third 2023-10-05 13:51 ` Alan Third 2023-10-05 14:01 ` Gerd Möllmann 2023-10-05 14:09 ` Gerd Möllmann 2023-10-05 14:58 ` Alan Third 2023-10-05 15:11 ` Gerd Möllmann 2023-10-05 16:29 ` Eli Zaretskii 2023-10-05 16:39 ` Gerd Möllmann 2023-10-05 17:06 ` Eli Zaretskii 2023-10-05 18:08 ` Stefan Kangas 2023-10-05 13:56 ` Gerd Möllmann 2023-10-05 16:19 ` Eli Zaretskii 2023-10-05 16:26 ` Alan Third 2023-10-05 16:43 ` Gerd Möllmann 2023-10-05 16:36 ` Gerd Möllmann 2023-10-05 17:04 ` Eli Zaretskii 2023-10-05 17:15 ` Gerd Möllmann 2023-10-05 18:25 ` Alan Third 2023-10-05 18:33 ` Gerd Möllmann 2023-10-05 18:46 ` Gerd Möllmann 2023-10-05 8:58 ` Gregory Heytings 2023-10-05 9:03 ` Gregory Heytings
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).