| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
All uses of meter drawing "mode" numbers now have the type
`MeterModeId`, including the uses in structures and arrays.
`MeterModeId` is defined as `unsigned int`, as (currently) it doesn't
save any code size by defining it to any smaller type.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
|
|
|
|
|
| |
This is a prerequisite to using MeterModeId type in more headers, to
avoid header dependency hell.
|
|
|
|
|
|
|
|
|
|
|
| |
All client codes that access this global `Meter_modes` array have been
replaced in previous commits, thus it's no longer necessary to keep
this internal information (draw functions, default heights, etc.)
public. It was also a bad idea when the client codes need to avoid
accessing `Meter_modes[0]` (which is reserved and contains null
information) by themselves.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
|
|
|
|
| |
Meter mode ID 0 will now be reserved.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The use of CUSTOM_METERMODE value in meter default mode was a bad
design. There are no meter that really has a "custom" mode to work with
and currently that value serves as a useless placeholder that hides the
real default mode for a meter.
Replace CUSTOM_METERMODE in `defaultMode` of all meters with the real
intended default modes. Currently only CPU meters and MemorySwapMeter
used this, and their real defaults are BAR_METERMODE.
In Meter_setMode(), remove the special treatment of `defaultMode ==
CUSTOM_METERMODE`, Meter_setMode() still calls the `updateMode` function
for custom treatment when it's present for a meter class.
As CUSTOM_METERMODE is obsolete from `defaultMode`, the init functions
of CPU meters and MemorySwapMeter need to be adjusted to avoid
incomplete initialization (Meter.draw function bring NULL).
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Meter_humanUnit() is often called with floating point values in
Meter objects, rewrite the function to let it process `double` type
natively, and save floating point to integer casts.
The rewritten function:
* Allows higher orders of magnitude including 'R' and 'Q', and
addresses infinity. (The previous version has a maximum value of
(2^64 - 1) representing 16 ZiB.)
* Rounds values when they are in intervals (99.9, 100) and (9.99, 10),
and displays them with correct precision (number of fraction digits).
* Produces assertion error on negative and NaN values (undefined
behavior).
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
|
|
|
|
| |
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
|
|
|
|
|
|
|
|
|
| |
On wide screens the previous value of 256 could end up insufficient to
cover the screen space allocated to the graph, leaving it awkwardly
truncated mid-column. We now allocate the buffer dynamically instead,
growing it to accommodate whatever width the graph occupies.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The 'comprisedValues' boolean property unnecessarily complicates the
drawing algorithms of Bar meters and Graph meters. Since the only user
of 'comprisedValues' is ZramMeter, it is better to rework the meter so
that it no longer needs 'comprisedValues'.
The 'values[ZRAM_METER_UNCOMPRESSED]' now stores the difference between
uncompressed and compressed data size.
Signed-off-by: Kang-Che Sung <explorer09@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
First stage in sanitizing the process list structure so that htop
can support other types of lists too (cgroups, filesystems, ...),
in the not-too-distant future.
This introduces struct Machine for system-wide information while
keeping process-list information in ProcessList (now much less).
Next step is to propogate this separation into each platform, to
match these core changes.
|
|
|
|
|
| |
Useful for bar mode if latter values of the meter comprise previous
ones.
|
|
|
|
|
|
|
|
|
| |
Show a non highlighted string at the start of htop, not the failure
text.
Also the original fix only handled the text mode, not the bar mode.
Improves: 2977414d ("Discard stale information from DiskIO and NetworkIO meters")
Related: #860
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Extending to right neighbors is intended for text meters with an
overlong content, so the whole text is shown if possible.
Multi column meters, like the combined memory and swap meter, position
its text depending on the given total width; keep the position to the
original assigned header slot.
Short term resolution for #796
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several improvements to the way values are displayed in the
PCP platform DynamicMeter implementation:
- handle the initial 'caption' setting as with regular meters,
this required a new meter callback because we no longer have
just a single meter caption for the DynamicMeter case
- if no label is provided for a metric in a configuration file
use the short form metric name as a fallback
- honour the suffix setting in the configuration file
- convert metric values to the canonical units for htop (kbyte
and seconds), and use Meter_humanUnit when it makes sense to
do so.
Also improves the handling of fatal string error messages in a
couple of places, thanks to BenBE for the review feedback.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is based on exploratory work by Sohaib Mohamed.
The end goal is two-fold - to support addition of Meters we
build via configuration files for both the PCP platform and
for scripts ( https://github.com/htop-dev/htop/issues/526 )
Here, we focus on generic code and the PCP support. A new
class DynamicMeter is introduced - it uses the special case
'param' field handling that previously was used only by the
CPUMeter, such that every runtime-configured Meter is given
a unique identifier. Unlike with the CPUMeter this is used
internally only. When reading/writing to htoprc instead of
CPU(N) - where N is an integer param (CPU number) - we use
the string name for each meter. For example, if we have a
configuration for a DynamicMeter for some Redis metrics, we
might read and write "Dynamic(redis)". This identifier is
subsequently matched (back) up to the configuration file so
we're able to re-create arbitrary user configurations.
The PCP platform configuration file format is fairly simple.
We expand configs from several directories, including the
users homedir alongside htoprc (below htop/meters/) and also
/etc/pcp/htop/meters. The format will be described via a
new pcp-htop(5) man page, but its basically ini-style and
each Meter has one or more metric expressions associated, as
well as specifications for labels, color and so on via a dot
separated notation for individual metrics within the Meter.
A few initial sample configuration files are provided below
./pcp/meters that give the general idea. The PCP "derived"
metric specification - see pmRegisterDerived(3) - is used
as the syntax for specifying metrics in PCP DynamicMeters.
|
| |
|
| |
|
| |
|
|
|
|
| |
Closes: #484
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Change the color and total based on the actual 1min load value:
< 1 : green and total of 1.0
< cpu-count : yellow and total of cpu-count
else : red and total of 2*cpu-count
Closes: #32
|
|
|
|
|
|
| |
to bar buffers
Closes: #294
|
|
|
|
| |
Most of the time the parameter is passed to snprintf type functions
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- allow count out-parameter of String_split() to be NULL
- introduce xStrndup()
- do not allow NULL pointers passed to String_eq()
it is not used in any code
- implement String_startsWith(), String_contains_i() and String_eq()
as inline header functions
- adjust several conversion issues
|
|
|
|
| |
Information as seen by IWYU 0.12 + clang 9 on Linux
|
|
|
|
|
|
|
| |
E.g. if the HT/SMT mode changes
Use separate data for sub-meters
Do not reuse drawData for maintainability
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR htop-dev/htop#70 got rid of the infrastructure for generating header
files, but it left behind some code duplication.
Some of cases are things that belong in the header file and don't need
to be repeated in the C file. Other cases are things that belong in the
C file and don't need to be in the header file.
In this commit I tried to fix all of these that I could find. When given
a choice I preferred keeping things out of the header file, unless they
were being used by someone else.
|
|
|
|
|
|
|
|
| |
The MIN, MAX, CLAMP, MINIMUM, and MAXIMUM macros appear
throughout the codebase with many re-definitions. Make
a single copy of each in a common header file, and use
the BSD variants of MINIMUM/MAXIMUM due to conflicts in
the system <sys/param.h> headers.
|
|
|
|
|
| |
Remove leftover empty ifdef/endif pairs, whitespace.
The generated htop.h file was also unused - removed.
|
|
|
|
|
|
|
|
| |
Applied via:
$ find * -name '*.h' -exec sed -i -r 's/^extern (.+\()/\1/;' {} +
Suggested-by: Bert Wesarg <bert.wesarg@googlemail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reasoning:
- implementation was unsound -- broke down when I added a fairly
basic macro definition expanding to a struct initializer in a *.c
file.
- made it way too easy (e.g. via otherwise totally innocuous git
commands) to end up with timestamps such that it always ran
MakeHeader.py but never used its output, leading to overbuild noise
when running what should be a null 'make'.
- but mostly: it's just an awkward way of dealing with C code.
|
|\ |
|
| | |
|
|/
|
|
| |
Sync-up missing extern declarations for many functions.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rationale (copied from htop issue #471):
The function name "setValues" is misleading. For most OOP (object-
oriented programming) contexts, setXXX functions mean they will change
some member variables of an object into something specified in
function arguments. But in the *Meter_setValues() case, the new values
are not from the arguments, but from a hard-coded source. The caller
is not supposed to change the values[] to anything it likes, but
rather to "update" the values from the source. Hence, updateValues is
a better name for this family of functions.
|
|
|
|
|
|
|
|
| |
(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.
|