summaryrefslogtreecommitdiffhomepage
path: root/xmobar.cabal
AgeCommit message (Collapse)Author
2020-12-20Including new .org doc files in extra-source-filesjao
2020-11-29Add new plugin: NotmuchMailslotThe
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.
2020-11-19test: Fix flaky CpuSpecTomas Janousek
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.)
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-13bench: Clean up a bitTomas Janousek
2020-10-25Fix for broken DateZone monitorDino Morelli
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.
2020-10-10update libmpd to 0.9.2.0Olivier Schneider
2020-10-09Changelog and friendsjao
2020-08-07Changelog and unreleased version bumpjao
2020-06-26Drop support for GHC < 8.4 (fixes issue #461)0.35.1jao
2020-06-26Version bumpjao
2020-06-23Cleanup and add some testsSibi Prabakaran
2020-06-19Allow building with timezone-olson-0.2.0Peter Simons
Fixes https://github.com/jaor/xmobar/issues/463.
2020-06-13Version bump, changelog, readmejao
2020-06-13Initial support for benchmarks of the pluginsSibi Prabakaran
2020-06-12Updates for 0.340.34jao
Closes #457
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-04-27Base for ghc 8.10 (fixes #440)jao
2020-04-12Version bumpjao
2020-04-12Add a HandleReader PluginPavan Rikhi
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.
2020-04-12Require bytestring >= 0.10.8.2.Zev Weiss
Version 0.10.8.1 contains a bug in the readFile function that misbehaves on things like magic procfs files where stat(2) returns an st_size of zero, which breaks the Net monitor and such; 0.10.8.2 contains the fix.
2020-03-05Not exposing modules outside Xmobarjao
2020-02-26Version 0.330.33jao
2020-02-25Wireless: support NL80211 userspace <-> kernelspace APIPaul Fertser
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)
2020-02-23Timer coalescing: handle exceptions in timer coordination threadTomas Janousek
This corrects my (wrong) assumption that the timer coordination thread will only fail if there's an error in the code, and in that case any attempt to recover is futile. It turns out that the thread does fail recoverably in one notable case: when running in the non-threaded RTS, registerDelay fails immediately. And we probably still wish for xmobar to support the non-threaded RTS. One way to solve this issue is to add a bunch of #ifdefs and compile the code only in the threaded case. This would double the number of configurations that need to be tested, though. Instead, let's make the code robust against all kinds of exceptions in the timer coordination thread, and get non-threaded RTS support for free.
2020-02-22Implement timer coalescing (noticeably less CPU/power usage)Tomas Janousek
xmobar currently runs every monitor in its own thread. Monitors that do periodic updates simply sleep and loop. This unfortunately leads to these threads coming out of sync, and xmobar ends up waking up and redrawing for every periodic monitor. In my case, that is 7 times per second, which is enough for xmobar to be at the top of "top" with more than 1% CPU usage, and to have a noticeable impact on battery life. This commit adds a central timer coordination thread which makes sure that periodic updates happen together and that we only redraw once they're all done. Together with PR #409, I managed to lower the idle power draw of my laptop from 4W to 3W.
2020-01-27Revert "Use a single Manager across the whole application"jao
This reverts commit 1f1f0bd8b811740c84215f9ed4fa5ebd8309a990.
2020-01-27Revert "Only require http-conduit when absolutely necessary"jao
This reverts commit efb6d6817c092fe08e9b0f1b8a17bddd29d97cdb.
2020-01-16Only require http-conduit when absolutely necessaryslotThe
2020-01-16Use a single Manager across the whole applicationslotThe
2020-01-08Enable FreeBSD features implicitly from build platformDhananjay Balan
2020-01-06Support for freebsd battery status:Dhananjay Balan
Exposed via -f with_freebsd flag, uses sysctl to query battery status.
2019-10-15Changelog updatesjao
2019-10-15Allow latest GHCVanessa McHale
2019-10-10Credits and version bumpjao
2019-10-10libmpd 0.9.0.10jao
2019-08-23Version 0.300.30jao
2019-07-12fixed old CoreTemp in Monitors.hs, set up xmobar.cabal for MultiCoreTempFelix Springer
2019-02-07Always require http-conduit for weather (fixes #378)jao
2019-01-27Changelog for 0.29.5jao
2018-12-24Marks for 0.29.4jao
2018-12-24Upgrade to alsa-mixer 0.3.0 (cf. #372, #373)jao
2018-12-100.29.30.29.3jao
2018-12-10Set max version for alsa-mixerAndrzej Ressel
2018-12-080.29.20.29.2jao
2018-12-050.29.10.29.1jao
2018-12-03CoreCommon -> Common.Filesjao
2018-12-03Unit test fixesjao
2018-12-02Example xmobar.hsjao
2018-12-02Fix: exposing the Command constructors in libjao