| Age | Commit message (Collapse) | Author |
|---|
|
While using xmobar to reproduce/fix a bug in xmonad I noticed that
xmobar doesn't react immediately to the signals to reposition or change
screen.
Apparently none of the Xlib functions called from `repositionWin` flush
the Xlib output buffer (XMoveResizeWindow is known to not flush,
although it's unfortunately not documented), so when compiled with the
threaded runtime that runs XNextEvent in a separate thread, the
reposition is sent to the X server only later when other stuff happens.
With all monitors set to refresh once a minute, this can take a looong
time.
(It's entirely possible this happens even without the threaded runtime,
I didn't test that, sorry.)
The fix is to call XSync at the end of `repositionWin`.
While at it, I spotted that drawInWin calls XSync with discard=true,
which seems like a mistake. We don't want to discard any events, do we?
(In practice, I'd expect the `eventer` thread to read all events even
before the drawing thread manages to discard them, so even if this
discarding XSync ever had any reason to be there, I don't think it does
anything meaningful these days. I may be wrong, though.)
|
|
This reverts commits c6669e26e1 (partially; changelog entry kept),
73e02934d6, 78efa5900a.
These commits were introduced as a workaround for a double UTF-8
encoding bug in xmonad-contrib which itself was meant to be a
fix/workaround for another issue. We have now identified the underlying
issue and fixed it right at the root, so this entire cascade of hacky
(and wrong) workarounds can be safely reverted. Thankfully, none of the
xmonad-contrib hacks made it into a release, so there's no backward
compat to worry about.
Should anyone be interested in the details,
https://github.com/xmonad/xmonad-contrib/commit/63e31ccd8d2865863778207b679f806941bf2788
provides a summary and links to all the related issues and PRs.
Related: https://github.com/jaor/xmobar/pull/482
Related: https://github.com/jaor/xmobar/issues/476
Related: https://github.com/xmonad/xmonad-contrib/commit/63e31ccd8d2865863778207b679f806941bf2788
Related: https://github.com/xmonad/xmonad-contrib/pull/471
Related: https://github.com/xmonad/xmonad-contrib/issues/377
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
By checking full paths, instead of just dirs (option 1).
|
|
|
|
|
|
|
|
Fixes #466
|
|
|
|
Closes #457
|
|
|
|
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. :-)
|
|
|
|
This adds a new `HandleReader` plugin, which displays data from a
Haskell `Handle`. This is really only useful if you are running xmobar
from within another Haskell program, but lets you avoid the mechanics of
creating a named pipe with the proper file permissions.
Instead, you can use `System.Process.createPipe` to make a pair of read
& write Handles. If you pass the read handle to HandleReader, you can
use hPutStr on the write Handle to send data to xmobar from your
application code.
|
|
|
|
NL80211 was introduced in Linux 2.6.24 in 2007 as a new extensible
universal API, replacing "wireless extensions" ioctls. It works on top
of netlink, and allows direct communication to cfg80211 kernel
subsystem. Since then it became a hard requirement for all upstream
wireless drivers to hook into cfg80211 (SoftMAC drivers do it via the
common mac80211 layer). There's still additional compatibility code that
allows limited Wext functionality for cfg80211 drivers but it's buggy
and can be disabled altogether when CONFIG_CFG80211_WEXT is not set.
This patch makes use of "netlink" Haskell library which doesn't have any
additional runtime dependencies (so neither iwlib nor libnl are
required). The operation is the same as performed by "iw dev <devname>
link" command.
The signal level is transformed to "quality" by first clamping it to
[-110; -40], then adding 110 and dividing by 70 (same meaningless
formula as used by the cfg80211 Wext compatibility layer).
"essid" template argument is replaced by more appropriate "ssid" (with
the old variant still available for backwards compatibility)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
