any perl tool to create a flow of perl scripts

Discussion in 'Perl Misc' started by iarunkumar@gmail.com, Feb 24, 2007.

  1. Guest

    We have hundreds of perl scripts being used. It's hard to debug and
    don't know the flow like which one is calling which. Is there any tool
    that creates a flow chart like giving a visual view of multiple perl
    scripts.

    Thanks
    Arun
     
    , Feb 24, 2007
    #1
    1. Advertising

  2. Uri Guttman Guest

    >>>>> "i" == iarunkumar <> writes:

    i> We have hundreds of perl scripts being used. It's hard to debug and
    i> don't know the flow like which one is calling which. Is there any tool
    i> that creates a flow chart like giving a visual view of multiple perl
    i> scripts.

    sounds like a bad design to begin with. having scripts calling scripts
    is slower and harder to debug. convert most/many to modules and you will
    be able to track their usage better, improve speed and ease
    maintenance. otherwise tracking will need something like strace to see
    what procs get called.

    in other words, hire a quality perl professional to refactor your mess
    into a cleanly designed system.

    uri

    --
    Uri Guttman ------ -------- http://www.stemsystems.com
    --Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
    Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
     
    Uri Guttman, Feb 24, 2007
    #2
    1. Advertising

  3. Re: any perl tool to create a flow of perl scripts :-[

    Uri Guttman wrote:

    >>>>>> "i" == iarunkumar <> writes:

    >
    > i> We have hundreds of perl scripts being used. It's hard to debug and
    > i> don't know the flow like which one is calling which. Is there any
    > tool i> that creates a flow chart like giving a visual view of multiple
    > perl i> scripts.
    >
    > sounds like a bad design to begin with. having scripts calling scripts
    > is slower and harder to debug. convert most/many to modules and you will
    > be able to track their usage better, improve speed and ease
    > maintenance. otherwise tracking will need something like strace to see
    > what procs get called.
    >
    > in other words, hire a quality perl professional to refactor your mess
    > into a cleanly designed system.
    >
    > uri
    >

    :-[
     
    john.swilting, Feb 24, 2007
    #3
  4. Re: any perl tool to create a flow of perl scripts :-[ (co)

    john.swilting wrote:

    > Uri Guttman wrote:
    >
    >>>>>>> "i" == iarunkumar <> writes:

    >>
    >> i> We have hundreds of perl scripts being used. It's hard to debug and
    >> i> don't know the flow like which one is calling which. Is there any
    >> tool i> that creates a flow chart like giving a visual view of multiple
    >> perl i> scripts.
    >>
    >> sounds like a bad design to begin with. having scripts calling scripts
    >> is slower and harder to debug. convert most/many to modules and you will
    >> be able to track their usage better, improve speed and ease
    >> maintenance. otherwise tracking will need something like strace to see
    >> what procs get called.
    >>
    >> in other words, hire a quality perl professional to refactor your mess
    >> into a cleanly designed system.
    >>
    >> uri
    >>

    > :-[

    me, I start to improve me. I do not post any more in France. it does not
    like me
    (co)
     
    john.swilting, Feb 24, 2007
    #4
  5. Re: any perl tool to create a flow of perl scripts :-[ (co)

    Michele Dondi wrote:

    > Here, instead, I bet most people like you as much as to acknowledge
    > your contributions to the group along the lines of acknowledged people
    > in

    if I can help it, I would post a solution
     
    john.swilting, Feb 24, 2007
    #5
  6. Guest

    wrote:
    > We have hundreds of perl scripts being used. It's hard to debug and
    > don't know the flow like which one is calling which.


    How is this calling taking place?

    > Is there any tool
    > that creates a flow chart like giving a visual view of multiple perl
    > scripts.


    I'd use the system's grep, find, etc.. Or maybe Perl.

    Xho

    --
    -------------------- http://NewsReader.Com/ --------------------
    Usenet Newsgroup Service $9.95/Month 30GB
     
    , Feb 24, 2007
    #6
  7. wrote:
    > We have hundreds of perl scripts being used. It's hard to debug and
    > don't know the flow like which one is calling which. Is there any tool
    > that creates a flow chart like giving a visual view of multiple perl
    > scripts.


    Autodia will help you to analyse individual scripts and the modules they
    use. If your applications aren't modularized at all then this is going
    to be of limited value.

    Mark
     
    Mark Clements, Feb 24, 2007
    #7
  8. steve Guest

    On Feb 24, 7:46 pm, Mark Clements <>
    wrote:
    > wrote:
    > > We have hundreds of perl scripts being used. It's hard to debug and
    > > don't know the flow like which one is calling which. Is there any tool
    > > that creates a flow chart like giving a visual view of multiple perl
    > > scripts.

    >
    > Autodia will help you to analyse individual scripts and the modules they
    > use. If your applications aren't modularized at all then this is going
    > to be of limited value.
    >
    > Mark


    Hi Arun,
    I'm working on something similar for testcases that have
    dependancies on other testcases, build a graphical representation of
    these dependancies

    steve
     
    steve, Feb 25, 2007
    #8
  9. gf Guest

    On Feb 23, 7:50 pm, wrote:
    > We have hundreds of perl scripts being used. It's hard to debug and
    > don't know the flow like which one is calling which. Is there any tool
    > that creates a flow chart like giving a visual view of multiple perl
    > scripts.


    This is a messy solution, but you've already got a messy problem so it
    can only help...

    Write a bit of code to add a line to each of the Perl scripts that are
    in your execution paths. Since you don't know for sure what's called
    by what you need the line in all scripts.

    That line needs to append a trace message to a single file that you
    define using a date/time stamp and the name of the running program,
    plus its passed in arguments. You might even want to dump the
    environment too if you suspect there's significant information being
    used there too.

    Something like this (untested line) should work...

    1 and open (my $__LOG, '>>', '/absolute/path/to/writable/log'),
    print $__LOG scalar(localtime),"\t","$0 @ARGV\n",
    close($__LOG);

    (I wrapped the line to help it survive formatting by news browsers so
    unwrap it into a single line.)

    You can insert that line into your scripts by running something like
    this untested and simplistic code...

    #!/usr/bin/perl

    use warnings;
    use strict;

    my $code = q{
    1 and open (my $__LOG, '>>', '/absolute/path/to/writable/log'),
    print $__LOG scalar(localtime),"\t$0 @ARGV\n",
    close($__LOG);
    };
    foreach (@ARGV)
    {
    if ( open( my $FI, '<', $_ ) && open( my $FO, '>', "$_.new" ) )
    {
    while (<$FI>)
    {
    print $FO $code, "\n" if ( $. == 2 );
    print $FO $_;
    }
    }
    close $FO;
    close $FI;
    rename $_, "$_.old";
    rename "$_.new", $_;
    }

    Then, as the application runs each script will update the log file
    showing when they were called and what their parameters were.

    You'll have a starting point to track down the execution flow then.

    As you get things figured out or don't want something writing to the
    log, change the leading 1 to a 0 in the code files you understand and
    that file will 'gnore the log statement.

    Just be very aware that this can create a very large log file in a
    very short time, depending on the activity and structure of the
    overall application.

    Greg
     
    gf, Feb 26, 2007
    #9
  10. blazar Guest

    On 26 Feb, 18:53, "gf" <> wrote:
    > On Feb 23, 7:50 pm, wrote:


    > Something like this (untested line) should work...
    >
    > 1 and open (my $__LOG, '>>', '/absolute/path/to/writable/log'),
    > print $__LOG scalar(localtime),"\t","$0 @ARGV\n",
    > close($__LOG);

    [snip]
    > As you get things figured out or don't want something writing to the
    > log, change the leading 1 to a 0 in the code files you understand and
    > that file will 'gnore the log statement.


    1) At first I didn't understand the C<1 and> bit. In light of the
    explanation above, I do. Yet I find it somehow confusing. People
    generally use a C<DEBUG> constant set at the top of their scripts
    instead. I understand that here the situation is slightly different,
    because it's not a matter of debugging single scripts but a whole
    bunch of them, and I see the usefluness of a simple "tag" to be
    recognized and automatically changed. Anyway a thing like

    use constant DEBUG => 1;

    is also easy to find and replace with

    use constant DEBUG => 0;

    Alternatively one can use an environment variable, and even a mixed
    approach like thus:

    use constant DEBUG => $ENV{THIS_JOB_DEBUG};

    So that she can turn it definitely on or off for individual scripts.

    2) Your code as suggested won't work: a lexical variable is not
    available in the same statement that defines it:

    $ cat foo.pl
    #!/usr/bin/perl

    use strict;
    use warnings;

    1 and open (my $__LOG, '>>', '/absolute/path/to/writable/log'),
    print $__LOG scalar(localtime),"\t","$0 @ARGV\n",
    close($__LOG);

    __END__

    $ perl foo.pl
    Global symbol "$__LOG" requires explicit package name at foo.pl line
    7.
    Global symbol "$__LOG" requires explicit package name at foo.pl line
    8.
    Execution of foo.pl aborted due to compilation errors.

    Though you may convert it to something that *does* work:

    if (DEBUG) {
    open my $__LOG, '>>', '/absolute/path/to/writable/log'
    or die "$!\n!";
    print $__LOG scalar(localtime),"\t","$0 @ARGV\n",
    }

    3) In addition to your conceptually good suggestion, I don't know
    *how* each script "calls" other ones, but the OP may want to "trap"
    each of them by overloading some core functions or operators, if that
    is possible.
     
    blazar, Feb 27, 2007
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jj

    OT: C/C++ flow tool?

    jj, Jan 31, 2004, in forum: C++
    Replies:
    2
    Views:
    467
    stelios xanthakis
    Jan 31, 2004
  2. Hemanth

    tool to convert c code to flow chart

    Hemanth, May 20, 2004, in forum: C Programming
    Replies:
    3
    Views:
    6,955
    Mark A. Odell
    May 20, 2004
  3. Jack Dowson
    Replies:
    0
    Views:
    467
    Jack Dowson
    May 7, 2007
  4. IJALAB

    Tool to create Perl based scripts

    IJALAB, Feb 20, 2007, in forum: Perl Misc
    Replies:
    3
    Views:
    109
    Billy Patton
    Feb 22, 2007
  5. Replies:
    13
    Views:
    553
    Anno Siegel
    Sep 10, 2007
Loading...

Share This Page