GNU bug report logs - #73855
[PATCH] * lisp/autorevert.el: Avoid reverting buffer in short time

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 73855 in the body.
You can then email your comments to 73855 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lin Sun <sunlin7.mail <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] * lisp/autorevert.el: Avoid reverting buffer in short time
Date: Thu, 17 Oct 2024 23:24:00 +0000

[Message part 1 (text/plain, inline)]

Hi,

High CPU consumption after enabling the "auto-revert" for a buffer.
Here is a way to reproduce the issue:
1. on one terminal run command "strace -f -o /tmp/a.log vi -nw"
2. on second terminal, start another emacs and open the file
/tmp/a.log, enable the "auto-revert" mode on the /tmp/a.log buffer.

Typing on 1st terminal(vi), the strace will continually write the
/tmp/a.log, and the emacs try to revert the /tmp/a.log buffer again
and again, then CPU loading turns high.

The function `auto-revert-handler` may be called twice for 2.5 seconds
intervals on a rapidly changed buffer/file.

The root cause is `auto-revert--end-lockout` will call
`auto-revert-handler` in which the `auto-revert--lockout-timer` was
cleared, then the next call `auto-revert-notify-handler` will revert
the buffer immediately regardless the buffer actually was revert just
before.

This patch will record when the buffer was reverted and avoid
reverting it again in the same second.

[0001-lisp-autorevert.el-Avoid-reverting-buffer-in-short-t.patch (text/x-patch, attachment)]

Message #8 received at 73855 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Lin Sun <sunlin7.mail <at> gmail.com>
Cc: 73855 <at> debbugs.gnu.org
Subject: Re: bug#73855: [PATCH] * lisp/autorevert.el: Avoid reverting buffer
 in short time
Date: Fri, 18 Oct 2024 09:50:44 +0200

Lin Sun <sunlin7.mail <at> gmail.com> writes:

> Hi,

Hi,

> High CPU consumption after enabling the "auto-revert" for a buffer.
> Here is a way to reproduce the issue:
> 1. on one terminal run command "strace -f -o /tmp/a.log vi -nw"
> 2. on second terminal, start another emacs and open the file
> /tmp/a.log, enable the "auto-revert" mode on the /tmp/a.log buffer.
>
> Typing on 1st terminal(vi), the strace will continually write the
> /tmp/a.log, and the emacs try to revert the /tmp/a.log buffer again
> and again, then CPU loading turns high.
>
> The function `auto-revert-handler` may be called twice for 2.5 seconds
> intervals on a rapidly changed buffer/file.
>
> The root cause is `auto-revert--end-lockout` will call
> `auto-revert-handler` in which the `auto-revert--lockout-timer` was
> cleared, then the next call `auto-revert-notify-handler` will revert
> the buffer immediately regardless the buffer actually was revert just
> before.
>
> This patch will record when the buffer was reverted and avoid
> reverting it again in the same second.

There is no bug. If auto-revert-use-notify is non-nil, file
notifications are in game, which are *supposed* to revert
immediately. No delay is wanted.

In your case, where mass write happens to a file, I recommend to set
auto-revert-use-notify to nil. Polling is used then instead, with
auto-revert-interval interval between reverts. The default value is 5
(seconds), you might change it to 1.

Furthermore, your use case doesn't look ideal for enabling
auto-revert-mode. Checking fast changing log files is better done with
auto-revert-tail-mode.

Best regards, Michael.

Message #11 received at 73855 <at> debbugs.gnu.org (full text, mbox):

From: Lin Sun <sunlin7.mail <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 73855 <at> debbugs.gnu.org
Subject: Re: bug#73855: [PATCH] * lisp/autorevert.el: Avoid reverting buffer
 in short time
Date: Sat, 19 Oct 2024 05:58:14 +0000

