| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Failed at least once in GitHub Actions:
predicate failed on: "Cpu: <fc=red>100</fc>% <fc=red>##########</fc>"
Also, there's no need to guard the Xmobar.Plugins.Monitors.CpuSpec
module with the with_alsa flag. (And it doesn't really work anyway,
hspec-discover doesn't care about what modules are declared in cabal, so
stack/ghc complains that "These modules are needed for compilation but
not listed in your .cabal file's other-modules:
Xmobar.Plugins.Monitors.AlsaSpec" and then fails to detect changes in
those modules.)
|
|
Introducing the throttling unfortunately has a negative side-effect: it
delays all stdin processing, including EOF detection, which can cause
confusion the previous commit tries to fix.
The only benefit of the throttling is to prevent 100% CPU usage when a
lot of garbage is provided on xmobar stdin. We still don't know where
that garbage comes from in https://github.com/jaor/xmobar/issues/438, or
rather why there's more than a handful of lines of such garbage. @psibi
has since fixed his setup to not produce that garbage, and no one else
ever reported such a problem, so it's probably safe to ignore it for
now.
Should anyone ever encounter that again, feel free to ping me, even in
the middle of the night, to help debug this.
Fixes: 7759df11f746 ("StdinReader: Improve exception handling")
Fixes: b7a3d6745817 ("Avoid busy looping by not catching all exceptions")
|
|
This corrects a misleading comment "EOF check is necessary for certain
systems" which was added without complete understanding of the root
cause of #442. That issue was in fact caused by old xmobars not being
terminated on early EOF, and is thus necessary on _all_ systems that
rely on EOF to terminate old xmobar before starting a new one. (To
trigger the bug, one additionally needs to close the xmobar pipe before
sending any input to it, which is unusual, but incorrectly configured
xmonad might trigger that.)
Furthermore, this fixes another execution path that could lead to xmobar
not being terminated on EOF:
`echo -e '\xff' | xmobar -c '[Run StdinReader]' -t '%StdinReader%'`
would terminate the StdinReader thread upon catching the "invalid
argument (invalid byte sequence)" so there'd be no thread to detect the
subsequent EOF and xmobar would get stuck.
Additionally, I believe that terminating either the thread or the entire
xmobar upon receiving a single miscoded byte isn't desirable, as this
might be an intermittent issue and another input line can be perfectly
okay. Therefore I suggest that the original issue @psibi was trying to
fix by b7a3d6745817 is worked around by introducing a throttling delay
instead of terminating the thread, as I assume that exceptions other
than async and EOF are recoverable.
Fixes: b7a3d6745817 ("Avoid busy looping by not catching all exceptions")
Fixes: 68ac4d3ae6f3 ("Update stderr and the bar on receiving exception")
Fixes: ed0663aac942 ("Add EOF check before getLine operation from stdin")
Fixes: https://github.com/jaor/xmobar/issues/442
Related: https://github.com/jaor/xmobar/pull/439
Related: https://github.com/jaor/xmobar/pull/448
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This fixes the following crash that happens with the default xmobar
configuration (using HOME=/ makes xmobar ignore ~/.xmobarrc):
$ echo "<fn=1>x</fn>" | HOME=/ xmobar
xmobar: Prelude.!!: index too large
Commit 3e9e1cb9d300 ("Fix crashes/busy looping happening via index")
meant to fix this but apparently it only fixed indexing of fontlist, not
voffs, so the crash was still there.
Fixes: https://github.com/jaor/xmobar/issues/504
|
|
The readme says additional fonts are centered vertically if a
corresponding offset isn't specified in `textOffsets`, but this didn't
happen as we used the first font's metrics for centering of all fonts
instead.
Fixes: a2365debfaba ("New configuration parameter `textOffsets` (fixes #311)")
|
|
|
|
This makes the Date plugin approximately twice as fast, and makes xmobar
up to about 5–10 % faster if Date is the only active plugin. (If more
expensive plugins like Network or MultiCpu are used, it doesn't make any
measurable difference.)
Micro-benchmark results on my HW:
Date Benchmarks/Date mean 2.833 μs ( +- 16.08 ns )
Date Benchmarks/DateZonedTime mean 5.020 μs ( +- 32.91 ns )
Date Benchmarks/DateWithTimeZone mean 2.827 μs ( +- 20.52 ns )
(DateZonedTime is the original implementation and DateWithTimeZone is
the implementation we had since 0.34 which never refreshes timezone.)
Real-life measurements (done overnight on an idle laptop, with all
measured xmobars running in parallel to ensure comparable conditions;
xmobars configured to only display date and with rate 10 — once per
second):
$ time timeout 6h xmobar .xmobarrc-DateZonedTime
real 360m0,010s
user 0m9,867s
sys 0m4,644s
(9.867 + 4.644) / (360 * 60) = 0.000672
$ time timeout 6h xmobar .xmobarrc-Date
real 360m0,008s
user 0m9,535s
sys 0m4,327s
(9.535 + 4.327) / (360 * 60) = 0.000642
$ time timeout 6h xmobar .xmobarrc-Date-10m
real 360m0,010s
user 0m9,780s
sys 0m4,215s
(9.780 + 4.215) / (360 * 60) = 0.000648
$ time timeout 6h xmobar .xmobarrc-DateWithTimeZone
real 360m0,006s
user 0m9,658s
sys 0m4,166s
(9.658 + 4.166) / (360 * 60) = 0.000640
(.xmobarrc-Date-10m is the proposed implementation, but with timezone
refresh every 10 minutes instead of every 1 minute)
Interpretation of these results:
* refreshing xmobar with just date takes around 650 μs
* that is xmobar with just date uses around 0.065 % of CPU time
* refreshing timezone takes additional cca 30 μs
When we only refresh timezone once a minute, these 30 μs become 0.5 μs
amortized, and that should be acceptable to even the most dedicated
perfectionist :-)
Fixes: a58e32f7c8af ("Revert "Optimize date plugin"")
Fixes: 878db3908060 ("Optimize date plugin")
Co-authored-by: Sibi Prabakaran <sibi@psibi.in>
|
|
|
|
A missing bit from a58e32f7c8af7b03410ab6693019cfc92c9cfca3.
|
|
This reverts commit 878db39080607ba476ba8d8f547ad28259efb6a9. That
commit optimized the date plugin by avoiding calling getTimeZone on each
execution, instead calling it just once upon startup and reusing that
zone. As a result, the time zone will not be updated dynamically, e.g.
when shifting in or out of daylight savings time.
I noticed this after my local time zone had shifted from EDT to EST. My
xmobar showed 4:30 when the local time was in fact 3:30 (and running
date on the command line confirmed that my system clock was actually
aware of this shift). I had to restart xmobar in order to pick up the
new time zone.
I repro'd the unexpected behavior by temporarily disabling my system's
time syncing, setting the time to 30 seconds before the zone shift,
running date to confirm I'd set the correct time, restarting xmobar, and
observing.
sudo systemctl stop systemd-timesyncd.service
date --set="01:59:30"
date
I observed my xmobar clock go from 1:59 to 2:00, rather than from 1:59
to 1:00 as expected.
Following the same steps, I was able to verify that this commit fixes
the issue.
|
|
There's a longstanding bug in timezone-olson that causes it to fail to
read some zoneinfo files (but not all, oddly). This was resolved in
timezone-olson-0.2.0 which can be built against by using a later
Stackage snapshot than master currently points to.
This fix pushes the snapshot up to lts-16.0 and also modifies the
cabal version range for timezone-olson to set 0.2.0 as the minimum.
|
|
- Relates to #491
|
|
|
|
|
|
|
|
Provide an option the user can specify any number of times to add to the
additionalFonts config field.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
With this change, xmobar should respect the data which it gets. Xmobar
should just render the data instead of trying to encode it.
|
|
spotifyd is funky that way
|
|
|
|
Both functions had a default parameter for use in some error cases. Now each accepts only one parameter (a
PerChannel), and return Nothing on an error.
The definition of 'channel' confused me, so I simplified it. Hopefully it's now
more clear that it just applies 'toInteger' to the 'IO (Maybe
CLong)' that 'channel'' returns.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
