I think I am about to ramble on a bit.

I would really be surprised if there was a "generic" progress reporting function in CPAN. creating tag files or write over a line is almost too simple to be worth a CPAN module. doing something operating system specific (a progress bar on a Windows screen for example) would be a different story. I think a "good" CPAN module would end up having so many options it would be way too big to be practical since it would probably at a minimum include tag file and console options, estimating routines (for completion estimates), memory usage reporting, all the options to change when reporting is done, and probably a variety of error checks along with a variety of ways to report the progress to reduce processing overhead.

I have been working on a Perl based system where we normally provide feedback by creating "tag" files in the processing directory to show the progress (this is running as a background/batch process). the progress code does have the option to display to the console if running manually. based on the progress I have been providing the most important thing is to show that something is being done (processing record ####). additional information (processing record #### of ####) may be better in some cases where it is expected to take a long time. I report progress regularly (typically every 5 seconds) - that seems to be good enough for most cases. all of my common progress code is responsible for determining when to show the progress - the calling program just "reports" the progress.

when I started to write the progress code I am currently using there was almost no progress reporting for anything that was going on. the code I am using now grew from a few simple routines to a whole collection of routines with special progress reporting options (percentages, time estimates, memory usage, etc.) so it is probably not a good example to be posted. if you write your own package it may start out as around 100-150 lines of code. if you do a lot of progress reporting then the code will probably grow based on what you report and how you want to report it. my progress reporting related code (in at least 3 files) totals around 1000 lines of code and modest comments.

my recommendation - try something (anything) and then if that does not work to your satisfaction - try something else.

a word of caution - if you are going to report progress for every operation then be careful about building strings for each progress report - can be a significant amount of processing. in my case I had alternate ways of reporting which did not have much overhead (the progress routine would build the variable string from a fixed base string and a record count if it was time to report). and while you may be able to test if it is time to report progress for each case where you report progress it is a whole lot easier to have a common package of some sort do it so all you really need to do is insert calls wherever you need to report progress.

in the late 1990s I worked on a system (C/Assembly) using PC hardware I actually modified the VGA character set to add some characters for a "heartbeat" (characters shaped like a heart in various sizes), "spinner" characters (circles with different sections filled), and progress bar characters. once the setup was figured out (those old DOS books were handy at the time) it made an otherwise boring ASCII display a little more interesting. sometimes it is also handy to have something "clever" like this when talking to a customer about a problem ("is the heart beating"). it turns out that all of those little characters provided a lot of information with very little code (good things come in small packages or something like that).

now an opinion. I feel that the progress that should be reported should be targeted to the end user of the program. the objective is to have the end user know that things are working (so they are happy) and have a piece of information (and possible failure indication) that can be used to help isolate where a problem is (so the developer is less unhappy when debugging). I do not think there are any real rules for providing progress to an end user except that if they wonder what is going on or complain that something is taking a long time then they need to be given some indication that things are OK. and as a developer I may want even more progress because I want to know that the software is actually working. just be careful about providing too much information.

end of ramble - sorry to put you to sleep....

In reply to Re: Progress Bar in Perl script by Anonymous Monk
in thread Progress Bar in Perl script by slayedbylucifer

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.