On Fri, Oct 18, 2024 at 7:50 AM Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> In your case, where mass write happens to a file, I recommend to set
> auto-revert-use-notify to nil. Polling is used then instead, with
> auto-revert-interval interval between reverts. The default value is 5
> (seconds), you might change it to 1.
>
> Furthermore, your use case doesn't look ideal for enabling
> auto-revert-mode. Checking fast changing log files is better done with
> auto-revert-tail-mode.
>
Thanks for the comments, the tail mode worked for me; but actually I
enabled the global-auto-revert-mode, I have to manually switch to tail
mode for some buffers. And yes, the default interval value is 5
seconds.

Let's look at this case: the auto-revert-interval is 5, a writing
happened 1 write / second, total 20 writings (in 20 seconds). The
revert-handler run on: first time (T0), and then locks for 5 seconds;
then T5 lock done, revert the buffer; then T6 reverts the and locks it
again... The revert happened as below:

T0...T5,T6...T11,T12...T17,T18...T23

The T5,T6 are nearby, similar happened on T11,T12, and after each lock
end, there is a revert executed nearby.

This patch try to enhance the lock, then makes the revert happened on:

T0...T5...T10...T15...

That reduced loading on my local.

Best Regards, Lin

Message #14 received at 73855 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Lin Sun <sunlin7.mail <at> gmail.com>
Cc: 73855 <at> debbugs.gnu.org
Subject: Re: bug#73855: [PATCH] * lisp/autorevert.el: Avoid reverting buffer
 in short time
Date: Sat, 19 Oct 2024 11:06:41 +0200

Lin Sun <sunlin7.mail <at> gmail.com> writes:

Hi Lin,

> Let's look at this case: the auto-revert-interval is 5, a writing
> happened 1 write / second, total 20 writings (in 20 seconds). The
> revert-handler run on: first time (T0), and then locks for 5 seconds;
> then T5 lock done, revert the buffer; then T6 reverts the and locks it
> again... The revert happened as below:
>
> T0...T5,T6...T11,T12...T17,T18...T23
>
> The T5,T6 are nearby, similar happened on T11,T12, and after each lock
> end, there is a revert executed nearby.
>
> This patch try to enhance the lock, then makes the revert happened on:
>
> T0...T5...T10...T15...
>
> That reduced loading on my local.

Thanks for explanation, now I understand the scenario.

Your patch makes sense. However, autorevert-tests fail now:

--8<---------------cut here---------------start------------->8---
# make -C test autorevert-tests
make: Entering directory '/home/albinus/src/emacs/test'
make[1]: Entering directory '/home/albinus/src/emacs/test'
  GEN      lisp/autorevert-tests.log
