coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: numfmt (=print 'human' sizes) updates


From: Pádraig Brady
Subject: Re: numfmt (=print 'human' sizes) updates
Date: Fri, 14 Dec 2012 08:53:39 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1

On 12/14/2012 05:38 AM, Assaf Gordon wrote:
Hello,

Attached is a slightly improved patch - minor code changes, and many more tests.
Line coverage is 98%, and branch coverage is now >93% , and most of the 
non-covered branches are simply unreachable (I'm checking the reachable ones).

The comments below still apply.

wow great stuff.

Assaf Gordon wrote, On 12/13/2012 01:02 AM:

Most of the previously raised issues have been addressed, except handling 
locale'd grouping in the input numbers (locale'd decimal-point is handled 
correctly).

Cool, we can address that if needed later.


Added support for header, auto-whitespace-padding, floating-point input .
Internally, all values are now stored as "long double" (instead of previously 
uintmax_t) - enables working with Yotta-scale values.

The following should now 'just work' :
     df | ./src/numfmt --header --field 2 --to=si
     ls -l | ./src/numfmt --header --field 5 --to=iec
     ls -lh | ./src/numfmt --header --field 5 --from=iec --padding=10

The "--debug" option now behaves more like sort's "--debug": prints messages to 
STDERR about possible bad combinations and inputs (which are not fatal errors):

     $./src/numfmt --debug 60000
     ./src/numfmt: no conversion option specified
     60000

Maybe --verbose would be more appropriate, if this option is needed at all.
sort is exceedingly complex whereas hopefully numfmt will not.

The "--devdebug" option can be used to show internal states (perhaps will be 
removed once the program is finalized?).

Yes we may remove, or at least not document.


The test file 'tests/misc/numfmt.pl' contains many more tests and details about 
possible inputs/outputs.

If the functionality is acceptable, the next steps are cleaner code and better 
documentations.

I hope to review this, this weekend.

thanks!
Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]