[Yum-devel] [UG] progress meters

[Michael Stenner]

OK, I have a working progress meter thingy.  At least, I think it
works.  This should be interpreted as some kind of double-alpha.  This
is basically a proposed interface.  So, now I have a few questions,
mostly about output format.  Here's what it's currently doing (trimmed
to remove some of the files:

file_15                        512 kB    00:00:02     233 kB/s
file_03                        1.0 MB    00:00:07     131 kB/s
file_12                        256 kB    00:00:20      13 kB/s
file_18                        1.0 MB    00:00:46      22 kB/s
file_19                        1.0 MB    00:00:15      66 kB/s
files:  19/19  100%   data: 6.1 MB/6.1 MB 100%   time: 00:01:07/00:01:07       

Basically, the bottom line always tells you where you are in files,
bytes, and time.  Every time a file is finished, it's printed along
with its size, the time it took, and the download rate.  I'd very much
like to hear people's thoughts on the output format.  I'd like to see
some kind of ETA (as there currently is in yum) but I'm not sure how
to do it.  We have a finite amount of space :)

I implemented this using a scheme inspired by ryan's example in the
threading test code.  There is a master progress meter, and it creates
many "helpers" which are handed into the grabbers.  Each of these
reports back to the the master.  Note that the api for the progress
meters might have changed a little, so it probably won't work with the
grabbers ATM.  Here are the things I would like to include:

  * an external "lock" method so that the calling app can write to the
    stream without conflicting with the meter in a different thread.
    This would go in the text meter only, not the base meter (from
    which gui meters can also be derived).

  * a "failure" method which means "we couldn't get this file, but
    we're going to keep getting others.  This would appropriately
    modify the "status line".

  * a convenience class that automagically works for multiple threads
    by detecting which thread it's in and assigning one helper per
    thread.  This would allow you to create a single object and use it
    in multiple threads.  It would be a little less flexible, though.
    For example, the current meter can also be used in select-based
    multi-file downloads.

  * alternate (derived) versions and/or options do deal with
    - when we don't know the total file size
    - when we JUST want the status line and not the report of every
      file
    - other?

If you want to look at the current progress meter, it's here:
  http://linux.duke.edu/~mstenner/misc/new_progress.py
 
The test code is a little nasty, but the real code itself is quite
nice :)  I'm especially happy with the RateEstimator class.

				-Michael 
-- 
  Michael D. Stenner                            mstenner at ece.arizona.edu
  ECE Department, the University of Arizona                 520-626-1619
  1230 E. Speedway Blvd., Tucson, AZ 85721-0104                 ECE 524G