summaryrefslogtreecommitdiffhomepage
path: root/src
AgeCommit message (Collapse)Author
2020-11-24New monitor: MPDXjao
2020-11-19StdinReader: Remove throttling on exceptionTomas Janousek
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")
2020-11-19StdinReader: Improve exception handlingTomas Janousek
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
2020-11-15Fix crash on <fn=1>x</fn> when no additional fonts are specifiedTomas Janousek
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
2020-11-15Fix vertical centering of additional fontsTomas Janousek
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)")
2020-11-13Optimize Date plugin again (refresh timezone only once a minute)Tomas Janousek
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>
2020-11-02Revert "Optimize date plugin"ivanbrennan
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.
2020-10-09additionalFonts command-line option: --add-fontivanbrennan
Provide an option the user can specify any number of times to add to the additionalFonts config field.
2020-10-09hlintingjao
2020-08-09A bit of documentation for <box>jao
2020-08-09Update changelog and add commentSibi Prabakaran
2020-08-09Conditional encoding of xft stringSibi Prabakaran
2020-08-09Avoid double utf8 encodingSibi Prabakaran
With this change, xmobar should respect the data which it gets. Xmobar should just render the data instead of trying to encode it.
2020-08-08Mpris2: accepting Word32 as type for trackNumberjao
spotifyd is funky that way
2020-08-08Fix: don't go below zero in indexed barsjao
2020-08-07removed default arg of channel', channel (Plugins.Monitors.Volume)Keith
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.
2020-08-07fix non-exhaustive pattern warningUnoqwy
2020-08-07better parsing for boxes + add marginsUnoqwy
2020-08-07fix line width for boxesUnoqwy
2020-08-07make hlint happyUnoqwy
2020-08-07Fix 1px-off bordersUnoqwy
2020-08-07Add the <box> tag to set borders around textUnoqwy
2020-08-07Refactor ColorInfo to TextRenderInfoUnoqwy
ColorInfo contains background offsets, it is no longer only about colors TextRenderInfo can hold information such as color, offsets, etc
2020-08-07Allow font bg to be taller (or smaller)Unoqwy
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.
2020-08-07Redundant imports (mostly <$>) removedjao
2020-08-07Don't get confused by empty configuration dirs (fixes #313)jao
By checking full paths, instead of just dirs (option 1).
2020-08-07String index as progress barjao
2020-06-23Fix hlint warningsSibi Prabakaran
2020-06-23Update based on feedback on the PRSibi Prabakaran
2020-06-23Hlint fixesSibi Prabakaran
2020-06-23Some formatting of codeSibi Prabakaran
2020-06-23More cleanupSibi Prabakaran
2020-06-23Cleanup and add some testsSibi Prabakaran
2020-06-23Fix warningsSibi Prabakaran
2020-06-23Further optimizationSibi Prabakaran
2020-06-23More efficient formattingSibi Prabakaran
2020-06-23Optimize CPU monitorSibi Prabakaran
2020-06-23Add some optimizationSibi Prabakaran
2020-06-13Look up only the first coretemp.N/hwmon dir in MultiCoreTempjao
2020-06-13Version bump, changelog, readmejao
2020-06-13Detection of Tdie and Tctl for Ryzen temperaturesjao
2020-06-13Initial support for benchmarks of the pluginsSibi Prabakaran
2020-06-12Update UVWeather branchSibi Prabakaran
2020-06-12Optimize weather plugin by reusing manager and other refactorsSibi Prabakaran
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.
2020-06-05Optimize date pluginSibi Prabakaran
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. :-)
2020-05-19hlintingjao
2020-05-19Add EOF check before getLine operation from stdinSibi Prabakaran
Fixes https://github.com/jaor/xmobar/issues/442
2020-05-17Temporarily restore Stdin to its previous statejao
2020-05-11more hlintingjao
2020-05-11hlintingjao