This patch just follows Craig's lead for the remaining
ps and top program files and associated man documents.
Signed-off-by: Jim Warner <james.warner@comcast.net>
The provision excluding some strings is intended to be
used very sparingly. It exists in case we collide with
some translation project person in a position to delay
a future release over his or her personal preferences.
(it's currently used only on v4.0.1 command line help)
Signed-off-by: Jim Warner <james.warner@comcast.net>
I sure hope we won't disappoint the library with these
changes since we're only exploiting one of the two new
enumerators that the immediately prior patch provided.
Now top will be able to offer a visual clue as to each
cpu (thread actually) core association. Is it a P-core
offering multiple threads or a single threaded E-core.
We'll accomplish this feat with a subtle change to the
states portion ('t' toggle) of the summary area. Where
before processors were represented as 'Cpu', they will
now be displayed as 'CpP' (P-core) and 'CpE' (E-core).
[ assuming that new '5' command toggle has been used ]
There are also new provisions for filtering those cpus
by their core type association via the new '5' toggle.
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch introduces a new #define TOG4_MEM_FIX which
serves to turn off the new feature it also implements.
The feature, on by default, provides a flexible memory
graph approach which strives to always keep its visual
separator in alignment with cpu separators seen above.
Below is a summary of the algorithm implementing this:
1) First, ascertain the widest graph which corresponds
to the largest number of cpu graphs but doesn't exceed
maximum allowable graph width (i.e. GRAPH_length_max).
2) Next, apply that to the graphed 'Mem' portion which
is likely to remain entirely visible. However, it will
grow or shrink depending on total adjacent cpu graphs.
3) Last, the same width is used for the 'Swap' portion
but that graph is considered sacrificial and very well
could be truncated depending on the width of a screen.
[ along the way, when the cpu graphs revert to their ]
[ abbreviated form, the memory graphs will also show ]
[ an abbreviated prefix. in this way the widths will ]
[ also be maximized, reducing potential distortions. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit will change some comments, adjust a little
whitespace but mostly rename some #define identifiers.
Signed-off-by: Jim Warner <james.warner@comcast.net>
When displaying detailed memory statistics two abreast
data for the lines are less than those for cpus. So we
can exploit such a difference to provide a distinctive
separator. This may help separating cpu & memory data.
[ in truth, this happened before this patch. what we ]
[ are doing now is polishing that accidental feature ]
[ and placing it under the control of a conditional. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When more than two cpus are displayed per summary area
line in graph form, those memory graphs were scaled to
that same width for consistency & aesthetics. However,
they probably shouldn't have been reduced to less than
terminal width due to a resulting loss of information.
[ after all, detailed memory stats are never reduced ]
So now, supporting logic was refactored to behave just
as it did before the 4 toggle was expanded beyond '1'.
[ the changes impact the 2 memory graphs exclusively ]
Reference(s):
https://www.freelists.org/post/procps/top-enhancements-2-bugs-swatted,1
Signed-off-by: Jim Warner <james.warner@comcast.net>
I guess the cat's out of the bag with the prior commit
message. It mentioned the objective of displaying more
than the current two cpu graphs on summary area lines.
On the way to that objective, this patch just prepares
our battlefield for the actual implementation in which
up to 8 individual cpu graphs will be shown on 1 line.
[ no logic has been impacted with this commit. we're ]
[ just adding one manifest constant, trading several ]
[ identifiers and updating some comments so the next ]
[ commit might be just a little bit more manageable. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The logic (illogic?) in the sum_tics() and do_memory()
functions has grown to become almost unfathomable over
time. Additionally, though perhaps not apparent in the
code, many steps are duplicated within those routines.
So, this patch refactors all the summary graph support
to consolidate duplicated code and (hopefully) make it
more understandable with an eye to future maintenance.
[ additionally, that show_special guy's workload has ]
[ been reduced by eliminating any special directives ]
[ previously embedded in some cpu graphs even though ]
[ a cpu may have been idle during the last interval. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
When 2 abreast cpu display was introduced, the minimum
screen width was 160 columns so as to avoid (minimize)
truncation. Later that was reduced to 80 columns while
keeping the original minimum as a compile conditional.
In preparation for (virtually) eliminating these width
restrictions in a future patch this #define's history.
Reference(s):
. May, 2020 - introduced #define TOG4_NOTRUNC
commit be3dcaa842
. May, 2020 - introduce 2 abreast display
commit 59f5a37a24
Signed-off-by: Jim Warner <james.warner@comcast.net>
When two abreast display was introduce, in that commit
shown below, this #define provision was also added. It
actually was an artifact left from program development
and never made much sense in a real world application.
If activated it would make the '4' toggle appear to be
broken since it would only take affect if a user first
activated individual cpu display (the '1' toggle off).
And there was no error message offered to those users.
So, this questionable #define is now being eliminated.
Reference(s):
. May, 2020 - introduce 2 abreast display
commit 59f5a37a24
Signed-off-by: Jim Warner <james.warner@comcast.net>
