in reply to Visualizing bugs

Using text-based graphics to watch a non-deterministic process like this is a great idea -- both really rich and really simple.

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?)

Replies are listed 'Best First'.
Re^2: Visualizing bugs
by brian_d_foy (Abbot) on Dec 20, 2004 at 01:29 UTC

    The actual randomizing wasn't the problem. I had something else going on that messed things up. The trick is the boundary of two cycles. An object can be the last thing of the first cycle and the first thing of the next cycle, so effectively gets chosen twice in a row, which is bad. I wanted to spread those apart. It's not big deal: just the stupid sort of stuff that happens at 3 in the morning. I had wanted this technique for something else, so I tried it out. It doesn't really take that much attention: as long as I look at it and there are only two colors, everything is fine.

    I recall some odd problem with headers and that I had to remove something. I think I found the answer by plugging "curses perl mac os x" into Google. There is a fink port, and there is probably a Darwin Ports port too.

    If you are going to use this on a Mac, the vt100 terminal type might not work for you. I switched to dtterm (there is also Apple_Terminal), which is really just changing the TERM environment variable however your avorite shell does that.

    --
    brian d foy <bdfoy@cpan.org>
[reply]
Re^2: Visualizing bugs
by qq (Hermit) on Dec 21, 2004 at 01:31 UTC
[reply]
      That worked -- thanks!
[reply]

In Section Meditations