nmh-workers
[Top][All Lists]
Advanced

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

Re: [Nmh-workers] new marker format broke test suite


From: Paul Fox
Subject: Re: [Nmh-workers] new marker format broke test suite
Date: Wed, 14 May 2014 09:46:33 -0400

i've pushed the changes to rename %(units) to %(kilo), and to add a
new %(kibi) function.

if you're running git master, and are using %(units), you'll need
to change it to %(kilo).

the marker line (still) uses %(kilo), which means it disagrees with
the output of mhlist.  that's an easy change to mhform.marker,
depending on how others feel.

mhlist still uses 1024-based math, but prints K/M/G.  barring a
more complete rewrite to make mhlist's output tuneable, i guess i
should change it to either print Ki/Mi/Gi or use 1000-based math, to
at least be self-consistent.  thoughts?

paul


i wrote:
 > ralph wrote:
 >  > Hi Paul,
 >  > 
 >  > > it's clearly (to me, at least) not too late to change "units" to
 >  > > "kilo".  kibi can be added separately.
 >  > 
 >  > Ken said the code used base 2, >> 10, so the shipped files using the new
 >  > `units' should switch to kibi?  Or perhaps there aren't any?  (I thought
 >  > the functions were being added so marker lines could better represent
 >  > the content so they were being used there.)
 > 
 > summary:
 > 
 > currently (1.6 and previous) the part marker comes from mhlist's
 > list_content().  that code computes the size using ">> 10", and prints
 > K/M/G/T.  it avoids dealing with fractions by printing small numbers
 > of megabytes as large numbers of kilobytes, e.g.. "1089K".
 > 
 > when i made the marker controllable, at first the size got dropped
 > altogether (since part size wasn't available from mh-format), and then
 > when i realized that was a bit of a UI regression, it got added back
 > using %(units), which does "/ 1000", and prints K/M/G/T.  the default
 > mhshow.marker then adds a 'B', resulting in KB/MB/GB/TB.  ken and i had
 > agreed that it was okay to change the format somewhat (we were
 > specifically discussing the "1089K" thing at the time), and since i
 > was only implementing one %(units) function, decimal seemed like a
 > better choice than binary.  %(units) prints at most one digit after a
 > decimal point for fractional values.
 > 
 > i'm currently planning on renaming %(units) to %(kilo), and then adding
 > a new %(kibi), which will print Ki/Mi/Gi/Ti.
 > 
 > i don't particularly care whether %(kilo) or %(kibi) is used in the
 > default marker.  if left to me, i'll choose %(kilo).

=----------------------
 paul fox, address@hidden (arlington, ma, where it's 50.0 degrees)




reply via email to

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