Closed follow39 closed 6 months ago
Same here. When it happens, the process is spinning with 100% CPU utlization.
Hey thanks for reporting, unfortunatelly I'm tend to get behind maintaining circadian.el. If one of you feels keen enough to debug this, it would be highly appreciated.
Mine didn't freeze, but Emacs was super-slow for a while.
I caught the reason with a profiler (so nice to have the profiler on a hotkey!): 57% CPU on timer-event-handler
calling circadian-activate-latest-theme
. Repeatedly, I assume.
When Emacs was snappy again, I noted the time was 18:01. So perhaps it keeps running for the whole minute?
Test specifying the time as 18:00:00 instead of just 18:00.
I found something interesting, it seems that Emacs' run-at-time
function, passed "18:00" will run right away even if it is now 18:00:59!
That may or may not be related.
If it is, the source of the error must be that circadian is re-scheduling the same theme until the clock is definitely greater. I propose changing the little <=
inside circadian-a-earlier-b-p
to a <
. I haven't tested if that makes a difference yet. I don't always get the bug in the first place, so it'd be good if someone else can say if it makes a difference.
same here. It's cause huge issue in CPU usage on windows.
Hey thanks for reporting, unfortunatelly I'm tend to get behind maintaining circadian.el. If one of you feels keen enough to debug this, it would be highly appreciated.
If you haven't been able to maintain the package, would you mind if I step up as a maintainer? I've been using this package for almost more than an year and would rather not let this die.
@divyaranjan1905 happy to accept pull requests or even simple findings here in the ticket. I'm just updating my Windows Emacs to 29.3 now and will test a bit + see how it behaves on my Macbook.
I found something interesting, it seems that Emacs'
run-at-time
function, passed "18:00" will run right away even if it is now 18:00:59!That may or may not be related.
If it is, the source of the error must be that circadian is re-scheduling the same theme until the clock is definitely greater. I propose changing the little
<=
insidecircadian-a-earlier-b-p
to a<
. I haven't tested if that makes a difference yet. I don't always get the bug in the first place, so it'd be good if someone else can say if it makes a difference.
Ok changing this to <
only here https://github.com/guidoschmidt/circadian.el/blob/06f3cda8bc934c4806f403d628c169a94a8bed31/circadian.el#L105 let the tests fail, so that's clearly not the right thing unfortunatelly.
I also couldn't yet reproduce high CPU usage on my macOS system 😢 ... I think we first need to find a reliable way to reproduce this bug (+ which Emacs version on which OS)
Indeed it looks like circadian-activate-latest-theme
is running for a whole minute. A simple print
statement illustrates it 95e934fce4af7042e00c5c04f2da7c76d20ce6f4 quite easily.
Your last release reintroduced the freeze with Emacs 29.3. Other than using a kill command, nothing is possible via Emacs mini buffer. There is a continues update about the next run time in the minibuffer making it unusable.
It does not freeze for me. Emacs 30.0.50. Although it does complain about calendar-latitude and longitude, even though my circadian-themes
sets the times explicitly, so I set latitude and longitude too.
Hello! I have a problem - Emacs is completely freezed while swithing process. Theme is swithed but Emacs doesn't respond at all.
Related config:
Full config