| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ColorInfo contains background offsets, it is no longer only about colors
TextRenderInfo can hold information such as color, offsets, etc
|
|
Implemented only for XFT fonts.
Adds a new "part" in the fc tag.
> Example: <fc=white,gray:0>foo bar</fc> will make the font background
as tall as the bar (absolute offset, here set to 0 for both top &
bottom)
Changes ColorString to ColorInfo, containing both top and bottom
offsets. The "colors string" is still in only one string.
|
|
|
|
By checking full paths, instead of just dirs (option 1).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
As documented in the http-client library, calling newManager is an
expensive operation:
```
Creating a new Manager is a relatively expensive operation, you are
advised to share a single Manager between requests instead.
```
But inspite of the haddocks in xmobar claiming that once 'Manager' is
created, it will be used throughout the monitor is not true. Because for
every call of `startWeather` a new manager is being created.
Also I removed the option in WeatherOpts because even if it is false,
it will be ultimately created in `getData` function. Also without
using a manager - the plugin won't really work. So, I don't think
there is any reason for this option to exist.
I have introduced a new dependency http-client-tls to use the shared
global manager so that we reuse the same manager every time. This
simplifies a lot of code. Note that this is not really a new
dependency because http-conduit already depends on it transitively.
|
|
We avoid calling getTimeZone for each of the time the date has to be
updated. Instead, it's computed once at the start and re-used for each
invocation.
Looking at the implementation of 'getTimeZone', we can see that it's
very expensive:
https://www.stackage.org/haddock/lts-15.15/time-1.9.3/src/Data-Time-LocalTime-Internal-TimeZone.html#getTimeZone
It calls a C FFI each time to get the time
zone (getTimeZoneCTime). This is something which we can avoid and the
MR implements that.
I have been using my xmobar with this patch and the result has been
quite good. My xmobar CPU usage has used to hit 3~7%
intermittently. With this MR, It hits only 0.7% intermittently which
is nice. :-)
|
|
|
|
Fixes https://github.com/jaor/xmobar/issues/442
|
|
|
|
|
|
|
|
Right now, with the `StdinReader` plugin enabled - you can crash/cause
busy looping of xmobar if the following html file is opened:
```
<html>
<head>
<title>hello <fn=1>string</fn> </title>
</head>
</html>
```
More details about this bug is here:
https://github.com/jaor/xmobar/issues/442#issuecomment-625706001
This MR also fixes another bug which produces a crash in xmobar if you
pass non integer items between fn:
<fn=crash>
|
|
|
|
|
|
|
