| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Closes #208
|
|
Fixes #617
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Using this library allows us to receive swap info which is more
similar with result of command swapinfo.
|
|
In FreeBSD /proc/pid/stat is missing we should use for top procstat
library.
|
|
|
|
We should make better split os specify code for FreeBSD and Linux.
Idea comes from @liskin.
|
|
|
|
* A queue reader for xmobar using `TQueue a` from `stm`.
This is a flexible and performat solution for sharing
data between arbitrary haskell and xmobar.
* I am not sure if I did the haddocks correctly.
|
|
|
|
|
|
|
|
The existing support for the coretemp kernel driver only works with
Intel CPUs.
This commit extends support for temperature monitoring to AMD CPUs.
k10temp is a kernel driver for monitoring the temperature of AMD
processors. It supports everything from AMD's 10h (Opteron/Athlon)
family of processors to the latest 19h (Zen 3) family.
Reference: https://www.kernel.org/doc/html/latest/hwmon/k10temp.html
The meaning of the various temperatures made available has changed over
the years and only `Tctl` is available on processors prior to the 17h
family.
Labels for these temperatures are present but as Tctl and Tdie do not
contain a number I could not find a way to use these as
`checkedDataRetrieval` expects an integer label.
It is a PCI device and so an address needs to be supplied as part of the
configuration.
Example configuration:
`Run K10Temp "0000:00:18.3" ["--template", "T: <Tdie>C | <Tccd1>C"] 60`
|
|
|
|
Exposing Common.Types and Common.Run is now redundant, but we could
break configurations out there, so i'm not sure if we should remove them.
|
|
|
|
This plugin checks for new mail, provided that this mail is indexed by
notmuch. As mail that was tagged is moved from the new directory to
cur, the 'Mail' plugin (and its variants) won't work for such mail.
|
|
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.)
|
|
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>
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
