Fred Fish's dbug library Icon

User Ratings

ease 1 of 5 2 of 5 3 of 5 4 of 5 5 of 5 0 / 5
features 1 of 5 2 of 5 3 of 5 4 of 5 5 of 5 0 / 5
design 1 of 5 2 of 5 3 of 5 4 of 5 5 of 5 0 / 5
support 1 of 5 2 of 5 3 of 5 4 of 5 5 of 5 0 / 5
Write a Review

User Reviews

  • 1 of 5 2 of 5 3 of 5 4 of 5 5 of 5

    I met the Fred Fish debug macros when I worked for a transaction processing company. (I later actually met Fred Fish, but that's a different kettle, as it were (still a good kettle)). These macros can be used to trace entry and exit from routines (along with arguments passed), provide additional debug output, and log all that to a file or to standard out. In addition, you can use 'tags' to set up debug levels, similar to syslog but with text strings instead of numbers. Extremely powerful. The TPC I worked for not only used them for debugging during development, but the macros were compiled in to production code as well. (Making testing a production problem debuggable even on the production system, in case we could not reproduce it on the test system). I then carried them with me to my next job - the Arizona Freeway Management System (originally since moved to Our application there was heavily threaded, so I modified them to be thread-safe, with each thread able to write to its own output file (unfortunately I was unable to release those changes back to the world), and to allow on-the-fly changing of the debug state by connecting to a service that the program ran and accepting debug commands. I also added the ability to log data to a file (controllable by the debug state), or read that file back as if it had been the actual input to the program (also controllable by the debug state, IIRC). I also improved performance slightly by not doing the string compare if debug was off. Ah yes - I also added a 'monotonically-increasing' counter so we could merge the output into a single stream, in order. I think I made some other changes, but don't remember any more. In any case, the last time I used them without those changes, you could, from the command line, select what level of debug output you wanted, select what kinds of data was printed (date, time, sequence, etc), trace routine entry and exit (along with argument values), etc. One perhaps non-obvious application of these macros is for regression testing. Log to a file the execution of a test. Later, when changes are made to the program to fix a bug, re-run that test and compare the original log to the new one. With a bit of care, things that "don't matter" can be filtered, giving you a very strong indication of whether or not the bug fix broke something else. (Yes, I used THAT at another company I worked for). It was very nice to make a change to our 'compiler' program, run our very extensive set of tests (almost every bugfix resulted in a new test) and be able to verify that, not only was the output of the compiler correct, but execution changes were minimal or at least expected. So, bottom line - HIGHLY recommended. I've used them extensively and found them a great tool for the toolbelt. Rusty

    Posted 02/23/2012

Thanks for helping keep SourceForge clean.

Screenshot instructions:
Red Hat Linux   Ubuntu

Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Briefly describe the problem (required):

Upload screenshot of ad (required):
Select a file, or drag & drop file here.

Please provide the ad click URL, if possible:

Get latest updates about Open Source Projects, Conferences and News.

No, Thank you