| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Closes #457
|
|
|
|
|
|
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>
|
|
|
|
|
|
|
|
|
|
This specifically avoids situation described in this issue
https://github.com/jaor/xmobar/issues/438 where the handle was
throwing the IOException continously in a loop:
<stdin>: hGetLine: invalid argument (invalid byte sequence)
It happened because my system's environment was right, but the proper
behaviour hear would be to let it to throw the exception rather than
leading to a busy loop.
I did some git blame to find out that this commit introduced the
behaviour:
https://github.com/jaor/xmobar/commit/fc24dc1874dcf7c9e66e21502a58b40cbe627c85
but there was no reason mentioned in the commit for trying to capture
all exceptions.
|
|
|
|
|
|
hGetLineSafe is always hGetLine and hence we can directly use it.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
Use CPP macros to make the ALSA Spec file a no-op when the `with_alsa`
flag is set to False. Without these macros, HSpec will import the
AlsaSpec module causing test compilation to fail.
|
|
|
|
|
|
This makes the code hlint-clean for --cpp-define=USE_NL80211,
--cpp-define=IWLIB and without --cpp-define too.
|
|
|
|
|
|
|
|
|
|
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)
|
|
|
|
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.
|
|
The first implementation assumed all timers (monitors) are fast and
frequent (which happens to be the case in my configuration). This meant
that a single on-line weather monitor could block the entire xmobar
instance for a long time due to the refresh pausing (meant to reduce
power consumption).
This commit attempts to fix that by limiting the refresh pause time and
using the old periodic sleep method for these slow timers (monitors).
|
|
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.
|
|
A preparation for timer coalescing: tenthSeconds is just a sleep whereas
doEveryTenthSeconds enables using a central timer and waiting for all
monitors to update before refreshing the window. This commit is just a
simple refactor, the actual timer coalescing code comes later.
|
|
src/Xmobar/X11/Draw.hs:51:11-12: warning: [-Wunused-matches]
Defined but not used: ‘wr’
|
51 | drawInWin wr@(Rectangle _ _ wid ht) ~[left,center,right] = do
| ^^
src/Xmobar/App/EventLoop.hs:50:1-36: warning: [-Wunused-imports]
The import of ‘Xmobar.X11.Events’ is redundant
|
50 | import Xmobar.X11.Events(nextEvent')
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
The calculations are based on the assumption that current_now (or
power_now) are always positive. However, power_supply documentation in
the kernel sources say nothing about it, and so some drivers provide a
signed value (e.g. bq27xxx_battery_current).
Discovered and fixed on ac100/paz00 netbook.
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 1f1f0bd8b811740c84215f9ed4fa5ebd8309a990.
|
