Change Details

1) humanize_number() was being passed a buffer size that was one byte too small than the intended usable width if you account for the NUL byte that it needs to write. This caused noticeable problems with the Csw/Trp/Sys/Int/Sof/Flt showing without units for me (when the number was big enough). An easy way to get big numbers there is "yes | cat | cat | cat > /dev/null". 2) Another problem I noticed is that the fields under "Mem: KB" are turned into Ks before being passed to humanize_number(), which may then scale them again. So if it shows "1000K" it actually means "1000M". Pretty confusing. This patch rearranges this part of the screen to always use byte units directly. And it condenses the table a little. Looks a lot nicer I think! It's more like top(1) for this now. 3) Make other fields that use humanize_number() narrower because it makes them easier to read I think. 4) Relabelled "Proc:" to "Threads:" because it actually counts threads (hence why it doesn't match the numbers shown in top(1)). Not fixed: The fields in the r/p/d/s/w columns under "Proc:" (now "Threads:") have the same problem as the Csw/Trp/Sys/Int/Sof/Flt fields, but I have no idea how to fix them without rearranging the whole screen to give them more space. They only have space for 3 characters, this isn't enough for humanize_number() to do its thing right if the number is larger than 999 (before this patch, they had problem if they were larger than 99). The fields next to them have space for 4 characters which is the minimum for it to work correctly. At some point in the past the fields that overflow would be shown as "***" instead. You could argue that this is less misleading. Maybe we could make this "99+", "INF" or "NaN" instead? Maybe they could be shown in an E notation with no decimal instead (e.g. "1E4" for 1000)? That's only good for up to a billion with only 3 digits though. And it doesn't look so great. Also, some functions should be renamed but I'm trying to keep this diff small.

1) humanize_number() was being passed a buffer size that was one byte too small than the intended usable width if you account for the NUL byte that it needs to write. This caused noticeable problems with the Csw/Trp/Sys/Int/Sof/Flt showing without units for me (when the number was big enough). An easy way to get big numbers there is "yes | cat | cat | cat > /dev/null". 2) Another problem I noticed is that the fields under "Mem: KB" are turned into Ks before being passed to humanize_number(), which may then scale them again. So if it shows "1000K" it actually means "1000M". Pretty confusing. This patch rearranges this part of the screen to always use byte units directly. And it condenses the table a little. Looks a lot nicer I think! It's more like top(1) for this now. 3) Make other fields that use humanize_number() narrower because it makes them easier to read I think. 4) Relabelled "Proc:" to "Threads:" because it actually counts threads (hence why it doesn't match the numbers shown in top(1)). 5) For fields that are just too small for humanize_number(), restore previous behavior of rendering the field as a sequence of "*" characters. Not fixed: Point 5). The fields in the r/p/d/s/w columns under "Proc:" (now "Threads:") have the same problem as the Csw/Trp/Sys/Int/Sof/Flt fields, but I have no idea how to fix them without rearranging the whole screen to give them more space. They only have space for 3 characters, this isn't enough for humanize_number() to do its thing right if the number is larger than 999. The fields next to them have space for 4 characters which is the minimum for it to work correctly. Maybe we could make this "99+", "INF" or "NaN" instead? Maybe they could be shown in an E notation with no decimal instead (e.g. "1E3" for 1000)? Also, some functions should be renamed but I'm trying to keep this diff small.

1) humanize_number() was being passed a buffer size that was one byte too small than the intended usable width if you account for the NUL byte that it needs to write. This caused noticeable problems with the Csw/Trp/Sys/Int/Sof/Flt showing without units for me (when the number was big enough). An easy way to get big numbers there is "yes | cat | cat | cat > /dev/null". 2) Another problem I noticed is that the fields under "Mem: KB" are turned into Ks before being passed to humanize_number(), which may then scale them again. So if it shows "1000K" it actually means "1000M". Pretty confusing. This patch rearranges this part of the screen to always use byte units directly. And it condenses the table a little. Looks a lot nicer I think! It's more like top(1) for this now. 3) Make other fields that use humanize_number() narrower because it makes them easier to read I think. 4) Relabelled "Proc:" to "Threads:" because it actually counts threads (hence why it doesn't match the numbers shown in top(1)). 5) For fields that are just too small for humanize_number(), restore previous behavior of rendering the field as a sequence of "*" characters. Not fixed: The fields in the r/p/d/s/w columns under "Proc:" (now "Threads:") have the same problem as the Csw/Trp/Sys/Int/Sof/Flt fields, but I have no idea how to fix them without rearranging the whole screen to give them more space. They only have space for 3 characters, this isn't enough for humanize_number() to do its thing right if the number is larger than 999 (before this patch, they had problem if they were larger than 99). The fields next to them have space for 4 characters which is the minimum for it to work correctlyPoint 5). At some point in the past the fields that overflow would be shown as "***" insteadThe fields in the r/p/d/s/w columns under "Proc:" (now "Threads:") have the same problem as the Csw/Trp/Sys/Int/Sof/Flt fields, but I have no idea how to fix them without rearranging the whole screen to give them more space. You could argue that this is less misleadingThey only have space for 3 characters, this isn't enough for humanize_number() to do its thing right if the number is larger than 999. The fields next to them have space for 4 characters which is the minimum for it to work correctly. Maybe we could make this "99+", "INF" or "NaN" instead? Maybe they could be shown in an E notation with no decimal instead (e.g. "1E4"1E3" for 1000)? That's only good for up to a billion with only 3 digits though. And it doesn't look so great. Also, some functions should be renamed but I'm trying to keep this diff small.