Running 7 tests (2024-10-19 11:02:58+0200, selector `(not (tag :unstable))')
Reverting buffer `emacs-test-zzmdD8-autorevert'
   passed  1/7  auto-revert-test00-auto-revert-mode (3.554035 sec)
(Shell command succeeded with no output)
Reverting buffer `auto-revert-testenE8rY-autorevert'
Reverting buffer `auto-revert-testOJVaub-autorevert'
   passed  2/7  auto-revert-test01-auto-revert-several-files (0.172674 sec)
Reverting buffer `emacs-test-IIR73t-autorevert'
   passed  3/7  auto-revert-test03-auto-revert-tail-mode (2.527101 sec)
Reverting buffer `tmp'
Reverting buffer `tmp'
   passed  4/7  auto-revert-test04-auto-revert-mode-dired (0.457824 sec)
Reverting buffer `emacs-test-i5RWpJ-autorevert'
Test auto-revert-test05-global-notify backtrace:
  signal(ert-test-failed (((should (equal (auto-revert-test--buffer-st
  ert-fail(((should (equal (auto-revert-test--buffer-string buf-2) "2-
  (if (unwind-protect (setq value-171 (apply fn-169 args-170)) (setq f
  (let (form-description-173) (if (unwind-protect (setq value-171 (app
  (let ((value-171 'ert-form-evaluation-aborted-172)) (let (form-descr
  (let* ((fn-169 #'equal) (args-170 (condition-case err (list (auto-re
  (progn (setq buf-1 (find-file-noselect file-1)) (auto-revert-test--i
  (unwind-protect (progn (setq buf-1 (find-file-noselect file-1)) (aut
  (let* ((auto-revert-use-notify t) (auto-revert-avoid-polling t) (was
  (progn (let* ((auto-revert-use-notify t) (auto-revert-avoid-polling
  (unwind-protect (progn (let* ((auto-revert-use-notify t) (auto-rever
  (let* ((coding-system-for-write nil) (temp-file (identity (make-temp
  (progn (let* ((coding-system-for-write nil) (temp-file (identity (ma
  (unwind-protect (progn (let* ((coding-system-for-write nil) (temp-fi
  (let* ((coding-system-for-write nil) (temp-file (identity (make-temp
  (progn (let* ((coding-system-for-write nil) (temp-file (identity (ma
  (unwind-protect (progn (let* ((coding-system-for-write nil) (temp-fi
  (let* ((coding-system-for-write nil) (temp-file (identity (make-temp
  (progn (customize-set-variable 'auto-revert-interval 0.1) (let* ((co
  (unwind-protect (progn (customize-set-variable 'auto-revert-interval
  (let ((auto-revert-interval-orig auto-revert-interval)) (unwind-prot
  #f(lambda () [t] (let ((value-147 (gensym "ert-form-evaluation-abort
  #f(compiled-function () #<bytecode 0x1e80ca290561ae1>)()
  handler-bind-1(#f(compiled-function () #<bytecode 0x1e80ca290561ae1>
  ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test
  ert-run-test(#s(ert-test :name auto-revert-test05-global-notify :doc
  ert-run-or-rerun-test(#s(ert--stats :selector ... :tests ... :test-m
  ert-run-tests((not (tag :unstable)) #f(compiled-function (event-type
  ert-run-tests-batch((not (tag :unstable)))
  ert-run-tests-batch-and-exit((not (tag :unstable)))
  eval((ert-run-tests-batch-and-exit '(not (tag :unstable))) t)
  command-line-1(("-L" ":." "-l" "ert" "--eval" "(setq treesit-extra-l
  command-line()
  normal-top-level()
Test auto-revert-test05-global-notify condition:
    (ert-test-failed
     ((should (equal (auto-revert-test--buffer-string buf-2) "2-a")) :form
      (equal "" "2-a") :value nil :explanation
      (arrays-of-different-length 0 3 "" "2-a" first-mismatch-at 0)))
   FAILED  5/7  auto-revert-test05-global-notify (1.020224 sec) at lisp/autorevert-tests.el:451
Reverting buffer `emacs-test-cjR4uH-autorevert-2'
   passed  6/7  auto-revert-test06-write-file (0.136182 sec)
Reverting buffer `emacs-test-EnNjg7-autorevert'
Reverting buffer `emacs-test-EnNjg7-autorevert-0'
Reverting buffer `emacs-test-EnNjg7-autorevert-1'
Reverting buffer `emacs-test-EnNjg7-autorevert-2'
Reverting buffer `emacs-test-EnNjg7-autorevert-3'
Reverting buffer `emacs-test-EnNjg7-autorevert-4'
Reverting buffer `emacs-test-EnNjg7-autorevert-5'
Reverting buffer `emacs-test-EnNjg7-autorevert-6'
Reverting buffer `emacs-test-EnNjg7-autorevert-7'
Reverting buffer `emacs-test-EnNjg7-autorevert-8'
Reverting buffer `emacs-test-EnNjg7-autorevert-9'
   passed  7/7  auto-revert-test07-auto-revert-several-buffers (5.077571 sec)

Ran 7 tests, 6 results as expected, 1 unexpected (2024-10-19 11:03:12+0200, 14.040452 sec)

1 unexpected results:
   FAILED  auto-revert-test05-global-notify

make[1]: *** [Makefile:185: lisp/autorevert-tests.log] Error 1
make[1]: Leaving directory '/home/albinus/src/emacs/test'
make: *** [Makefile:251: lisp/autorevert-tests] Error 2
make: Leaving directory '/home/albinus/src/emacs/test'
--8<---------------cut here---------------end--------------->8---

Could you pls check what's up?

> Best Regards, Lin

Best regards, Michael.

Message #17 received at 73855 <at> debbugs.gnu.org (full text, mbox):

From: Lin Sun <sunlin7.mail <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 73855 <at> debbugs.gnu.org
Subject: Re: bug#73855: [PATCH] * lisp/autorevert.el: Avoid reverting buffer
 in short time
Date: Sat, 19 Oct 2024 17:52:35 +0000

[Message part 1 (text/plain, inline)]

Hi Michael,

On Sat, Oct 19, 2024 at 9:06 AM Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Thanks for explanation, now I understand the scenario.
>
> Your patch makes sense. However, autorevert-tests fail now:
...
> 1 unexpected results:
>    FAILED  auto-revert-test05-global-notify
>
> make[1]: *** [Makefile:185: lisp/autorevert-tests.log] Error 1
...
> Could you pls check what's up?
>
> Best regards, Michael.

Thank you for found the issue, really appreciate it! The issue was
fixed by setting the variable 'auto-revert--lockout-interval' to the
half value of 'auto-revert-interval' (similar to its definition).

Please help review again, thanks.

[0001-Enhance-the-auto-revert-to-avoid-revert-a-buffer-in-.patch (text/x-patch, attachment)]

Message #22 received at 73855-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Lin Sun <sunlin7.mail <at> gmail.com>
Cc: 73855-done <at> debbugs.gnu.org
Subject: Re: bug#73855: [PATCH] * lisp/autorevert.el: Avoid reverting buffer
 in short time
Date: Sun, 20 Oct 2024 11:15:26 +0200

Version: 31.1

Lin Sun <sunlin7.mail <at> gmail.com> writes:

> Hi Michael,

Hi Lin,

> Thank you for found the issue, really appreciate it! The issue was
> fixed by setting the variable 'auto-revert--lockout-interval' to the
> half value of 'auto-revert-interval' (similar to its definition).
>
> Please help review again, thanks.

This looks good now. I've pushed it to master, closing the bug.

Best regards, Michael.

Message #25 received at 73855-done <at> debbugs.gnu.org (full text, mbox):

From: Lin Sun <sunlin7.mail <at> gmail.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 73855-done <at> debbugs.gnu.org
Subject: Re: bug#73855: [PATCH] * lisp/autorevert.el: Avoid reverting buffer
 in short time
Date: Sun, 20 Oct 2024 18:29:57 +0000

On Sun, Oct 20, 2024 at 9:15 AM Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Version: 31.1
>
> Lin Sun <sunlin7.mail <at> gmail.com> writes:
>
> > Hi Michael,
>
> Hi Lin,
>
> > Thank you for found the issue, really appreciate it! The issue was
> > fixed by setting the variable 'auto-revert--lockout-interval' to the
> > half value of 'auto-revert-interval' (similar to its definition).
> >
> > Please help review again, thanks.
>
> This looks good now. I've pushed it to master, closing the bug.
>
> Best regards, Michael.

Hi Michael,

Thank you so much!

Best regards, Lin

Message #28 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Lin Sun <sunlin7.mail <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [BUG] Error: void-function (rx) during generating autoloads for
 python.el when building from source
Date: Wed, 13 Nov 2024 00:31:07 +0000

I met a compile issue while generating the autoloads.el from
python.el, it seems the `python--auto-mode-alist-regexp` is defined
with 'rx' but the 'rx' wasn't loaded.
Should relate to the commit `2f485e68ff96cc66a17df2c0a58e272bbfc24765`
    Add Python "*.pth" files to auto-mode-alist
    * lisp/progmodes/python.el (python--auto-mode-alist-regexp): New
    variable.

Here is the errors:

Loading ~/dev-env/work-dev/emacs31.build/lisp/theme-loaddefs.el (source)...
Error: void-function (rx)
  (rx (or (seq "." (or "py" "pth" "pyi" "pyw")) (seq "/" (or
"SConstruct" "SConscript"))) eos)
  (defconst python--auto-mode-alist-regexp (rx (or (seq "." (or "py"
"pth" "pyi" "pyw")) (seq "/" (or "SConstruct" "SConscript"))) eos))
  eval-buffer(#<buffer  *load*> nil
"~/dev-env/work-dev/emacs31.build/lisp/loaddefs.el" nil t)
  (if eval-function (funcall eval-function buffer (if dump-mode file
fullname)) (eval-buffer buffer nil (if dump-mode file fullname) nil
t))
  (let ((read-symbol-shorthands shorthands)) (if eval-function
(funcall eval-function buffer (if dump-mode file fullname))
(eval-buffer buffer nil (if dump-mode file fullname) nil t)))
  (let ((load-true-file-name fullname) (load-file-name fullname)
(set-auto-coding-for-load t) (inhibit-file-name-operation nil)
shorthands) (with-current-buffer buffer (set-buffer-multibyte t) (let
(deactivate-mark) (insert-file-contents fullname)) (setq shorthands
(and hack-read-symbol-shorthands-function (funcall
hack-read-symbol-shorthands-function))) (if (and
enable-multibyte-characters (or (eq (coding-system-type
last-coding-system-used) 'raw-text))) (set-buffer-multibyte nil))
(set-buffer-modified-p nil)) (let ((read-symbol-shorthands
shorthands)) (if eval-function (funcall eval-function buffer (if
dump-mode file fullname)) (eval-buffer buffer nil (if dump-mode file
fullname) nil t))))
  (unwind-protect (let ((load-true-file-name fullname) (load-file-name
fullname) (set-auto-coding-for-load t) (inhibit-file-name-operation
nil) shorthands) (with-current-buffer buffer (set-buffer-multibyte t)
(let (deactivate-mark) (insert-file-contents fullname)) (setq
shorthands (and hack-read-symbol-shorthands-function (funcall
hack-read-symbol-shorthands-function))) (if (and
enable-multibyte-characters (or (eq (coding-system-type
last-coding-system-used) 'raw-text))) (set-buffer-multibyte nil))
(set-buffer-modified-p nil)) (let ((read-symbol-shorthands
shorthands)) (if eval-function (funcall eval-function buffer (if
dump-mode file fullname)) (eval-buffer buffer nil (if dump-mode file
fullname) nil t)))) (let (kill-buffer-hook
kill-buffer-query-functions) (kill-buffer buffer)))
  (let ((buffer (generate-new-buffer " *load*")) (load-in-progress t)
(source (string-suffix-p ".el" fullname))) (unless nomessage (if
source (message "Loading %s (source)..." file) (message "Loading
%s..." file))) (when purify-flag (push (purecopy file)
preloaded-file-list)) (unwind-protect (let ((load-true-file-name
fullname) (load-file-name fullname) (set-auto-coding-for-load t)
(inhibit-file-name-operation nil) shorthands) (with-current-buffer
buffer (set-buffer-multibyte t) (let (deactivate-mark)
(insert-file-contents fullname)) (setq shorthands (and
hack-read-symbol-shorthands-function (funcall
hack-read-symbol-shorthands-function))) (if (and
enable-multibyte-characters (or (eq (coding-system-type
last-coding-system-used) 'raw-text))) (set-buffer-multibyte nil))
(set-buffer-modified-p nil)) (let ((read-symbol-shorthands
shorthands)) (if eval-function (funcall eval-function buffer (if
dump-mode file fullname)) (eval-buffer buffer nil (if dump-mode file
fullname) nil t)))) (let (kill-buffer-hook
kill-buffer-query-functions) (kill-buffer buffer)))
(do-after-load-evaluation fullname) (unless (or nomessage
noninteractive) (if source (message "Loading %s (source)...done" file)
(message "Loading %s...done" file))) t)
  (if (null (file-readable-p fullname)) (and (null noerror) (signal
'file-error (list "Cannot open load file" file))) (let ((buffer
(generate-new-buffer " *load*")) (load-in-progress t) (source
(string-suffix-p ".el" fullname))) (unless nomessage (if source
(message "Loading %s (source)..." file) (message "Loading %s..."
file))) (when purify-flag (push (purecopy file) preloaded-file-list))
(unwind-protect (let ((load-true-file-name fullname) (load-file-name
fullname) (set-auto-coding-for-load t) (inhibit-file-name-operation
nil) shorthands) (with-current-buffer buffer (set-buffer-multibyte t)
(let (deactivate-mark) (insert-file-contents fullname)) (setq
shorthands (and hack-read-symbol-shorthands-function (funcall
hack-read-symbol-shorthands-function))) (if (and
enable-multibyte-characters (or (eq (coding-system-type
last-coding-system-used) 'raw-text))) (set-buffer-multibyte nil))
(set-buffer-modified-p nil)) (let ((read-symbol-shorthands
shorthands)) (if eval-function (funcall eval-function buffer (if
dump-mode file fullname)) (eval-buffer buffer nil (if dump-mode file
fullname) nil t)))) (let (kill-buffer-hook
kill-buffer-query-functions) (kill-buffer buffer)))
(do-after-load-evaluation fullname) (unless (or nomessage
noninteractive) (if source (message "Loading %s (source)...done" file)
(message "Loading %s...done" file))) t))
  load-with-code-conversion("~/dev-env/work-dev/emacs31.build/lisp/loaddefs.el"
"~/dev-env/work-dev/emacs31.build/lisp/loaddefs.el" nil nil)
  load("loaddefs")
  (condition-case nil (load "loaddefs") (file-error (load "ldefs-boot.el")))
  load("loadup.el")
Symbol's function definition is void: rx
make[2]: *** [Makefile:1016: bootstrap-emacs.pdmp] Error 255
make[2]: Leaving directory '~/dev-env/work-dev/emacs31.build/src'
make[1]: *** [Makefile:554: src] Error 2
make[1]: Leaving directory '~/dev-env/work-dev/emacs31.build'
make[1]: Entering directory '~/dev-env/work-dev/emacs31.build'
***
*** "make all" failed with exit status 2.

Message #31 received at 73855 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lin Sun <sunlin7.mail <at> gmail.com>
Cc: 73855 <at> debbugs.gnu.org
Subject: Re: bug#73855: [BUG] Error: void-function (rx) during generating
 autoloads for python.el when building from source
Date: Wed, 13 Nov 2024 16:51:02 +0200

> From: Lin Sun <sunlin7.mail <at> gmail.com>
> Date: Wed, 13 Nov 2024 00:31:07 +0000
> 
> I met a compile issue while generating the autoloads.el from
> python.el, it seems the `python--auto-mode-alist-regexp` is defined
> with 'rx' but the 'rx' wasn't loaded.
> Should relate to the commit `2f485e68ff96cc66a17df2c0a58e272bbfc24765`
>     Add Python "*.pth" files to auto-mode-alist
>     * lisp/progmodes/python.el (python--auto-mode-alist-regexp): New
>     variable.
> 
> Here is the errors:

Thanks, but what is the recipe for reproducing this? just "make
bootstrap" or something else?

And in what branch?  Your bug report lacks any information about your
OS, Emacs configuration and version, and the build details.

Message #34 received at 73855 <at> debbugs.gnu.org (full text, mbox):

From: Lin Sun <sunlin7.mail <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73855 <at> debbugs.gnu.org
Subject: Re: bug#73855: [BUG] Error: void-function (rx) during generating
 autoloads for python.el when building from source
Date: Wed, 13 Nov 2024 17:13:14 +0000

On Wed, Nov 13, 2024 at 2:51 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > From: Lin Sun <sunlin7.mail <at> gmail.com>
> > Date: Wed, 13 Nov 2024 00:31:07 +0000
> > I met a compile issue while generating the autoloads.el from
> > python.el, it seems the `python--auto-mode-alist-regexp` is defined
> > with 'rx' but the 'rx' wasn't loaded.
> > Should relate to the commit `2f485e68ff96cc66a17df2c0a58e272bbfc24765`
> >     Add Python "*.pth" files to auto-mode-alist
> >     * lisp/progmodes/python.el (python--auto-mode-alist-regexp): New
> >     variable.
> >
> > Here is the errors:
>
> Thanks, but what is the recipe for reproducing this? just "make
> bootstrap" or something else?
>
> And in what branch?  Your bug report lacks any information about your
> OS, Emacs configuration and version, and the build details.
Hi Eli,
Thanks for replying, the error happened when I compiled the master
branch (a7400cb8810) on Ubuntu 20.04, clang-20, libgccjit-14.

I spent more than 1 hours to search what caused the issue on my local
but didn't find the root cause, clean up and rebuild didn't help, so I
posted the error messages to mail list for searching helping.
This morning I checked out the latest master branch and started a
fresh building and everything works perfectly.

The issue should be my local issue (maybe related to some environment
variables or dependent libraries). I'm still keeping my eyes on it,
and will investigate the root cause if it happens again.

Please close this ticket, thanks, appreciate it!

Message #37 received at 73855 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lin Sun <sunlin7.mail <at> gmail.com>,
 Stefan Kangas <stefankangas <at> gmail.com>
Cc: 73855 <at> debbugs.gnu.org
Subject: Re: bug#73855: [BUG] Error: void-function (rx) during generating
 autoloads for python.el when building from source
Date: Thu, 14 Nov 2024 09:39:18 +0200

> From: Lin Sun <sunlin7.mail <at> gmail.com>
> Date: Wed, 13 Nov 2024 17:13:14 +0000
> Cc: 73855 <at> debbugs.gnu.org
> 
> On Wed, Nov 13, 2024 at 2:51 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > > From: Lin Sun <sunlin7.mail <at> gmail.com>
> > > Date: Wed, 13 Nov 2024 00:31:07 +0000
> > > I met a compile issue while generating the autoloads.el from
> > > python.el, it seems the `python--auto-mode-alist-regexp` is defined
> > > with 'rx' but the 'rx' wasn't loaded.
> > > Should relate to the commit `2f485e68ff96cc66a17df2c0a58e272bbfc24765`
> > >     Add Python "*.pth" files to auto-mode-alist
> > >     * lisp/progmodes/python.el (python--auto-mode-alist-regexp): New
> > >     variable.
> > >
> > > Here is the errors:
> >
> > Thanks, but what is the recipe for reproducing this? just "make
> > bootstrap" or something else?
> >
> > And in what branch?  Your bug report lacks any information about your
> > OS, Emacs configuration and version, and the build details.
> Hi Eli,
> Thanks for replying, the error happened when I compiled the master
> branch (a7400cb8810) on Ubuntu 20.04, clang-20, libgccjit-14.
> 
> I spent more than 1 hours to search what caused the issue on my local
> but didn't find the root cause, clean up and rebuild didn't help, so I
> posted the error messages to mail list for searching helping.
> This morning I checked out the latest master branch and started a
> fresh building and everything works perfectly.
> 
> The issue should be my local issue (maybe related to some environment
> variables or dependent libraries). I'm still keeping my eyes on it,
> and will investigate the root cause if it happens again.
> 
> Please close this ticket, thanks, appreciate it!

Stefan, can you please take a look?  Should python.el require rx due
to this change?  If not, feel free to close.

Message #40 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andreas Röhler <andreas.roehler <at> easy-emacs.de>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#73855: [BUG] Error: void-function (rx) during generating
 autoloads for python.el when building from source
Date: Thu, 14 Nov 2024 10:35:03 +0100

python.el compiles nicely here from emacs -Q: GNU Emacs 31.0.50 (build 
1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.16.0) of 
2024-11-14

Am 14.11.24 um 08:39 schrieb Eli Zaretskii:
>> From: Lin Sun <sunlin7.mail <at> gmail.com>
>> Date: Wed, 13 Nov 2024 17:13:14 +0000
>> Cc: 73855 <at> debbugs.gnu.org
>>
>> On Wed, Nov 13, 2024 at 2:51 PM Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>> From: Lin Sun <sunlin7.mail <at> gmail.com>
>>>> Date: Wed, 13 Nov 2024 00:31:07 +0000
>>>> I met a compile issue while generating the autoloads.el from
>>>> python.el, it seems the `python--auto-mode-alist-regexp` is defined
>>>> with 'rx' but the 'rx' wasn't loaded.
>>>> Should relate to the commit `2f485e68ff96cc66a17df2c0a58e272bbfc24765`
>>>>      Add Python "*.pth" files to auto-mode-alist
>>>>      * lisp/progmodes/python.el (python--auto-mode-alist-regexp): New
>>>>      variable.
>>>>
>>>> Here is the errors:
>>> Thanks, but what is the recipe for reproducing this? just "make
>>> bootstrap" or something else?
>>>
>>> And in what branch?  Your bug report lacks any information about your
>>> OS, Emacs configuration and version, and the build details.
>> Hi Eli,
>> Thanks for replying, the error happened when I compiled the master
>> branch (a7400cb8810) on Ubuntu 20.04, clang-20, libgccjit-14.
>>
>> I spent more than 1 hours to search what caused the issue on my local
>> but didn't find the root cause, clean up and rebuild didn't help, so I
>> posted the error messages to mail list for searching helping.
>> This morning I checked out the latest master branch and started a
>> fresh building and everything works perfectly.
>>
>> The issue should be my local issue (maybe related to some environment
>> variables or dependent libraries). I'm still keeping my eyes on it,
>> and will investigate the root cause if it happens again.
>>
>> Please close this ticket, thanks, appreciate it!
> Stefan, can you please take a look?  Should python.el require rx due
> to this change?  If not, feel free to close.
>
>
>

Message #43 received at 73855-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Lin Sun <sunlin7.mail <at> gmail.com>
Cc: 73855-done <at> debbugs.gnu.org
Subject: Re: bug#73855: [BUG] Error: void-function (rx) during generating
 autoloads for python.el when building from source
Date: Sun, 17 Nov 2024 06:08:07 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Lin Sun <sunlin7.mail <at> gmail.com>
>> Date: Wed, 13 Nov 2024 17:13:14 +0000
>> Cc: 73855 <at> debbugs.gnu.org
>>
>> Thanks for replying, the error happened when I compiled the master
>> branch (a7400cb8810) on Ubuntu 20.04, clang-20, libgccjit-14.
>>
>> I spent more than 1 hours to search what caused the issue on my local
>> but didn't find the root cause, clean up and rebuild didn't help, so I
>> posted the error messages to mail list for searching helping.
>> This morning I checked out the latest master branch and started a
>> fresh building and everything works perfectly.
>>
>> The issue should be my local issue (maybe related to some environment
>> variables or dependent libraries). I'm still keeping my eyes on it,
>> and will investigate the root cause if it happens again.
>>
>> Please close this ticket, thanks, appreciate it!
>
> Stefan, can you please take a look?  Should python.el require rx due
> to this change?  If not, feel free to close.

I can't currently see that python.el should need to require rx due to
2f485e68ff96, no.  AFAICT, the `rx` macro is autoloaded, and the
defconst we put in loaddefs.el is then correctly converted to a string
in loaddefs.elc before dumping.  I also see that `(featurep 'rx)` is nil
in emacs -Q.  Finally, I can't reproduce the error in the OP, nor does
it seem like Lin Sun is able to.

So I'll close this bug for now.  Please reopen if this issue pops up
again and we can perhaps take a second look.

BTW, Lin Sun, please open a new bug report for any new issues in future.
Here, I can see that we used Bug#73855 for two different issues, which
makes it harder to track and follow the discussion.  Thanks!

Message #46 received at 73855-done <at> debbugs.gnu.org (full text, mbox):

From: Lin Sun <sunlin7.mail <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 73855-done <at> debbugs.gnu.org
Subject: Re: bug#73855: [BUG] Error: void-function (rx) during generating
 autoloads for python.el when building from source
Date: Sun, 17 Nov 2024 16:04:53 +0000

On Sun, Nov 17, 2024 at 2:08 PM Stefan Kangas <stefankangas <at> gmail.com> wrote:
> BTW, Lin Sun, please open a new bug report for any new issues in future.
> Here, I can see that we used Bug#73855 for two different issues, which
> makes it harder to track and follow the discussion.  Thanks!
Hi Stefan, that's my failure, will keep in my mind. Please close the
ticket. Thanks

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.