Progress reporting: N more to check

[jw schultz]

On Tue, Jan 13, 2004 at 01:59:18AM -0800, Wayne Davison wrote:
> On Mon, Jan 12, 2004 at 11:46:05PM -0800, jw schultz wrote:
> > How about "(%d of %d files)\n", cur_index, flist->count;
> 
> I tried that, but I didn't like it.  The first number in my patch
> tells you the current count of how many files were updated, not the
> offset within the list, which I think is more useful to know (yeah
> --stats gives that count transferred at the end, but this gives you
> a running count and the total at the end without all the other
> stats).  It also has a count-down that approaches 0 in the second
> part, which is friendlier for large numbers of files.  Being able to
> see at a glance in a really large transfer that there are just 3000
> files to go, and only 394 files had needed to be updated so far
> would be cool.  The simpler x-of-y stat can convey the amount to go
> via subtraction (e.g. subtract 29837 from 32725), plus a constant
> reminder of the total file count (which is only visible near the
> start of the transfer in my scheme).

Without knowing the size of flist the number of files to
check doesn't tell me where i am in the list statically
which is what i would want to know.  I also would want it to
be such that i could know this from an single entry.  No
back-scroll of a 52,197 lines to find the total file count.

If you want a rolling count of files updated that's fine.
I just thought it was more complicated than was needed.

I'd still like to know the position in the file list either
as a percentage or %d of %d.  Whether that is counting down
or up i don't care.  I don't think the two are mutually
exclusive.

> So, I personally like my suggestion better than a "(file %d of %d)"
> display.  Dunno if I'm in the minority on that or not, though.

You cut the text of your format but here's a few suggestions

	(sync 1034, 31.5% more)

A little vague but is the shortest.

	(sync 1034 of 1450, 2963 more)
	      |       |     |
	      |       |     flist->count - flist_index
	      |       flist_index
	      files_transfered

Relatively clear with all three numbers changing every
entry.  Most should be able to figure out what the three
numbers mean as it scrolls.  The first number increments by
one while the second jumps as files are skipped.  The third
gives you a jumping countdown.

	(sync 1034, 1450 of 4413)
	      |       |     |
	      |       |     flist->count
	      |       flist_index
	      files_transfered

My own preference,  The first number increments by one, the
second jumps (as in previous example) to converge on the
last number which is fixed.

All of which would meet both requirements.  The use of # as
a prefix usually indicates an index number or address, not a
count.

> (FYI, I think I've talked myself out of the extra "more to check"
Agreed.  

> verbage.  It should be enough to just say "more" and mention in the
> manpage that it means "more to check" and not "more to transfer".)

All the numbers should be explained in the manpage.  If
you'd like to put an explanation of the --stats numbers as
well that might be good too.  Since i don't much care i've
never bothered to research them but it seems to be a fairly
frequent question on the list.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt