Lord Rau has asked for the wisdom of the Perl Monks concerning the following question:

Hey guys! I'm going through 30,000+ lines of the most spaghetti-fied OO perl code I've ever seen. I've been trying to use the Perl debugger to get a good feel for the program's flow, but it's not helping. I end up with an 11 meg output file that's impossible to comb through due to all the calls to exporter.pm that perl is making whenever "use somemodule.pm;" is done. Any advice? Should I shoot myself now? Or do I dare try and tango with this monster? I need help!!!

Replies are listed 'Best First'.
Re: Perl Debugging Hell!
by stephen (Priest) on Apr 13, 2000 at 00:47 UTC
    You might want to look at the CPAN module Devel::Trace. It prints out program lines as they're executed. See http://www.plover.com/~mjd/perl/Trace for details. Might be easier than using the standard debugger.

    More interestingly, there's the Devel::TraceFuncs module, which does this: 

    Devel::TraceFuncs lets you instrument your programs, so you can see
what subroutines get called when, and by whom.  This is particularly
useful if you have a timing problem that doesn't show up if you use
the debugger (a "heisenbug").

The following program:

   use Devel::TraceFuncs qw(trace debug);
 
   sub foo {
     trace(my $f);

     debug "hi";
   }

   trace(my $f);

   foo(1, 2);
   debug "there";

produces this output:

   +-> global
   |  +-> main::foo(1, 2) (in t.pm:10)
   |  |  hi (in t.pm:6)
   |  +-< main::foo(1, 2) (in t.pm:10)
   |  there (in t.pm:11)
   +-< global

    [download]
    I haven't tried these, so your mileage may vary.

    Also, read Refactoring by Martin Fowler. Great advice in there about how to cope with legacy pasta.

    stephen

[reply]
[d/l]
Re: Perl Debugging Hell!
by czbsd (Initiate) on Apr 13, 2000 at 23:59 UTC
    The standard perl debugger is quite powerful, but a nicer interface can help. Check out the graphical debugger Devel::ptkdb. Works on any platform where you have perlTK (including *nix, Win, Mac). Invoke with 
        perl -d:ptkdb yourscript.pl

    [download]
    It does very nice pretty-printing of complex data structures, and other niceties.

    - czbsd
[reply]
[d/l]
Re: Perl Debugging Hell!
by chromatic (Archbishop) on Apr 12, 2000 at 20:04 UTC
    Looking at perlman:perldebug I see that the "n" command executes over subroutine calls... beats single stepping. You can also set a one-time breakpoint at a line number or a subroutine (name?) with the "c" command. The "b" command, of course, sets a normal breakpoint on a certain line. You can give it an optional condition.

    Anything beats single stepping. Take a look at perldebug and see if one of the breakpoint options there will help you avoid the Exporter calls.

[reply]
Re: Perl Debugging Hell!
by jbert (Priest) on Apr 13, 2000 at 14:28 UTC
    Hmm. Odd. 'use' is compile time (acts as though it is in a BEGIN {} statement).

    If there are 'use's in evals or 'require's in function calls or similar, you might get some joy from pre-loading all the modules in one go at the beginning.

    You could put together a mondo command line with '-M' options to pull in the modules or stick a 'use All' at the beginning and then have an 'All.pm' which pulled in every module in one place.

    Perl keeps track of which modules have been use'd and require'd so when the rest of the code tries to pull in a module a second time its a no-op.

    Of course, if the author was deeply evil they will have put nice order- and inter-dependent 'BEGIN' clauses in the modules so this approach would break, but hey.

[reply]

Back to Seekers of Perl Wisdom