But for the sake of debugging a process with respect to a spec of the sort:
... cycle through a collection of external files, ... do it in a random order, and ... go through all of the files before [doing] any file twice.
it seems to me there are easier methods that would involve listing problem cases to an error-log file, which can be read at whatever pace with full attention to relevant details (as opposed to watching a live animation with a constant data rate, where momentary distractions can make you miss some events, and the level of detail is limited).
For that matter, there are well-established cookbook techniques for efficiently randomizing any list of items, with no repeats and no drop-outs. I'm a little surprised to see this matter come up as something that requires special measures for debugging. (Maybe your process is more complicated, and you just decided to spare us the details?) Still, thanks and ++ for the display technique.
(BTW, I noticed from the screen shots that you're using a mac. I just tried installing Curses.pm on my mac so I could play with your code, and the CPAN build failed because of what appear to be some conflicts in header files -- e.g. I seem to have a "/usr/include/curses.h" (from Sep 2003) that contains some conflicts with a few different *.h files in "Perl/5.8.1/darwin-thread-multi-2level/CORE/", so Curses.c gets into trouble trying to use that curses.h along with those other *.h files. Did you have this trouble, and if so, how did you get around it?)
In reply to Re: Visualizing bugs
by graff
in thread Visualizing bugs
by brian_d_foy
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |