Age | Commit message (Collapse) | Author |
|
|
|
Add MEM% for processes in process list on FreeBSD.
|
|
Issue noticed by GCC6 -Wmisleading-indentation.
Thanks @JIghtuse and @Explorer09!
Closes #409.
|
|
Simplify autogen.sh
|
|
|
|
Make use of the autoreconf tool
|
|
Got a report in #397 that htop runs in NetBSD
masquerading as Linux and using a compatibility /proc
(like we used to in FreeBSD) and that it builds fine
apart from this syscall.
|
|
(Thanks @coypoop at #397 for the heads up!)
|
|
|
|
|
|
htop currently expects m_size and m_resident in pages (Process.c).
According to the proc_info.h header, the values returned by libproc
are in bytes:
http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/sys/proc_info.h
Eventually we should change the htop crossplatform API to expect memory
in bytes, but this is the smaller change that should fix it.
Closes #385.
|
|
|
|
|
|
Suppress compiler warnings on FreeBSD
|
|
|
|
Fix process memory on FreeBSD
|
|
|
|
Add travis badge, update README
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add FreeBSD battery support
|
|
|
|
|
|
|
|
|
|
|
|
Fix by @Explorer09 (see discussion on #355).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GRAPH_HEIGHT macro and 'dot' variable
|
|
(Cherry-picked from d56bcd8e0d8d6a177fc2e40db32fc73ea4588684, the
experimental graph coloring branch)
The variable 'dot' in GraphMeterMode_draw now means "maximum number of
dots per value (column) in graph". The old meaning was "amount of value
that is to be represented by a dot" and was always a fraction. Due to
a limitation in floating point computing, if GRAPH_HEIGHT were not a
power of 2, then rounding errors will occur on numbers like (1.0/3).
(Currently GRAPH_HEIGHT is 4 and so no precision loss.) 'dot' was used
as a divisor, and it's "division by a reciprocal". We change that to
simple multiplication.
|
|
(Cherry-picked from e93028d7fa0c5f00b5dc3336fd28abaf905cd572, the
experimental graph coloring branch)
Currently GRAPH_HEIGHT=4 . This prevents hard-coding the height of the graph
meters, and allows user to change it at compile-time.
|
|
Introduce CLAMP macro. Unify all MAX(l,MIN(h,x)) uses.
|
|
With the CLAMP macro replacing the combination of MIN and MAX, we will
have at least two advantages:
1. It's more obvious semantically.
2. There are no more mixes of confusing uses like MIN(MAX(a,b),c) and
MAX(MIN(a,b),c) and MIN(a,MAX(b,c)) appearing everywhere. We unify
the 'clamping' with a single macro.
Note that the behavior of this CLAMP macro is different from
the combination `MAX(low,MIN(x,high))`.
* This CLAMP macro expands to two comparisons instead of three from
MAX and MIN combination. In theory, this makes the code slightly
smaller, in case that (low) or (high) or both are computed at
runtime, so that compilers cannot optimize them. (The third
comparison will matter if (low)>(high); see below.)
* CLAMP has a side effect, that if (low)>(high) it will produce weird
results. Unlike MIN & MAX which will force either (low) or (high) to
win. No assertion of ((low)<=(high)) is done in this macro, for now.
This CLAMP macro is implemented like described in glib
<http://developer.gnome.org/glib/stable/glib-Standard-Macros.html>
and does not handle weird uses like CLAMP(a++, low++, high--) .
|
|
Darwin: replace vm_statistics64_* with vm_statistics_*
|
|
Works with:
- Darwin 9.8.0 (OS X 10.5.8) PPC
- Darwin 15.2.0 (OS X 10.11.2) Intel
|
|
vi keys: translate ALT-h/j/k/l to arrow keys
|