- 13 Feb, 2016 6 commits
-
-
Hung-Yi Chen authored
-
Hisham authored
-
Hisham authored
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.
-
https://github.com/hishamhm/htopHisham authored
-
Hisham authored
-
Hisham Muhammad authored
Suppress compiler warnings on FreeBSD
-
- 12 Feb, 2016 1 commit
-
-
Hung-Yi Chen authored
-
- 11 Feb, 2016 11 commits
-
-
Hisham Muhammad authored
Fix process memory on FreeBSD
-
Hisham authored
-
Hisham Muhammad authored
Add travis badge, update README
-
Tomas Barton authored
-
Tomas Barton authored
-
https://github.com/hishamhm/htopHisham authored
-
Tomas Barton authored
-
Tomas Barton authored
-
Greg V authored
-
Hisham Muhammad authored
Add FreeBSD battery support
-
Greg V authored
-
- 10 Feb, 2016 2 commits
- 03 Feb, 2016 2 commits
- 02 Feb, 2016 9 commits
- 31 Jan, 2016 3 commits
- 21 Jan, 2016 3 commits
-
-
Hisham Muhammad authored
GRAPH_HEIGHT macro and 'dot' variable
-
Explorer09 authored
(Cherry-picked from d56bcd8e, 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.
-
Explorer09 authored
(Cherry-picked from e93028d7, 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.
-
- 20 Jan, 2016 1 commit
-
-
Hisham Muhammad authored
Introduce CLAMP macro. Unify all MAX(l,MIN(h,x)) uses.
-
- 15 Jan, 2016 1 commit
-
-
Explorer09 authored
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--) .
-
- 13 Jan, 2016 1 commit
-
-
Hisham Muhammad authored
Darwin: replace vm_statistics64_* with vm_statistics_*
-