| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
My laptop currently has rx/tx bytes in 10s of gigabytes and it's only
been up for 20 days. Normally it's several times more. At this point,
Float can only tell the difference of 4KB and up:
Prelude> let x = (50 * 2^30 :: Float) in (x + 2000) - x
0.0
Prelude> let x = (50 * 2^30 :: Float) in (x + 3000) - x
4096.0
This commit makes the Net monitor read Word64 which is exactly what the
kernel prints into /proc/net/dev [1] and converts to Float only after
subtracting the two numbers.
[1] https://github.com/torvalds/linux/blob/7a308bb3016f57e5be11a677d15b821536419d36/net/core/net-procfs.c#L82
Still, I think it's time to switch from Float to Double. At half-gigabit
speeds (easily attainable at home while rsyncing over a direct UTP cable
between two post-2010 laptops), Float can only tell the difference of
8 bytes and up (and I'm not even considering takeDigits!). That's
probably okay for a Net monitor in xmobar, but we're so close to the
limit it makes sense to move to Double just in case.
|
|
This is essentially commit a0397ad2 applied to MultiCpu.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
expandEnv takes a string and expands the environment variables it can
find. variable substringing (e.g. ${VAR:1} to lop off the first
character) is not supported, but $VAR and ${VAR} formats are, with the
former being delimited by punctuation, but not underscores.
|
|
Fixes #265.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
threadDelay is in microseconds, It is unnecessary to check pipe every millisecond
|
|
|
|
For instance, the following command can be used in the configuration
file:
Run Volume "default" "Capture" [] 10
|
|
|
|
|
|
Now that flags are watched as well, updates should be triggered on
option changes.
|
|
|
|
|
|
(yes, it's happening on an xps with kernel 4.1.5)
|
|
|
|
This patch adds a new optional plugin showing UV data for Australian
users. The data is aquired by simple HTTP request from the Australian
Radiation Protection and Nuclear Safety Agencies XML data feed.
The uvmeter plugin can be configured ovserving multiple different
station across the country. The alias now defaults to 'uv <stationid>'.
|
|
|
|
|
|
|
|
|
|
This reverts commit 1668793e69b7e7c78b7c5b4fd05a256c8ea9f0b1.
|
|
|
|
|
|
Wind data sometimes looks like this:
"Wind: Variable at 3 MPH (3 KT):0"
Note the missing direction info. This fix adds an additional
parser for this case to pWind.
|
|
|
|
Displays playback flags in the style of ncmpcpp.
|
|
Available memory is determined from meminfo's `MemAvailable:` on 3.14 and
newer, and falls back to `free + buffer + cache` on older systems.
Introduces new variables `<available{,ratio,bar,vbar,ipat}>`.
|
|
|
|
|
|
|
|
|
|
This commit does more fundamental rework of the "Locks" plug-in: now the
plug-in is fully event-driven and thus extremely power-efficient,
effectively zero CPU consumption while idling.
|
|
The extremely useful "Locks" plugin eats quite a lot of CPU (>2% here on a
old-ish laptop), unfortunately. The plug-in unnecessary reopens the
display, which is quite expensive operation. It results into 16 syscalls:
socket(PF_LOCAL) -> connect(sun_path=@"/tmp/.X11-unix/X0"})
-> getpeername() -> uname()
-> access(".Xauthority") -> open(".Xauthority")
-> fstat() -> mmap()
-> read() -> close()
-> munmap() -> getsockname()
-> fcntl(F_SETFD) -> fcntl(F_SETFL)
-> shutdown() -> close()
This is almost half of all the syscalls that we ought to execute for the
plug-in to work. Now, considering the useful work and that "Locks" runs
every 200 milliseconds, it gives us >300 syscalls (and a lot more
wake-ups) per second.
This commit fixes the reopening issue, effectively halving the CPU
consumption (down to ~1%). The patch also makes it easier to implement
event-driven indicators that will reduce the idle CPU consumption to 0.
|
|
* Batt
* Bright
* Cpu
* Disk
* MPD
* Mem
* MultiCpu
* Net
* Volume
* Wireless
|
