* Timer errors in last few days (bignump change?)
@ 2018-09-05 17:54 Kaushal Modi
2018-09-05 18:39 ` Kaushal Modi
2018-09-05 22:34 ` Paul Eggert
0 siblings, 2 replies; 11+ messages in thread
From: Kaushal Modi @ 2018-09-05 17:54 UTC (permalink / raw)
To: Emacs developers
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
Hello,
I have been building Emacs regularly from the master branch.
In the last 2-3 days, this new error starts popping up frequently.
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
timer-next-integral-multiple-of-time((63065 20560) 60)
display-time-event-handler()
apply(display-time-event-handler nil)
timer-event-handler([t 23440 6080 0 60 display-time-event-handler nil nil
0])
timer-next-integral-multiple-of-time accepts TIME and SECS (integer) as
arguments, and the values (63065 20560) and 60 seem fine (or not?).
Before I dig deeper into debugging if some package went rogue, do you think
this number-or-marker-p error is related to bignump changes under the hood?
--
Kaushal Modi
[-- Attachment #2: Type: text/html, Size: 1008 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Timer errors in last few days (bignump change?)
2018-09-05 17:54 Timer errors in last few days (bignump change?) Kaushal Modi
@ 2018-09-05 18:39 ` Kaushal Modi
2018-09-05 18:43 ` Noam Postavsky
2018-09-05 18:45 ` Eli Zaretskii
2018-09-05 22:34 ` Paul Eggert
1 sibling, 2 replies; 11+ messages in thread
From: Kaushal Modi @ 2018-09-05 18:39 UTC (permalink / raw)
To: Emacs developers
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
When I try to do this:
M-: (apply #'encode-time (parse-time-string "2018-09-05"))
I get:
Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
encode-time(nil nil nil 5 9 2018 nil nil nil)
apply(encode-time (nil nil nil 5 9 2018 nil nil nil))
eval((apply #'encode-time (parse-time-string "2018-09-05")) t)
eval-expression((apply #'encode-time (parse-time-string "2018-09-05"))
nil nil 127)
funcall-interactively(eval-expression (apply #'encode-time
(parse-time-string "2018-09-05")) nil nil 127)
call-interactively(eval-expression nil nil)
command-execute(eval-expression)
On Wed, Sep 5, 2018 at 1:54 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:
> Hello,
>
> I have been building Emacs regularly from the master branch.
>
> In the last 2-3 days, this new error starts popping up frequently.
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
> timer-next-integral-multiple-of-time((63065 20560) 60)
> display-time-event-handler()
> apply(display-time-event-handler nil)
> timer-event-handler([t 23440 6080 0 60 display-time-event-handler nil
> nil 0])
>
> timer-next-integral-multiple-of-time accepts TIME and SECS (integer) as
> arguments, and the values (63065 20560) and 60 seem fine (or not?).
>
> Before I dig deeper into debugging if some package went rogue, do you
> think this number-or-marker-p error is related to bignump changes under the
> hood?
> --
>
> Kaushal Modi
>
--
Kaushal Modi
[-- Attachment #2: Type: text/html, Size: 2242 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Timer errors in last few days (bignump change?)
2018-09-05 18:39 ` Kaushal Modi
@ 2018-09-05 18:43 ` Noam Postavsky
2018-09-05 18:45 ` Eli Zaretskii
1 sibling, 0 replies; 11+ messages in thread
From: Noam Postavsky @ 2018-09-05 18:43 UTC (permalink / raw)
To: Kaushal Modi; +Cc: Emacs developers
On 5 September 2018 at 14:39, Kaushal Modi <kaushal.modi@gmail.com> wrote:
> When I try to do this:
>
> M-: (apply #'encode-time (parse-time-string "2018-09-05"))
>
> I get:
>
> Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
> encode-time(nil nil nil 5 9 2018 nil nil nil)
> apply(encode-time (nil nil nil 5 9 2018 nil nil nil))
> eval((apply #'encode-time (parse-time-string "2018-09-05")) t)
This looks similar to Bug#32443 (which nobody apart from OP is able to
replicate, so if you are able to, your feedback would be useful
there).
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Timer errors in last few days (bignump change?)
2018-09-05 18:39 ` Kaushal Modi
2018-09-05 18:43 ` Noam Postavsky
@ 2018-09-05 18:45 ` Eli Zaretskii
2018-09-05 18:49 ` Kaushal Modi
1 sibling, 1 reply; 11+ messages in thread
From: Eli Zaretskii @ 2018-09-05 18:45 UTC (permalink / raw)
To: Kaushal Modi; +Cc: emacs-devel
> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Wed, 5 Sep 2018 14:39:49 -0400
>
> When I try to do this:
>
> M-: (apply #'encode-time (parse-time-string "2018-09-05"))
>
> I get:
>
> Debugger entered--Lisp error: (wrong-type-argument fixnump nil)
> encode-time(nil nil nil 5 9 2018 nil nil nil)
> apply(encode-time (nil nil nil 5 9 2018 nil nil nil))
> eval((apply #'encode-time (parse-time-string "2018-09-05")) t)
> eval-expression((apply #'encode-time (parse-time-string "2018-09-05")) nil nil 127)
> funcall-interactively(eval-expression (apply #'encode-time (parse-time-string "2018-09-05")) nil nil 127)
> call-interactively(eval-expression nil nil)
> command-execute(eval-expression)
Are you saying that Emacs 26 doesn't signal a similar error in this
case? It does for me.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Timer errors in last few days (bignump change?)
2018-09-05 17:54 Timer errors in last few days (bignump change?) Kaushal Modi
2018-09-05 18:39 ` Kaushal Modi
@ 2018-09-05 22:34 ` Paul Eggert
2018-09-05 22:44 ` Kaushal Modi
1 sibling, 1 reply; 11+ messages in thread
From: Paul Eggert @ 2018-09-05 22:34 UTC (permalink / raw)
To: Kaushal Modi, Emacs developers
Kaushal Modi wrote:
> In the last 2-3 days, this new error starts popping up frequently.
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
> timer-next-integral-multiple-of-time((63065 20560) 60)
> display-time-event-handler()
> apply(display-time-event-handler nil)
> timer-event-handler([t 23440 6080 0 60 display-time-event-handler nil nil
> 0])
>
> timer-next-integral-multiple-of-time accepts TIME and SECS (integer) as
> arguments, and the values (63065 20560) and 60 seem fine (or not?).
I don't see how the first argument of timer-next-integral-multiple-of-time could
be (63065 20560). display-time-event-handler passes the value returned by
current-time, and that value is always a list of four integers. Is it possible
that you've redefined current-time, or redefined display-time-event-handler?
(63065 20560) corresponds to 2100-12-21 05:00:00 UTC, which is pretty far in the
future, and it seems unlikely you'd want to set alarms for that timestamp.
What platform are you running on? What is time_t on that platform, exactly? How
did you configure Emacs? Perhaps this is related to the year-2100 problems on
DOS and MS-Windows. I don't know much about those problems, though. See:
https://en.wikipedia.org/wiki/Time_formatting_and_storage_bugs#Year_2100
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Timer errors in last few days (bignump change?)
2018-09-05 22:34 ` Paul Eggert
@ 2018-09-05 22:44 ` Kaushal Modi
2018-09-05 22:55 ` Kaushal Modi
2018-09-05 23:28 ` Paul Eggert
0 siblings, 2 replies; 11+ messages in thread
From: Kaushal Modi @ 2018-09-05 22:44 UTC (permalink / raw)
To: Paul Eggert; +Cc: Emacs developers
[-- Attachment #1: Type: text/plain, Size: 486 bytes --]
On Wed, Sep 5, 2018, 6:34 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
> Kaushal Modi wrote:
>
> (63065 20560) corresponds to 2100-12-21 05:00:00 UTC, which is pretty far
> in the
> future, and it seems unlikely you'd want to set alarms for that timestamp.
>
Oh, thank you! I inadvertently played some "Back from the Future" while
hacking with a package test suite to fake the current-time.
Sorry for your wasted time. It was my mistake.. I redefined current-time.
> --
Kaushal Modi
[-- Attachment #2: Type: text/html, Size: 1021 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Timer errors in last few days (bignump change?)
2018-09-05 22:44 ` Kaushal Modi
@ 2018-09-05 22:55 ` Kaushal Modi
2018-09-05 23:28 ` Paul Eggert
1 sibling, 0 replies; 11+ messages in thread
From: Kaushal Modi @ 2018-09-05 22:55 UTC (permalink / raw)
To: Paul Eggert; +Cc: Emacs developers
[-- Attachment #1: Type: text/plain, Size: 907 bytes --]
On Wed, Sep 5, 2018 at 6:44 PM Kaushal Modi <kaushal.modi@gmail.com> wrote:
> On Wed, Sep 5, 2018, 6:34 PM Paul Eggert <eggert@cs.ucla.edu> wrote:
>
>> Kaushal Modi wrote:
>>
>> (63065 20560) corresponds to 2100-12-21 05:00:00 UTC, which is pretty far
>> in the
>> future, and it seems unlikely you'd want to set alarms for that timestamp.
>>
>
> Oh, thank you! I inadvertently played some "Back from the Future" while
> hacking with a package test suite to fake the current-time.
>
> Sorry for your wasted time. It was my mistake.. I redefined current-time.
>
>>
Though.. that value even though way in future is still valid, right? It
just happens that (encode-time 0 0 0 21 12 2100) returns that 2 element
time list.
Is the issue with:
- time list having 2 elements?
- year being 2100?
- Or the delta between that fake `current-time' and real current-time too
big?
I am on RHEL 6.8.
--
Kaushal Modi
[-- Attachment #2: Type: text/html, Size: 1856 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Timer errors in last few days (bignump change?)
2018-09-05 22:44 ` Kaushal Modi
2018-09-05 22:55 ` Kaushal Modi
@ 2018-09-05 23:28 ` Paul Eggert
1 sibling, 0 replies; 11+ messages in thread
From: Paul Eggert @ 2018-09-05 23:28 UTC (permalink / raw)
To: Kaushal Modi; +Cc: Emacs developers
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
Kaushal Modi wrote:
> Sorry for your wasted time. It was my mistake.. I redefined current-time.
No problem. In penance you might want to take a look at the attached, which
fixes a rounding error in that area that I noticed while looking into your report.
> hat value even though way in future is still valid, right?
Depends on the platform. It's not valid on platforms with 32-bit signed time_t;
it is valid on almost every other platform.
It
> just happens that (encode-time 0 0 0 21 12 2100) returns that 2 element
> time list.
Not if time_t is 32-bit signed.
> Is the issue with:
> - time list having 2 elements?
> - year being 2100?
> - Or the delta between that fake `current-time' and real current-time too
> big?
The issue is that encode-time returns a format that
timer-next-integral-multiple-of-time does not grok. I'm not sure it's worth
fixing this now, since we're about to change timestamp formats anyway and I'd
rather not be twiddling much with the old one (it'll still be supported blah
blah blah, I just don't want to be enhancing it).
[-- Attachment #2: 0001-Fix-timer.el-minor-rounding-error.patch --]
[-- Type: text/x-patch, Size: 2184 bytes --]
From 67475a59e95919e2dbe25ae950450578afdfd0dc Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@Penguin.CS.UCLA.EDU>
Date: Wed, 5 Sep 2018 16:19:47 -0700
Subject: [PATCH] Fix timer.el minor rounding error
* lisp/emacs-lisp/timer.el (timer-next-integral-multiple-of-time):
Fix rounding error by using integers rather than floats.
* test/lisp/emacs-lisp/timer-tests.el (timer-test-multiple-of-time):
New test.
---
lisp/emacs-lisp/timer.el | 10 +++++-----
test/lisp/emacs-lisp/timer-tests.el | 5 +++++
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/lisp/emacs-lisp/timer.el b/lisp/emacs-lisp/timer.el
index 795554fec5..74d37b0eae 100644
--- a/lisp/emacs-lisp/timer.el
+++ b/lisp/emacs-lisp/timer.el
@@ -102,14 +102,14 @@ timer-next-integral-multiple-of-time
"Yield the next value after TIME that is an integral multiple of SECS.
More precisely, the next value, after TIME, that is an integral multiple
of SECS seconds since the epoch. SECS may be a fraction."
- (let* ((trillion 1e12)
+ (let* ((trillion 1000000000000)
(time-sec (+ (nth 1 time)
- (* 65536.0 (nth 0 time))))
+ (* 65536 (nth 0 time))))
(delta-sec (mod (- time-sec) secs))
- (next-sec (+ time-sec (ffloor delta-sec)))
- (next-sec-psec (ffloor (* trillion (mod delta-sec 1))))
+ (next-sec (+ time-sec (floor delta-sec)))
+ (next-sec-psec (floor (* trillion (mod delta-sec 1))))
(sub-time-psec (+ (or (nth 3 time) 0)
- (* 1e6 (nth 2 time))))
+ (* 1000000 (nth 2 time))))
(psec-diff (- sub-time-psec next-sec-psec)))
(if (and (<= next-sec time-sec) (< 0 psec-diff))
(setq next-sec-psec (+ sub-time-psec
diff --git a/test/lisp/emacs-lisp/timer-tests.el b/test/lisp/emacs-lisp/timer-tests.el
index 65e5dc9bde..fa92c1b64a 100644
--- a/test/lisp/emacs-lisp/timer-tests.el
+++ b/test/lisp/emacs-lisp/timer-tests.el
@@ -39,4 +39,9 @@
(if (fboundp 'debug-timer-check)
(should (debug-timer-check)) t))
+(ert-deftest timer-test-multiple-of-time ()
+ (should (equal
+ (timer-next-integral-multiple-of-time '(0 0 0 1) (1+ (ash 1 53)))
+ (list (ash 1 (- 53 16)) 1 0 0))))
+
;;; timer-tests.el ends here
--
2.17.1
^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2018-09-05 23:28 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-09-05 17:54 Timer errors in last few days (bignump change?) Kaushal Modi
2018-09-05 18:39 ` Kaushal Modi
2018-09-05 18:43 ` Noam Postavsky
2018-09-05 18:45 ` Eli Zaretskii
2018-09-05 18:49 ` Kaushal Modi
2018-09-05 18:53 ` Kaushal Modi
2018-09-05 19:23 ` Eli Zaretskii
2018-09-05 22:34 ` Paul Eggert
2018-09-05 22:44 ` Kaushal Modi
2018-09-05 22:55 ` Kaushal Modi
2018-09-05 23:28 ` Paul Eggert
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.