The last release of wmbiff included a patch by Nye Liu from Debian
bug #917467 [1]. However, the second part of that patch is not necessary.
From Andreas Metzler's comment
I am not sure about the second part of the patch. I understand wmbiff
breaking on GNUTLS_E_AGAIN from gnutls_read, because this only started
to happen recently (with TLS1.3) on blocking sockets.
What I do not get from my rudimentary understanding C programmimg is the
second part, this is in the else of "if (scs->tls_state)", so, afaiui for
non-encrypted connections. Is the change necessary there at all, is it
the right thing to retry read on EAGAIN then?
We revert the second part of the patch.
[1] https://bugs.debian.org/917467
After the introduction of MemAvailable in the kernel v3.14 one can
estimate how much RAM memory is being "used" by how much it is left
before the system starts swapping.
That is the reason why I want to monitor memory usage, to know
how close the system is to swapping. Therefore I propose to
use MemAvailable to compute the percentage of "used" memory.
Theoretically, after this patch a 100% memory usage is a more
accurate description of "yeah, we need to swap from now on".
See https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773
The reason is the same as in the analogous patch for wmwifi
in commit 1e34ea7f980; it improves considerably the efficiency.
Keeping the 'interval' unchanged (set to 1 sec), with this change
the number of wakeups as measured by powertop goes from around 14 wakeups/sec
to around 2 wakeup/sec.
Base the decision to display either the interface name or essid
on a time interval rather than how many times the update() function
is called. The time interval is chosen to be 2 seconds.
The old logic would swap the display after update() was called
50 times. If 'interval' between updates is a sane value around 1 second,
it would take 50 seconds to swap the name on display.
I noticed using powertop that the number of wakeups per second
generated by wmwifi did not correlate well with the update interval,
where I'd expect approximately 1 wakeup if the update interval was 1 sec.
Strangely enough, calling the function
dockapp_nextevent_or_timeout(&event, update_interval * 1000)
in the main loop (note that I already replaced * 100 by * 1000 above)
with update_interval = 1 generates around 15 wakeups/sec here.
Calling usleep() in the loop instead leads to fewer wakeups, around 1/sec.
Signed-off-by: Carlos R. Mafra <crmafra@gmail.com>
Running asmon in a new kernel (v4.19 here) did not display memory information
because the code checked whether the kernel was _exactly_ v2.6.
Although I could modify the check for > v2.6 I decided to drop support
for versions less than v2.6 (released in 2003).
- "Untitled window" appears in xfce4-wmdock-plugin's enumeration of
dockapps using libdockapp.
- Reference to string buffer that might not live long enough.
Often, the number currently being displayed has more than 10 digits.
However, when clearing the display, only the first 10 digits were cleared.
When a new number was entered, it would be prepended to any digits that
weren't cleared. This behavior was invisible to the user, causing
incorrect calculations, e.g., Debian bug #564173:
1814 / 720 * 300 -> 7568.41111
But the correct answer is 755.833333.
The problem was that when the display was cleared, the string that stores
this number was not null-terminated. Indeed, 1814 / 720 gives us
2.519444444 (6 4's), but only 2.51944444 (5 4's) is displayed. When we
begin to multiply by 300, the final 4 remained, and so we really were
multiplying by 3004.
