* bug#39099: 26.3; display-time delay after PC sleep
@ 2020-01-12 13:42 ynyaaa
2020-01-23 5:08 ` Stefan Kangas
0 siblings, 1 reply; 8+ messages in thread
From: ynyaaa @ 2020-01-12 13:42 UTC (permalink / raw)
To: 39099
Enabling display-time, the time string is updated every 0 second.
If PC is awaked after sleep, the update timing is changed.
In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
of 2019-08-29 built on CIRROCUMULUS
Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
Windowing system distributor 'Microsoft Corp.', version 6.3.9600
Recent messages:
Configured using:
'configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install 'CFLAGS=-O2 -static -g3''
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS THREADS LCMS2
Important settings:
value of $LANG: JPN
locale-coding-system: cp932
Major mode: Emacs-Lisp
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Load-path shadows:
None found.
Features:
(network-stream nsm starttls tls gnutls mailalias smtpmail auth-source
tabify pp shadow sort mail-extr emacsbug message rmc puny seq dired
dired-loaddefs format-spec rfc822 mml mml-sec password-cache epa derived
epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cus-edit
cus-start cus-load wid-edit pulse eieio-opt speedbar sb-image ezimage
dframe find-func thingatpt xref cl-seq project ring eieio eieio-core
cl-macs eieio-loaddefs misearch multi-isearch cl-extra help-fns
radix-tree cl-print byte-opt gv bytecomp byte-compile cconv debug
help-mode easymenu cl-loaddefs cl-lib elec-pair time-date mule-util
japan-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)
Memory information:
((conses 16 150681 39356)
(symbols 48 25665 2)
(miscs 40 237 564)
(strings 32 41690 1772)
(string-bytes 1 1070389)
(vectors 16 19392)
(vector-slots 8 695666 19450)
(floats 8 75 361)
(intervals 56 2449 198)
(buffers 992 23))
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#39099: 26.3; display-time delay after PC sleep
2020-01-12 13:42 bug#39099: 26.3; display-time delay after PC sleep ynyaaa
@ 2020-01-23 5:08 ` Stefan Kangas
2020-01-23 9:47 ` ynyaaa
0 siblings, 1 reply; 8+ messages in thread
From: Stefan Kangas @ 2020-01-23 5:08 UTC (permalink / raw)
To: ynyaaa; +Cc: 39099
ynyaaa@gmail.com writes:
> Enabling display-time, the time string is updated every 0 second.
> If PC is awaked after sleep, the update timing is changed.
>
> In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
> of 2019-08-29 built on CIRROCUMULUS
> Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
> Windowing system distributor 'Microsoft Corp.', version 6.3.9600
Do you see this when running under "emacs -Q"?
What is the value of the `display-time-format' variable?
Do you mean that it updates every second before sleep?
How often does it update after you awaken after sleep?
Best regards,
Stefan Kangas
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#39099: 26.3; display-time delay after PC sleep
2020-01-23 5:08 ` Stefan Kangas
@ 2020-01-23 9:47 ` ynyaaa
2020-01-23 14:39 ` Stefan Kangas
2021-08-30 1:40 ` Lars Ingebrigtsen
0 siblings, 2 replies; 8+ messages in thread
From: ynyaaa @ 2020-01-23 9:47 UTC (permalink / raw)
To: Stefan Kangas; +Cc: 39099
Stefan Kangas <stefan@marxist.se> writes:
> ynyaaa@gmail.com writes:
>
>> Enabling display-time, the time string is updated every 0 second.
>> If PC is awaked after sleep, the update timing is changed.
>>
>> In GNU Emacs 26.3 (build 1, x86_64-w64-mingw32)
>> of 2019-08-29 built on CIRROCUMULUS
>> Repository revision: 96dd0196c28bc36779584e47fffcca433c9309cd
>> Windowing system distributor 'Microsoft Corp.', version 6.3.9600
>
> Do you see this when running under "emacs -Q"?
>
> What is the value of the `display-time-format' variable?
>
> Do you mean that it updates every second before sleep?
>
> How often does it update after you awaken after sleep?
>
> Best regards,
> Stefan Kangas
I tested following operations and got log.
Start emacs -Q
Setup logging
(setq display-time-hook
(lambda ()
(with-current-buffer (get-buffer-create "display time log")
(goto-char (point-max))
(insert (current-time-string now) ?\n))))
M-x display-time (16:01)
Wait for a while.
Sleep PC. (16:10)
Wait for a while.
Wake up PC. (16:29)
Wait for a while.
M-x display-time (16:36)
Explicitly calling display-time restarts display-time-timer.
Following lines are the contents of "display time log" buffer.
Thu Jan 23 16:01:03 2020
Thu Jan 23 16:02:00 2020
Thu Jan 23 16:03:00 2020
Thu Jan 23 16:04:00 2020
Thu Jan 23 16:05:00 2020
Thu Jan 23 16:06:00 2020
Thu Jan 23 16:07:00 2020
Thu Jan 23 16:08:00 2020
Thu Jan 23 16:09:00 2020
Thu Jan 23 16:10:00 2020
Thu Jan 23 16:29:43 2020
Thu Jan 23 16:29:43 2020
Thu Jan 23 16:30:43 2020
Thu Jan 23 16:31:43 2020
Thu Jan 23 16:32:43 2020
Thu Jan 23 16:33:43 2020
Thu Jan 23 16:34:43 2020
Thu Jan 23 16:35:43 2020
Thu Jan 23 16:36:43 2020
Thu Jan 23 16:36:59 2020
Thu Jan 23 16:37:00 2020
Thu Jan 23 16:38:00 2020
Thu Jan 23 16:39:00 2020
Thu Jan 23 16:40:00 2020
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#39099: 26.3; display-time delay after PC sleep
2020-01-23 9:47 ` ynyaaa
@ 2020-01-23 14:39 ` Stefan Kangas
2020-01-23 18:11 ` Eli Zaretskii
2021-08-30 1:40 ` Lars Ingebrigtsen
1 sibling, 1 reply; 8+ messages in thread
From: Stefan Kangas @ 2020-01-23 14:39 UTC (permalink / raw)
To: ynyaaa; +Cc: 39099
ynyaaa@gmail.com writes:
> I tested following operations and got log.
I don't have access to a Windows machine so I'll leave investigating
this further to someone else. Thanks for provididing those details.
Best regards,
Stefan Kangas
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#39099: 26.3; display-time delay after PC sleep
2020-01-23 14:39 ` Stefan Kangas
@ 2020-01-23 18:11 ` Eli Zaretskii
0 siblings, 0 replies; 8+ messages in thread
From: Eli Zaretskii @ 2020-01-23 18:11 UTC (permalink / raw)
To: Stefan Kangas; +Cc: ynyaaa, 39099
> From: Stefan Kangas <stefan@marxist.se>
> Date: Thu, 23 Jan 2020 15:39:33 +0100
> Cc: 39099@debbugs.gnu.org
>
> I don't have access to a Windows machine so I'll leave investigating
> this further to someone else.
I don't think this is specific to Windows. The underlying problem
here is that our timers are interval timers: the next time a timer
fires is set by adding the interval to the time it fires now. So if
Emacs doesn't get CPU for a long time, it will start counting time
from the first moment it gets CPU again.
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#39099: 26.3; display-time delay after PC sleep
2020-01-23 9:47 ` ynyaaa
2020-01-23 14:39 ` Stefan Kangas
@ 2021-08-30 1:40 ` Lars Ingebrigtsen
2021-08-30 1:46 ` Lars Ingebrigtsen
1 sibling, 1 reply; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-30 1:40 UTC (permalink / raw)
To: ynyaaa; +Cc: Stefan Kangas, 39099
ynyaaa@gmail.com writes:
> Explicitly calling display-time restarts display-time-timer.
> Following lines are the contents of "display time log" buffer.
>
> Thu Jan 23 16:01:03 2020
> Thu Jan 23 16:02:00 2020
> Thu Jan 23 16:03:00 2020
> Thu Jan 23 16:04:00 2020
Right, because it's doing
(run-at-time t 60 ...)
which means that we should only run at each integral multiple of 60.
> Thu Jan 23 16:29:43 2020
> Thu Jan 23 16:29:43 2020
> Thu Jan 23 16:30:43 2020
> Thu Jan 23 16:31:43 2020
But then after sleeping, we're still running every 60 seconds -- but
it's not running on integral multiples?
Eli Zaretskii <eliz@gnu.org> writes:
> I don't think this is specific to Windows. The underlying problem
> here is that our timers are interval timers: the next time a timer
> fires is set by adding the interval to the time it fires now. So if
> Emacs doesn't get CPU for a long time, it will start counting time
> from the first moment it gets CPU again.
It sounds like something else is going on here. It's adding 60 seconds
correctly -- but not computing the integral multiples correctly... So
it sounds like somehow `timer-next-integral-multiple-of-time' is
computing things incorrectly after sleeping?
I had a look at the function, and I couldn't see anything obviously
wrong with it.
Here's a test case:
(format-time-string "%H:%M:%S"
(timer-next-integral-multiple-of-time (current-time) 60))
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#39099: 26.3; display-time delay after PC sleep
2021-08-30 1:40 ` Lars Ingebrigtsen
@ 2021-08-30 1:46 ` Lars Ingebrigtsen
2021-08-31 1:05 ` Lars Ingebrigtsen
0 siblings, 1 reply; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-30 1:46 UTC (permalink / raw)
To: ynyaaa; +Cc: Stefan Kangas, 39099
Lars Ingebrigtsen <larsi@gnus.org> writes:
> I had a look at the function, and I couldn't see anything obviously
> wrong with it.
Ah, no -- I misread the timer code. It's only computing the first
repeat length (to get us to the integral multiple), but after that, it
doesn't recompute how long it should be to the next. So if we sleep for
103 second, then we'll fire immediately upon waking up, and then fire
every 60 seconds after that.
So to get this right, the timer machinery would have to recompute the
repeat to bring us back to the integral multiple...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 8+ messages in thread
* bug#39099: 26.3; display-time delay after PC sleep
2021-08-30 1:46 ` Lars Ingebrigtsen
@ 2021-08-31 1:05 ` Lars Ingebrigtsen
0 siblings, 0 replies; 8+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-31 1:05 UTC (permalink / raw)
To: ynyaaa; +Cc: Stefan Kangas, 39099
Lars Ingebrigtsen <larsi@gnus.org> writes:
> So to get this right, the timer machinery would have to recompute the
> repeat to bring us back to the integral multiple...
This is now fixed in Emacs 28, and I added an essay to NEWS to try to
explain what the slightly incompatible change entails.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-08-31 1:05 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-12 13:42 bug#39099: 26.3; display-time delay after PC sleep ynyaaa
2020-01-23 5:08 ` Stefan Kangas
2020-01-23 9:47 ` ynyaaa
2020-01-23 14:39 ` Stefan Kangas
2020-01-23 18:11 ` Eli Zaretskii
2021-08-30 1:40 ` Lars Ingebrigtsen
2021-08-30 1:46 ` Lars Ingebrigtsen
2021-08-31 1:05 ` Lars Ingebrigtsen
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).