I just got the following error trying to run native-compiled time-to-days: Debugger entered--Lisp error: (wrong-number-of-arguments (lambda (&optional time) (funcall #<subr decode-time> (or time G167))) 3) (decode-time (22352 22528) nil nil) (time-to-days (22352 22528)) Re-evaluating defun of time-to-days fixes the error. Best, Ihor In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.16.0) of 2021-04-30 built on localhost Repository revision: fa65c044f2ebe666467166075c1507a8d0e1347f Repository branch: feature/native-comp Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Gentoo/Linux Configured using: 'configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-silent-rules --docdir=/usr/share/doc/emacs-28.0.9999 --htmldir=/usr/share/doc/emacs-28.0.9999/html --libdir=/usr/lib64 --program-suffix=-emacs-28-vcs --includedir=/usr/include/emacs-28-vcs --infodir=/usr/share/info/emacs-28-vcs --localstatedir=/var --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp --without-compress-install --without-hesiod --without-pop --with-file-notification=inotify --with-pdumper --enable-acl --with-dbus --with-modules --without-gameuser --with-libgmp --without-gpm --with-json --without-kerberos --without-kerberos5 --without-lcms2 --with-xml2 --without-mailutils --with-native-compilation --with-selinux --with-gnutls --without-libsystemd --with-threads --with-wide-int --with-zlib --with-sound=oss --with-x --without-ns --without-gconf --without-gsettings --without-toolkit-scroll-bars --with-gif --with-jpeg --with-png --with-rsvg --with-tiff --with-xpm --with-imagemagick --with-xft --with-cairo --with-harfbuzz --without-libotf --without-m17n-flt --with-x-toolkit=no --with-dumping=pdumper 'CFLAGS=-march=native -pipe -O2' CPPFLAGS= 'LDFLAGS=-Wl,-O1 -Wl,--as-needed'' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ IMAGEMAGICK JPEG JSON LIBSELINUX LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY OLDXMENU PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF X11 XDBE XIM XPM ZLIB Important settings: value of $LC_COLLATE: C value of $LANG: en_US.utf8 locale-coding-system: utf-8-unix Major mode: ELisp/l Memory information: ((conses 16 2803364 652253) (symbols 48 82982 8) (strings 32 394883 248801) (string-bytes 1 13653046) (vectors 16 187919) (vector-slots 8 4341859 573177) (floats 8 17548 3388) (intervals 56 124000 2648) (buffers 992 103))
> From: Ihor Radchenko <yantar92@gmail.com>
> Date: Sat, 01 May 2021 09:47:35 +0800
>
> I just got the following error trying to run native-compiled time-to-days:
>
> Debugger entered--Lisp error: (wrong-number-of-arguments (lambda (&optional time) (funcall #<subr decode-time> (or time G167))) 3)
> (decode-time (22352 22528) nil nil)
> (time-to-days (22352 22528))
I cannot reproduce this. When was your time-date.el
natively-compiled? What happens if you delete the .eln file and
recompile it?
Eli Zaretskii <eliz@gnu.org> writes: > I cannot reproduce this. When was your time-date.el > natively-compiled? It was compiled during emacs installation (I am on Gentoo): /usr/lib64/emacs/28.0.50/native-lisp/28.0.50-7ff4cc51: -rw-r--r--. 1 46K May 1 11:19 time-date-40951a48-0eafe94e.eln I am not sure if it is important, but the problem appears in one of org-mode tests. I just ran =make test= on current Org mode master. > What happens if you delete the .eln file and > recompile it? I deleted the file and restarted emacs -Q. The new eln file is in /home/yantar92/.emacs.d/eln-cache/28.0.50-7ff4cc51: -rwxr-xr-x. 1 59K May 1 14:58 time-date-40951a48-0eafe94e.eln The problem persist. I also tried to delete all the org eln files in my local .emacs.d as well as system-wide eln files generated during Emacs installation. It did not help. The full backtrace: decode-time((22352 22528) nil nil) time-to-days((22352 22528)) org-time-stamp-to-now("2016-06-03 Fri") org-deadline-close-p("2016-06-03 Fri" 0) apply(org-deadline-close-p ("2016-06-03 Fri" 0)) (setq value-13032 (apply fn-13030 args-13031)) (unwind-protect (setq value-13032 (apply fn-13030 args-13031)) (setq (if (unwind-protect (setq value-13032 (apply fn-13030 args-13031)) ( (let (form-description-13034) (if (unwind-protect (setq value-13032 (let ((value-13032 'ert-form-evaluation-aborted-13033)) (let (form-d (let* ((fn-13030 #'org-deadline-close-p) (args-13031 (condition-case (progn (org-mode) (let ((point (string-match "<point>" inside-text)) (unwind-protect (progn (org-mode) (let ((point (string-match "<point (save-current-buffer (set-buffer temp-buffer) (unwind-protect (progn (let ((temp-buffer (generate-new-buffer " *temp*" t))) (save-current (let ((inside-text (if (stringp "* Heading") "* Heading" (eval "* He (progn (fset 'time-subtract vnew) (fset 'time-less-p vnew) (fset 'ti (unwind-protect (progn (fset 'time-subtract vnew) (fset 'time-less-p (let* ((vnew #'(lambda nil G89)) (vnew #'(lambda (&optional time &re (let* ((G88 "2016-06-03 Fri 01:43") (G89 (if (stringp G88) (apply #' (lambda nil (let* ((G88 "2016-06-03 Fri 01:43") (G89 (if (stringp G8 ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test ert-run-test(#s(ert-test :name test-org/deadline-close-p :documentat ert-run-or-rerun-test(#s(ert--stats :selector "\\(org\\|ob\\)" :test ert-run-tests("\\(org\\|ob\\)" #f(compiled-function (event-type &res ert-run-tests-batch("\\(org\\|ob\\)") ert-run-tests-batch-and-exit("\\(org\\|ob\\)") (let ((org-id-track-globally t) (org-test-selector (if org-test-sele org-test-run-batch-tests("\\(org\\|ob\\)") command-line-1(("--eval" "(setq vc-handled-backends nil org-startup- command-line() normal-top-level() Best, Ihor
> From: Ihor Radchenko <yantar92@gmail.com>
> CC: 48133@debbugs.gnu.org
> Date: Sat, 01 May 2021 15:11:36 +0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I cannot reproduce this. When was your time-date.el
> > natively-compiled?
>
> It was compiled during emacs installation (I am on Gentoo):
>
> /usr/lib64/emacs/28.0.50/native-lisp/28.0.50-7ff4cc51:
> -rw-r--r--. 1 46K May 1 11:19 time-date-40951a48-0eafe94e.eln
>
> I am not sure if it is important, but the problem appears in one of
> org-mode tests. I just ran =make test= on current Org mode master.
So maybe the problem is not in time-date.el, maybe it's elsewhere?
Can you show the exact code of the test that fails and how to run it?
Eli Zaretskii <eliz@gnu.org> writes: > So maybe the problem is not in time-date.el, maybe it's elsewhere? > Can you show the exact code of the test that fails and how to run it? I run it by cloning Org mode repo from https://code.orgmode.org/bzg/org-mode.git and running =make test= The failing test is test-org/deadline-close-p failing at the first should assertion: (ert-deftest test-org/deadline-close-p () "Test `org-deadline-close-p' specifications." (org-test-at-time "2016-06-03 Fri 01:43" ;; Timestamps are close if they are within `ndays' of lead time. (org-test-with-temp-text "* Heading" (should (org-deadline-close-p "2016-06-03 Fri" 0)) (should (org-deadline-close-p "2016-06-02 Thu" 0)) (should-not (org-deadline-close-p "2016-06-04 Sat" 0)) (should (org-deadline-close-p "2016-06-04 Sat" 1)) (should (org-deadline-close-p "2016-06-03 Fri 12:00" 0))) ;; Read `ndays' from timestamp if argument not given. (org-test-with-temp-text "* H" (should (org-deadline-close-p "2016-06-04 Sat -1d")) (should-not (org-deadline-close-p "2016-06-04 Sat -0d")) (should (org-deadline-close-p "2016-06-10 Fri -1w")) (should-not (org-deadline-close-p "2016-06-11 Sat -1w"))) ;; Prefer `ndays' argument over lead time in timestamp. (org-test-with-temp-text "* H" (should (org-deadline-close-p "2016-06-04 Sat -0d" 1)) (should-not (org-deadline-close-p "2016-06-04 Sat -0d" 0))) ;; Completed tasks are never close. (let ((org-todo-keywords '(("TODO" "|" "DONE")))) (org-test-with-temp-text "* TODO Heading" (should (org-deadline-close-p "2016-06-03"))) (org-test-with-temp-text "* DONE Heading" (should-not (org-deadline-close-p "2016-06-03")))))) org-deadline-close-p code: (defun org-deadline-close-p (timestamp-string &optional ndays) "Is the time in TIMESTAMP-STRING close to the current date?" (setq ndays (or ndays (org-get-wdays timestamp-string))) (and (<= (org-time-stamp-to-now timestamp-string) ndays) (not (org-entry-is-done-p)))) org-time-stamp-to-now: (defun org-time-stamp-to-now (timestamp-string &optional seconds) "Difference between TIMESTAMP-STRING and now in days. If SECONDS is non-nil, return the difference in seconds." (let ((fdiff (if seconds #'float-time #'time-to-days))) (- (funcall fdiff (org-time-string-to-time timestamp-string)) (funcall fdiff nil))))
> From: Ihor Radchenko <yantar92@gmail.com>
> CC: 48133@debbugs.gnu.org
> Date: Sat, 01 May 2021 16:22:32 +0800
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > So maybe the problem is not in time-date.el, maybe it's elsewhere?
> > Can you show the exact code of the test that fails and how to run it?
>
> I run it by cloning Org mode repo from
> https://code.orgmode.org/bzg/org-mode.git
> and running =make test=
>
> The failing test is test-org/deadline-close-p failing at the first
> should assertion:
Thanks, I hope Andrea will be able to look into this soon.
Ihor Radchenko <yantar92@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> So maybe the problem is not in time-date.el, maybe it's elsewhere?
>> Can you show the exact code of the test that fails and how to run it?
>
> I run it by cloning Org mode repo from
> https://code.orgmode.org/bzg/org-mode.git
> and running =make test=
Just to confirm I can reproduce this. Will look into it.
Andrea
Ihor Radchenko <yantar92@gmail.com> writes: > I just got the following error trying to run native-compiled time-to-days: > > Debugger entered--Lisp error: (wrong-number-of-arguments (lambda (&optional time) (funcall #<subr decode-time> (or time G167))) 3) > (decode-time (22352 22528) nil nil) > (time-to-days (22352 22528)) > > Re-evaluating defun of time-to-days fixes the error. I'm just taking a stab in the dark here -- but it's really odd that it seems to say that the signature of `decode-time' is (&optional time) Is it possible that the test code is mocking/redefining `decode-time' with the wrong signature, or something along those lines? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Lars Ingebrigtsen <larsi@gnus.org> writes:
> I'm just taking a stab in the dark here -- but it's really odd that it
> seems to say that the signature of `decode-time' is
>
> (&optional time)
>
> Is it possible that the test code is mocking/redefining `decode-time'
> with the wrong signature, or something along those lines?
Yes, it is the case. `decode-time' is redefined via `cl-letf' form in
`org-test-at-time' macro in org-test.el:
((symbol-function 'decode-time)
(lambda (&optional time) (funcall ,(symbol-function 'decode-time)
(or time ,at))))
Hope it helps.
Best,
Ihor
Ihor Radchenko <yantar92@gmail.com> writes: > Yes, it is the case. `decode-time' is redefined via `cl-letf' form in > `org-test-at-time' macro in org-test.el: > > ((symbol-function 'decode-time) > (lambda (&optional time) (funcall ,(symbol-function 'decode-time) > (or time ,at)))) > > Hope it helps. Yes, indeed. :-) So this is a bug in the org test harness, I think? I've added Amin to the CCs. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Ihor Radchenko <yantar92@gmail.com> writes: > While I agree that it is a bug on Org mode side, I am also wondering how > to handle backward-compatibility with older Emacs versions in such cases. In this case, adding the additional optional arguments won't have an adverse effect in any Emacs version, I think? > Is there any way to know in which Emacs version the function argument > list was changed? You'd have to ask git. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Lars Ingebrigtsen <larsi@gnus.org> writes:
> Yes, indeed. :-) So this is a bug in the org test harness, I think?
> I've added Amin to the CCs.
While I agree that it is a bug on Org mode side, I am also wondering how
to handle backward-compatibility with older Emacs versions in such cases.
Is there any way to know in which Emacs version the function argument
list was changed?
Best,
Ihor
Lars Ingebrigtsen <larsi@gnus.org> writes: > In this case, adding the additional optional arguments won't have an > adverse effect in any Emacs version, I think? Sure. I was thinking about more dramatic changes in argument list. Think swapped args. >> Is there any way to know in which Emacs version the function argument >> list was changed? > > You'd have to ask git. Fair enough. Though I was hoping for something like "Probably introduced at or before Emacs version 19.29.", but for argument list. Or even incorporating git changelog for given function into the help buffer.
Ihor Radchenko <yantar92@gmail.com> writes: > Sure. I was thinking about more dramatic changes in argument list. Think > swapped args. I don't think we ever do things like that a lot. (If ever.) > Fair enough. Though I was hoping for something like "Probably introduced > at or before Emacs version 19.29.", but for argument list. Or even > incorporating git changelog for given function into the help buffer. No, it's just too much work. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
Ihor Radchenko <yantar92@gmail.com> writes: >> Yes, indeed. :-) So this is a bug in the org test harness, I think? > > Just letting know that it is now fixed on Org mode master. This bug > report can be closed. OK; closing. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no
> Yes, indeed. :-) So this is a bug in the org test harness, I think?
Just letting know that it is now fixed on Org mode master. This bug
report can be closed.