With the help of our Swedish translator, hopefully the
final buglet has now been vanquished in the multi-byte
translation support. This one was a real nasty bugger.
Although it didn't occur with every terminal emulator,
occasionally random text lines were being chopped off.
As it turns out, those terminals were blameless. There
were two separate places in top's show_special routine
where potential multi-byte sequences were inadequately
addressed. Solution: exploit existing utf-8 functions.
[ it also became apparent that the translation hints ]
[ in the top_nls module were deficient. so a special ]
[ caution was added regarding the final line of txt. ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
Unlike the insp_mkrow_raw function the insp_mkrow_utf8
routine is not equipped to print non-ctl, non-printing
characters like '<7f>'. However, technically that very
value currently slips through the cracks. So with this
patch top will now print a space in the unlikely event
a character with the value of 127 is ever encountered.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since all the necessary utf-8 plumbing is now in place
this commit will extend multi-byte support to user and
group names. Now top will be on a par with the ps guy.
[ plus, it's also my way of showing appreciation for ]
[ all those investments silently made by translators ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
Translatable column headers are supposed to be limited
to no more than 7 characters, even though some columns
are wider than that or even variable width. That value
of 7 is dictated by the Fields Management screen which
will otherwise truncate a column header longer than 7.
Our new utf-8 support did not adequately deal with the
potential need for truncation of column headers should
that limit of 7 be exceeded. This patch corrects that.
[ a few comments were also tweaked just a little bit ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
The previous commit implemented multi-byte support for
the basic top user interaction and display provisions.
This commit completes multi-byte support by addressing
that 'Inspect Other Output' feature (the 'Y' command).
Few people probably exploit this very powerful feature
which allows the perusing of any file or piped output.
And even if nobody uses 'Y', someone will stumble over
it on the help screen and try it out. Assuming top was
not built with INSP_OFFDEMO defined, they'll end up on
the screen our translators have faithfully translated.
Without this patch, such a screen would display with a
bunch of 'unprintable' characters which will then show
in the standard (less-like) way as: '^A', '<C3>', etc.
In other words, those poor screens will be a big mess!
[ this program can even display an executable binary ]
[ while at that same time supporting Find/Find Next. ]
[ imagine, a file with no guarantee of real strings! ]
[ just try a Find using less with such binary files. ]
With this commit, the translated 'Y' demo screens will
now be properly shown, providing no invalid multi-byte
characters have been detected. Should that be the case
then they'll be displayed in that less-like way above.
And, if users go on to fully exploit this 'Y' command,
there is a good chance that a file or pipe might yield
output in a utf-8 multi-byte form. Should that be true
such output will thus be handled appropriately by top.
[ in many respects, this change was more challenging ]
[ than the basic support within the previous commit. ]
[ story of my life: least used = most effort needed. ]
Many thanks to our procps-ng translators which enabled
a proper test of these changed 'Y' command provisions:
. Vietnamese: Trần Ngọc Quân
. Polish: Jakub Bogusz
. German: Mario Blättermann
. French: Frédéric Marchal, Stéphane Aulery
[ and my sincerest apologies too, for my negligence! ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
When this project first began implementing translation
support nearly 6 years ago, we overcame many 'gettext'
obstacles and limitations. And, of course, there were
not any actual translations at the time so our testing
was quite limited plus, in many cases, only simulated.
None of that, however, can justify or excuse the total
lack of attention to top's approach to NLS, especially
since some actual translations have existed for years.
When the issue referenced below was raised, I suffered
immediate feelings of anxiety, doubt and pending doom.
This was mostly because top strives to avoid line wrap
at all costs and that did not bode well for multi-byte
translated strings, using several bytes per character.
I was also concerned over possible performance impact,
assuming it was even possible to properly handle utf8.
But, after wrestling with the problem for several days
those initial feelings have now been replaced by guilt
over any trouble I initially caused those translators.
One can only imagine how frustrating it must have been
after the translation effort to then see top display a
misaligned column header and fields management page or
truncated screens like those of help or color mapping.
------------------------------------------------------
Ok, with that off my chest let's review these changes,
now that top properly handles UTF8 multi-byte strings.
. Performance - virtually all of this newly added cost
for multi-byte support is incurred during interactions
with the user. So, performance is not really an issue.
The one occasion when performance is impacted is found
during 'summary_show()' processing, due to an addition
of one new call to 'utf8_delta()' in 'show_special()'.
. Extra Wide Characters - I have not yet and may never
figure out a way to support languages like zh_CN where
the characters can be wider than most other languages.
. Translated User Name - at some future point we could
implement translation of user names. But as the author
of the issue acknowledged such names are non-standard.
Thus task display still incurs no new multi-byte costs
beyond those already incurred in that escape.c module.
For raising the issue I extend my sincerest thanks to:
Göran Uddeborg
Reference(s):
https://gitlab.com/procps-ng/procps/issues/68
Signed-off-by: Jim Warner <james.warner@comcast.net>
The 'N_fmt' and 'N_txt' macros are interchangeable and
just highlight the 2 str types found in Norm_nlstable.
The change in this patch (strictly cosmetic) was found
during the coding for what will be the next 2 commits.
It has not been squashed into either of those so as to
not muddy up the waters for what was a major refactor.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Until this patch, top falsely assumed that there would
always be some (small) amount of physical memory after
subtracting 'used' and 'available' from the total. But
as the issue referenced below attests, a sum of 'used'
and 'available' might exceed that total memory amount.
I'm not sure if this is a problem with our calculation
of the 'used' amount, a flaw in the kernel 'available'
algorithms or some other reason I cannot even imagine.
Anyway, this patch protects against such a contingency
through the following single line addition of new code
. if (pct_used + pct_misc > 100.0 || pct_misc < 0) ...
The check for less than zero is not actually necessary
as long as the source numbers remain unsigned. However
should they ever become signed, we'll have protection.
[ Most of the changes in this commit simply separate ]
[ a variable's definition from its associated logic. ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/64
Signed-off-by: Jim Warner <james.warner@comcast.net>
For the past 3 years top has fully honored that locale
LC_NUMERIC setting which impacts his refresh interval.
For the past nearly 5 years top has saved that refresh
value in a locale independent form in his config file.
With this commit we'll intentionally break top so that
a comma or period will be accepted for the radix point
regardless of what that LC_NUMERIC may have suggested.
The current locale LC_NUMERIC will, however, determine
how the delay interval is displayed in the 'd' prompt.
[ This position is better than the approach employed ]
[ by those coreutils 'sleep' and 'timeout' programs. ]
[ Both claim to permit floating point arguments. But ]
[ neither one will accept the comma separator should ]
[ the locale be a country that in fact uses a comma. ]
Reference(s):
https://gitlab.com/procps-ng/procps/merge_requests/50
Prototyped by: Jan Rybar <jrybar@redhat.com>
Signed-off-by: Jim Warner <james.warner@comcast.net>
Ok, I admit it. I'm now tired of cleaning up after me.
This is the 3rd related tweak after that '-1' argument
was originally introduced. And with this patch we will
once again properly honor the '-o' and '-u|U' switches
without a need to be followed by an additional switch.
[ one can follow my unfortunate trail of alterations ]
[ beginning with my most recent fix referenced below ]
Reference(s):
commit 4b44aebd80
Signed-off-by: Jim Warner <james.warner@comcast.net>
While the effective user id would always be present in
each proc_t, thus supporting 'u' filtering, other user
ids would only be present if /proc/$$/status was read.
This commit just puts the 'master' branch top on a par
with the 'newlib' branch when user filtering with 'U'.
Signed-off-by: Jim Warner <james.warner@comcast.net>
With the introduction of a new '1' command line toggle
I have gone and broken a provision of the '-p' command
line switch (pids monitoring). Multiple pids could not
be specified through the use of comma delimited lists.
Thus, this commit simply corrects that newly added bug
which was born in the 'adjustment' commit shown below.
Reference(s):
. adjustment to '-1' implementation
commit 909b37d755
Signed-off-by: Jim Warner <james.warner@comcast.net>
There exists the possibility that a 'putp' call can be
issued before the 'setupterm' invocation has occurred,
as is reflected in a bugzilla report referenced below.
Strangely, such a SEGV isn't always triggered as logic
would suggest it ought to be. I experienced a fault in
these environments with the associated curses version:
. archlinux, procps-ng 3.3.12, ncurses 6.0.20170429
. fedora-25, procps-ng 3.3.10, ncurses 6.0.20160709
. opensuse-42.2, procps-ng 3.3.9, ncurses 5.9.20140201
. gentoo, procps-ng 3.3.12, ncurses 6.0.20150808
. slackw-14.2, procps-ng 3.3.12, ncurses 6.0.20160910
Whereas under these environments there was no problem:
. ubuntu-17.04, procps-ng 3.3.12, ncurses 6.0.20160625
. debian-test, procps-ng 3.3.12, ncurses 6.0.20161126
. mageia-5.1, procps-ng 3.3.9, ncurses 5.9.20140323
[ as an aside, the expected result in the bug report ]
[ is incorrect and should mention the '1' parameter. ]
[ however, until release 3.3.13 when the '1' becomes ]
[ a valid switch, numbers are not detected when used ]
[ with any switch which doesn't require an argument. ]
[ you're welcome to treat that as a separate bugglet ]
Reference(s):
https://bugzilla.redhat.com/show_bug.cgi?id=1450429
Signed-off-by: Jim Warner <james.warner@comcast.net>
The top program already incorporated a modest delay at
startup so that some minimal process cpu history could
be established. However, Summary Area system level cpu
statistic history reflected usage since boot. As such,
unchanging % values would be shown with every restart.
This commit just adopts the same approach used in task
%CPU history for the Summary Area statistics. In other
words, it introduces a 'priming read' at startup as is
found in the newlib implementation for the <stat> API.
Reference(s):
https://gitlab.com/procps-ng/procps/merge_requests/42
Signed-off-by: Jim Warner <james.warner@comcast.net>
This program has always tried to maintain an extermely
robust command line parsing procedure, far more robust
that what's available with the getopt stuff. But, with
the introduction of our first numeric switch it should
have been made even more robust than, in fact, it was.
This commit will now accomplish such a desirable goal.
Reference(s):
. added '1' command line switch
commit 89db82d143
Signed-off-by: Jim Warner <james.warner@comcast.net>
All of top's display was designed to fit into an 80x24
terminal. This includes the help screens plus both the
Summary and Task Areas, assuming no saved config file.
With release 3.3.10, the startup defaults were changed
assuming ./configure --disable-modern-top wasn't used.
This was done in the hope of introducing some users to
unknown capabilities such as colors, forest view, etc.
The purpose of this commit is to coax a few more users
into possibly exploring another capability: scrolling.
We do so by tweaking the default startup display so as
to show full command lines. Now, when things no longer
fit in 80x24, horizontal scrolling might be exploited.
[ of course, this can be reversed with the -c switch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
If built without ./configure --disable-modern-top, the
program displays each cpu individually providing there
is sufficient vertical screen real estate. For massive
SMP environments this will necessitate use of a config
file where the cpu summary toggle ('1') could be saved
via the 'W' command. But, an rcfile may not be viable.
So this commit introduces a '1' command line switch to
emulate exactly the effects of the interactive toggle.
And since it is our first numeric switch some existing
parsing logic had to be changed slightly. Such changes
are, in truth, an improvement. For example, instead of
seeing "inappropriate '2'" with ./top -2 we'll now see
the vastly more appropriate error "unknown option '2'.
References(s):
https://gitlab.com/procps-ng/procps/issues/55
Signed-off-by: Jim Warner <james.warner@comcast.net>
In their 3.2.7 version of top, Redhat introduced an -M
switch to automatically scale Summary Area memory data
to avoid truncation (and the resulting '+' indicator).
The procps-ng top does not employ suffixes with memory
data nor does it allow for different scaling with each
separate value. Rather, scaling appears at line start.
If built without ./configure --disable-modern-top, the
Summary Area memory will be scaled at GiB which should
lessen chance of truncation. Otherwise KiB was used to
reflect such memory, increasing the truncation chance.
And while 'W' can be used to preserve some appropriate
scaling value, there are arguments against such rcfile
approaches as cited in the issue and bug report below.
So this commit will bump the Summary Area memory scale
factor from KiB to MiB when using --disable-modern-top
as a concession to that Redhat bug report noted below.
And it also introduces a new command line switch which
can force any desired scaling regardless of the rcfile
or which ./configure option might have been specified.
[ for top's help text we'll show 'E' as if it were a ]
[ switch without arguments in order to keep the help ]
[ text displayable without wrap in an 80x24 terminal ]
[ the man page, however, will show all k-e arguments ]
Reference(s):
https://gitlab.com/procps-ng/procps/issues/53https://bugzilla.redhat.com/show_bug.cgi?id=1034466
Signed-off-by: Jim Warner <james.warner@comcast.net>
After much reflection I've come to the conclusion that
displaying 3 decimal places (usually) when memory data
had been scaled is no longer optimal with today's ever
increasing amounts. And given that not all task memory
fields are the same widths, inconsistencies can easily
arise as illustrated and discussed in the issue below.
Instead of unilaterally reducing the number of decimal
places, this commit will sneak in such a change via an
existing configure option that was very likely unused.
The former 'disable-wide-memory' option has now become
'enable-wide-memory', which can be used if the current
behavior (3 decimal places) is preferred. Without that
option, whenever memory is scaled beyond KiB, just one
decimal place will be shown in Summary and Task areas.
And Task area field width will no longer be changed by
this revised configure option. Instead, all such field
widths will now be fixed at the former maximum values.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/50
Signed-off-by: Jim Warner <james.warner@comcast.net>
By default the file HOME/.toprc will be prefered. This ensures there
should be minimal breakage even if this file is later created by some
other means. Otherwise we will follow the new behaviour described by
the XDG Base Directory Specification:
If the XDG_CONFIG_HOME environment variable is available we will attempt
to use this as XDG_CONFIG_HOME/procps/toprc otherwise we will fall-back
to HOME/.config/procps/toprc instead.
Signed-off-by: Earnestly <zibeon@gmail.com>
That issue cited below prompted some changes under the
newlib branch to standardize the calculation involving
busy, idle, user & system accumulated plus delta tics.
This patch will bring our master branch version of top
into agreement with that newlib version which exploits
some of those newly added library extended provisions.
Reference(s):
https://gitlab.com/procps-ng/procps/issues/48
Signed-off-by: Jim Warner <james.warner@comcast.net>
It makes no sense to begin our tracked nested level at
'1' then later require a '1' to be subtracted from the
level as artwork and indentation is added for display.
By beginning such tracked levels at zero, we can avoid
the need to adjust it & use it directly in a snprintf.
[ this commit parallels a patch in our newlib branch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch just parallels some adjustments/corrections
which were also implemented under the 'newlib' branch.
[ remaining differences between man documents relate ]
[ to old kernels with topic '2b. TASK and CPU State' ]
[ and a note in '4c. SORTING' for TTY + WCHAN fields ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Still unhappy with a minor memory leak associated with
libnuma, I experimented with omitting the dlclose that
was issued at module's end. For some reason which will
remain a mystery, the valgrind leak then went bye-bye.
So this patch just omits one use of dlclose and relies
on whatever kernel magic is at work to free the memory
when each process ends. We kept, however, the original
code (now commented-out) to serve as a future caution.
There remains one potential (but unlikely) dlclose use
near the original dlopen. But there will be no leak as
that 'numa_node_of_cpu' will not yet have been called.
This seems to be the culprit that triggers such leaks.
None of this libnuma shit would likely have come close
to hitting our fan had the numa developers provided us
with 'new' and 'unref' functions like our newlib does.
[ this commit parallels a patch in our newlib branch ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
After discovering those terrible costs associated with
/proc/status vs. /proc/stat, the build_header function
changed to favor the latter for a field found in both.
Well, low-and-behold, this top program still used some
flags that needlessly caused 'status' to still be read
when 'statm' could have served. And, while top's needs
require conversion from pages to KiB, that's still far
less costly than reading that gosh darn 'status' file.
[ this patch parallels similar changes to newlib top ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
Long ago, in a galaxy far away, top was convinced that
/proc/stat was to be favored over /proc/status if some
field could be satisfied with either. This was done to
avoid extra costs of 64-bit math for 32-bit platforms.
Well, its time to acknowledge the prevalence of 64-bit
platforms. And in such an environment there is a large
hidden cost currently if using status instead of stat.
In fact, that cost difference can be as high as 1400%.
So, this commit will coax top into favoring that least
costly route while also fixing an EU_TGD library flag.
[ this patch parallels similar changes to newlib top ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit provides for raising the total displayable
fields from its current 70 to 86. It also bumps the id
in an rcfile representing the version from 'i' to 'j'.
The increase in number of fields will make sharing the
rcfile with an older top, once it's saved, impossible.
These changes are being done via a #define rather than
hard coded so any such sharing will still be possible.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Whoa, I had never considered an alternative to ncurses
until the issue referenced below was raised. Thus, I'm
surprised to find that 'tparm' was the only impediment
to ultimately utilizing this alternate curses library.
And, while we could have substituted that non-standard
'tiparm' with only 2 arguments, we'll utilize the full
parms compliment in the spirit of that original patch.
Frankly, the task of developing an alternative library
to that ncurses implementation really boggles my mind.
Congratulations to rofl0r, whoever that masked man is.
Reference(s):
. issue raised
https://gitlab.com/procps-ng/procps/issues/38
. netbsd-curses home
https://github.com/sabotage-linux/netbsd-curses
Signed-off-by: Jim Warner <james.warner@comcast.net>
This patch adapts the ps program to a newly add proc_t
field and provides for new support in that top program
along with his man document (ps was already ok there).
Signed-off-by: Jim Warner <james.warner@comcast.net>
We'll follow Craig's lead and whack some author stuff.
[ and we'll honor the SEE ALSO guideline for periods ]
[ but essentially ignore all the other busybody crap ]
[ which, to be honest, we pretty much follow already ]
[ actually, if you're told to follow a certain style ]
[ in program examples, you've gone way past busybody ]
[ crap and have entered the realm of anal retentive! ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This development (only) define can be used to turn top
into a simple text program, disabling termcap effects.
But input (at screen bottom) suffers from a line wrap.
So, this commit just makes the input prompt processing
a little more effective by adding one leading newline.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Now that the conditional OOMEM_ENABLE has been removed
and all users exposed to those 'out of memory' fields,
it's about time we added them to the top man document.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Using the <STAT> api under the newlib branch, that top
program is very responsive to changes in the number of
on-line cpus. However under the master branch this top
program is very responsive only to losses of some cpu.
When a cpu is brought back on-line potential delays of
60 seconds could be encountered. That delay was simply
an attempt to reduce costs and reflected the erroneous
assumption that adding a cpu required physical effort.
So without redesigning the cpu refresh code to emulate
that of newlib, this commit just reduces the potential
delay to 3 seconds (the same that is used for memory).
[ As an aside, if one wants to have their confidence ]
[ in that htop program badly shaken, try taking some ]
[ cpus off-line & on-line again while it is running. ]
[ Poor ol' htop just continues to report results for ]
[ whatever were the cpus when started. Nice feature, ]
[ but I wonder where those phantom results are from. ]
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just tries to parallel that newlib branch.
It contains the following changes, which were prompted
by the newlib coverity analysis which Craig initiated:
. comment typo predicting 'String not null terminated'
. eliminate 'Logically dead code' from insp_make_row()
Some tweaks, unrelated to coverity, are also included:
. use more modern (recommended) approach for time call
Signed-off-by: Jim Warner <james.warner@comcast.net>
This commit just tries to parallel the implementations
in the newlib branch. The config file Rc.zero_suppress
will be extended to include both out-of-memory fields.
And while we're at it, we'll also extend zero suppress
to that NI (nice value) field, which already should've
had it. Plus we trade those namespaces custom suppress
logic for our now slightly enhanced make_num function.
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since support already exists in the newlib branch this
represents an equivalent master branch implementation,
and this commit message is shared with 2 more patches.
Beginning with linux-4.5, the following new fields are
being added under that /proc/<pid>/status pseudo file:
. RssAnon - size of resident anonymous memory
. RssFile - size of resident file mappings
. RssShmem - size of resident shared memory
p.s. Locked resident memory support was also added but
isn't directly related to the kernel 4.5 enhancements.
p.p.s. Archlinux, Debian-stretch and Fedora-23 already
are currently using a 4.5 linux kernel (as of 6/2/16).
Signed-off-by: Jim Warner <james.warner@comcast.net>
Since support already exists in the newlib branch this
represents an equivalent master branch implementation,
and this commit message is shared with 2 more patches.
Beginning with linux-4.5, the following new fields are
being added under that /proc/<pid>/status pseudo file:
. RssAnon - size of resident anonymous memory
. RssFile - size of resident file mappings
. RssShmem - size of resident shared memory
p.s. Locked resident memory support was also added but
isn't directly related to the kernel 4.5 enhancements.
p.p.s. Archlinux, Debian-stretch and Fedora-23 already
are currently using a 4.5 linux kernel (as of 6/2/16).
Signed-off-by: Jim Warner <james.warner@comcast.net>
After experimenting with those 4.5 kernel enhancements
to /proc/<pid>/status, that newly added overview topic
'Memory Types' was found to be in need of some tweaks.
In addition, the 'DATA' description wasn't quite broad
enough since explicit private file mappings impact it.
( lastly, for the record, the 2nd commit referred to )
( below contained an incorrect reference that should )
( have been the original issue 21 commit. instead it )
( showed an invalid SHA-1 hash. i believe i have now )
( identified a flaw in my workflow that produced it. )
Reference(s):
. original patch responding to issue #21
commit e4bbd3ca1a
. subsequent patch with invalid commit ref
commit 5dcbcd00fe
Signed-off-by: Jim Warner <james.warner@comcast.net>
In response to Issue #21, the commit referred to below
provided some much needed improvements and corrections
to topic `3a. DESCRIPTIONS of Fields' in the man page.
However, it assumed a reader possessed much background
knowledge that may not, in truth, actually be present.
So without, hopefully, insulting anyone's intelligence
this patch offers an expanded discussion of some terms
and concepts within a separate section under OVERVIEW.
[ plus it affords an opportunity to incorporate that ]
[ extremely useful table from Florent Bruneau's post ]
Reference(s):
commit f2a08cf16794ec6085bdecbaf8f7c2887cd4e87f
https://techtalk.intersec.com/2013/07/memory-part-1-memory-types/
Signed-off-by: Jim Warner <james.warner@comcast.net>
Due to quirks in kernel memory management plus limited
information available from /proc/<pid>/status & statm,
some of the top resident memory fields were capable of
exceeding available physical memory. So this commit is
a bit of a band-aid until the kernel has been changed.
Such a change appears to be on the horizon in the form
of three new fields to be added to /proc/<pid>/status.
While not preventing 'resident' memory from apparently
exceeding physical memory, the new fields will help to
clarify any such contingency, if/when we exploit them.
Reference(s):
. original post by Samuel Thibault
https://gitlab.com/procps-ng/procps/issues/21
. informative memory analysis
https://techtalk.intersec.com/2013/07/memory-part-1-memory-types/https://techtalk.intersec.com/2013/07/memory-part-2-understanding-process-memory/
. kernel changes to /proc/<pid>/status
commit 8cee852ec53fb530f10ccabf1596734209ae336b
commit eca56ff906bdd0239485e8b47154a6e73dd9a2f3
Signed-off-by: Jim Warner <james.warner@comcast.net>
The commit referenced below claims to disable vertical
scrolling when idle tasks weren't being shown. However
it really addresses only a point in time when that 'i'
toggle is keyed. Left untouched were the up/down keys.
So this commit will simply finish the job of disabling
vertical scrolling whenever tasks which have used some
CPU are the only ones which are currently being shown.
Reference(s):
commit c07f6c5e6d
Signed-off-by: Jim Warner <james.warner@comcast.net>
Multiple scanf()s use the GNU-permitted %Lu. This is not supported in
other libraries and isn't to the POSIX specification. The L modifier
is only used for floats in POSIX.
Replacing %Lu with %llu is the same for GNU libc (scanf(3) says as much)
but means other libraries will work fine.
Closes: #19
References:
http://pubs.opengroup.org/onlinepubs/009695399/functions/fscanf.html
It is documented behavior that when certain other keys
are active, sorts column highlighting will temporarily
be disabled. Among those keys is the 'L' (locate/find)
provision. The equals ('=') key can be used to restore
column highlighting by resetting other keys, except 1.
When a locate/find is active, the '=' key will have no
effect on 'x' column highlighting, which still remains
disabled. Further, when 'L' is active an 'x' keystroke
is processed changing the state of column highlighting
but without any visual clue (since it's yet disabled).
So this commit just extends the '=' key to embrace 'L'
processing resets, just like other highlight disabling
keys while avoiding 'x' state changes if approproiate.
Signed-off-by: Jim Warner <james.warner@comcast.net>
We'll following the newlib <pids> approach to hashing:
. a 'PIDs at max depth:' portion of that UNREF_RPTHASH
enabled #define is now published only when the maximum
depth of hash table entry chains exceed depths of one.
Signed-off-by: Jim Warner <james.warner@comcast.net>
