[30159] in Perl-Users-Digest
Perl-Users Digest, Issue: 1402 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Mar 29 00:09:41 2008
Date: Fri, 28 Mar 2008 21:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 28 Mar 2008 Volume: 11 Number: 1402
Today's topics:
Capturing CPU and other execution Stats <pgodfrin@gmail.com>
Re: Capturing CPU and other execution Stats <ben@morrow.me.uk>
Re: Capturing CPU and other execution Stats <pgodfrin@gmail.com>
Re: Capturing CPU and other execution Stats <pgodfrin@gmail.com>
child process dying if syswrite fails? <elwood@agouros.de>
Re: child process dying if syswrite fails? <ben@morrow.me.uk>
Re: empty variables - getting rid of "uninitialized val <allergic-to-spam@no-spam-allowed.org>
Re: empty variables - getting rid of "uninitialized val <willem@stack.nl>
Error.pm still maintained? <miknrene@drizzle.com>
Re: Error.pm still maintained? <smallpond@juno.com>
Re: Error.pm still maintained? <spamtrap@dot-app.org>
Re: Installing module Apache2::Reload failed <ben@morrow.me.uk>
Re: Installing module Apache2::Reload failed ronny204@googlemail.com
Re: Readline using foreach and while <szrRE@szromanMO.comVE>
Re: Readline using foreach and while <ben@morrow.me.uk>
Re: sockets giving me gray hairs. server keeps dying <BLOCKSPAMfishfry@your-mailbox.com>
Re: using cgi.pm <glex_no-spam@qwest-spam-no.invalid>
Re: using cgi.pm <john@castleamber.com>
Visualising / overview tools <grantdenkinson@hushmail.com>
Re: Visualising / overview tools <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 28 Mar 2008 09:57:51 -0700 (PDT)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Capturing CPU and other execution Stats
Message-Id: <c7cbef50-8b01-4586-a5a2-410db3ee3eae@i29g2000prf.googlegroups.com>
Greetings,
Is there a way to capture runtime stats? I like to report stuff at the
end of my run, including how many CPU seconds and Elapsed seconds.
I've already used Time:HiRes clock(), but I'm looking for some more
granularity. Eventually I'll be setting up some simulations and I'd
like to see what kind of stats I can get out of my programs.
Any thoughts?
thanks,
pg
------------------------------
Date: Fri, 28 Mar 2008 17:11:36 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Capturing CPU and other execution Stats
Message-Id: <8flvb5-9i4.ln1@osiris.mauzo.dyndns.org>
Quoth pgodfrin <pgodfrin@gmail.com>:
> Greetings,
>
> Is there a way to capture runtime stats? I like to report stuff at the
> end of my run, including how many CPU seconds and Elapsed seconds.
> I've already used Time:HiRes clock(), but I'm looking for some more
> granularity. Eventually I'll be setting up some simulations and I'd
> like to see what kind of stats I can get out of my programs.
The canonical answer to this is BSD::Resource, assuming your system
supports it.
Ben
------------------------------
Date: Fri, 28 Mar 2008 10:42:36 -0700 (PDT)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Re: Capturing CPU and other execution Stats
Message-Id: <e7f9da19-938c-4e39-a479-d8e2f857837a@c19g2000prf.googlegroups.com>
On Mar 28, 12:11 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth pgodfrin <pgodf...@gmail.com>:
>
> > Greetings,
>
> > Is there a way to capture runtime stats? I like to report stuff at the
> > end of my run, including how many CPU seconds and Elapsed seconds.
> > I've already used Time:HiRes clock(), but I'm looking for some more
> > granularity. Eventually I'll be setting up some simulations and I'd
> > like to see what kind of stats I can get out of my programs.
>
> The canonical answer to this is BSD::Resource, assuming your system
> supports it.
>
> Ben
Thanks Ben...
pg
p.s. How are you?
------------------------------
Date: Fri, 28 Mar 2008 12:06:54 -0700 (PDT)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Re: Capturing CPU and other execution Stats
Message-Id: <ab547f69-dae1-4a78-a786-9655453ee0a4@i12g2000prf.googlegroups.com>
On Mar 28, 12:42 pm, pgodfrin <pgodf...@gmail.com> wrote:
> On Mar 28, 12:11 pm, Ben Morrow <b...@morrow.me.uk> wrote:
>
> > Quoth pgodfrin <pgodf...@gmail.com>:
>
> > > Greetings,
>
> > > Is there a way to capture runtime stats? I like to report stuff at the
> > > end of my run, including how many CPU seconds and Elapsed seconds.
> > > I've already used Time:HiRes clock(), but I'm looking for some more
> > > granularity. Eventually I'll be setting up some simulations and I'd
> > > like to see what kind of stats I can get out of my programs.
>
> > The canonical answer to this is BSD::Resource, assuming your system
> > supports it.
>
> > Ben
>
> Thanks Ben...
> pg
>
> p.s. How are you?
worked like a charm!
pg
------------------------------
Date: Fri, 28 Mar 2008 15:36:08 +0000 (UTC)
From: Konstantinos Agouros <elwood@agouros.de>
Subject: child process dying if syswrite fails?
Message-Id: <1206718568.231538@rumba>
Hi,
I encountered a strange problem. I have an application that has a few
sockets open. To notify the other side that I am 'finished' I do a
shutdown on the socket. Because I am lazy I do a syswrite on the socket
after the shutdown which of course fails. However I found that the whole
childprocess doing this dies if I do the syswrite. This used not to happen.
The whole thing is on Gentoo Linux using perl 5.8.8.
Anybody can comment on this?
Regards,
Konstantin
--
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: elwood@agouros.de
Otkerstr. 28, 81547 Muenchen, Germany. Tel +49 89 69370185
----------------------------------------------------------------------------
"Captain, this ship will not survive the forming of the cosmos." B'Elana Torres
------------------------------
Date: Fri, 28 Mar 2008 15:56:32 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: child process dying if syswrite fails?
Message-Id: <g2hvb5-mr3.ln1@osiris.mauzo.dyndns.org>
Quoth Konstantinos Agouros <elwood@agouros.de>:
>
> I encountered a strange problem. I have an application that has a few
> sockets open. To notify the other side that I am 'finished' I do a
> shutdown on the socket. Because I am lazy I do a syswrite on the socket
> after the shutdown which of course fails. However I found that the whole
> childprocess doing this dies if I do the syswrite. This used not to happen.
> The whole thing is on Gentoo Linux using perl 5.8.8.
If you write to a socket (or pipe) which is closed, your process will be
sent SIGPIPE. The default action for SIGPIPE is to terminate the
process: this is useful in pipelines when the reading process exits
early. You can ignore this signal, in which case the write will fail
with EPIPE instead.
Ben
------------------------------
Date: Fri, 28 Mar 2008 19:57:05 +0100 (CET)
From: Jim Cochrane <allergic-to-spam@no-spam-allowed.org>
Subject: Re: empty variables - getting rid of "uninitialized value" warnings?
Message-Id: <slrnfuqfs1.74o.allergic-to-spam@no-spam-allowed.org>
On 2008-03-28, Tomasz Chmielewski <tch@nospam.syneticon.net> wrote:
> I have perl code which should do some action only if:
>
> - the variable does not begin with "#" (commented out),
> - the variable is not empty
>
>
>
> use strict;
> use warnings;
>
> my @array = ("# Comment", "/usr/bin/binary --test", "");
>
> foreach my $var (@array) {
>
> my @execargs = split(/#/, $var);
>
> if ( $execargs[0] ne '' ) { print "$var 0: |$execargs[0]|\n" }
>
> }
If I understand what you're trying to do (and perhaps I don't), you want
something like this:
#!/usr/bin/perl
use strict;
use warnings;
my @array = ("# Comment",
"/usr/bin/binary --test1",
"/usr/bin/binary --test2",
"/usr/bin/binary\t--test3",
" /usr/bin/binary --test4",
"");
for my $var (@array) {
if (not $var or $var =~ /^#/) {
next;
}
my @execargs = split(' ', $var);
print 'arg array: ' . join(', ', @execargs) . "\n";
}
>
>
> Unfortunately, it shows uninitialized value warnings for the empty
> variable (""):
>
> $ perl test.pl
> /usr/bin/binary --test 0: |/usr/bin/binary --test|
> Use of uninitialized value $execargs[0] in string ne at test.pl line 14.
>
>
>
> Using:
>
> if ( defined $execargs[0] ) { print "$var 0: |$execargs[0]|\n" }
>
> is not a solution either, because $execargs[0] will be defined for a
> case with "# Comment" and an undesired action will be made for this element:
>
>
> $ perl test.pl
> # Comment 0: ||
> /usr/bin/binary --test 0: |/usr/bin/binary --test|
>
>
>
> How can I get rid of warnings if I make tests with "if" and some
> variables are empty?
>
> Should I just ignore it? Or use "no warnings" just for that piece of
> code throwing a warning?
>
>
>
--
------------------------------
Date: Fri, 28 Mar 2008 19:18:19 +0000 (UTC)
From: Willem <willem@stack.nl>
Subject: Re: empty variables - getting rid of "uninitialized value" warnings?
Message-Id: <slrnfuqh3r.7t8.willem@snail.stack.nl>
Tomasz wrote:
) I have perl code which should do some action only if:
)
) - the variable does not begin with "#" (commented out),
) - the variable is not empty
That's not quite what your code indicates is your intention.
It looks more like:
- Print only the part of a line before the '#'
- Don't print of the above is empty.
) my @array = ("# Comment", "/usr/bin/binary --test", "");
)
) foreach my $var (@array) {
)
) my @execargs = split(/#/, $var);
)
) if ( $execargs[0] ne '' ) { print "$var 0: |$execargs[0]|\n" }
)
) }
)
)
) Unfortunately, it shows uninitialized value warnings for the empty
) variable (""):
)
) $ perl test.pl
) /usr/bin/binary --test 0: |/usr/bin/binary --test|
) Use of uninitialized value $execargs[0] in string ne at test.pl line 14.
)
)
)
) Using:
)
) if ( defined $execargs[0] ) { print "$var 0: |$execargs[0]|\n" }
)
) is not a solution either, because $execargs[0] will be defined for a
) case with "# Comment" and an undesired action will be made for this element:
How about just:
if ($execargs[0]) ?
And how about:
my ($execarg) = split(/#/, $var);
and then:
if ($execarg) { ... }
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Fri, 28 Mar 2008 11:02:08 -0700
From: Michael Slass <miknrene@drizzle.com>
Subject: Error.pm still maintained?
Message-Id: <m38x02u3q7.fsf@drizzle.com>
Hi:
I'm finding some bugs in Error.pm, and searches for Error on the perl
groups return only older (+1Y) postings. Is Error.pm still being
maintained? If not, is there a better try/catch/finally for perl5?
If so, what?
Thank you.
--
Mike Slass
------------------------------
Date: Fri, 28 Mar 2008 13:21:39 -0700 (PDT)
From: smallpond <smallpond@juno.com>
Subject: Re: Error.pm still maintained?
Message-Id: <60d4683a-46ce-48db-971f-05b0aa14dc4f@m71g2000hse.googlegroups.com>
On Mar 28, 2:02 pm, Michael Slass <miknr...@drizzle.com> wrote:
> Hi:
>
> I'm finding some bugs in Error.pm, and searches for Error on the perl
> groups return only older (+1Y) postings. Is Error.pm still being
> maintained? If not, is there a better try/catch/finally for perl5?
> If so, what?
>
> Thank you.
>
> --
> Mike Slass
CPAN shows the latest change was in January, so yes: actively
maintained.
The changelog is only about the build files and examples, so no: there
are no reported bugs, despite extensive testing over the last 10
years.
What evidence of bugs do you have?
------------------------------
Date: Fri, 28 Mar 2008 17:07:09 -0400
From: Sherman Pendley <spamtrap@dot-app.org>
Subject: Re: Error.pm still maintained?
Message-Id: <m18x027e2q.fsf@dot-app.org>
Michael Slass <miknrene@drizzle.com> writes:
> I'm finding some bugs in Error.pm, and searches for Error on the perl
> groups return only older (+1Y) postings. Is Error.pm still being
> maintained?
It looks like it to me. Search.cpan.org indicates that the most recent
release was on January 25, 2008. Have you tried emailing the maintainer
listed in its docs?
sherm--
--
My blog: http://shermspace.blogspot.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
------------------------------
Date: Fri, 28 Mar 2008 15:49:56 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Installing module Apache2::Reload failed
Message-Id: <4mgvb5-mr3.ln1@osiris.mauzo.dyndns.org>
Quoth ronny204@googlemail.com:
> Thank you very much for your response. Here are the significant lines
> out of Makefile.PL:
>
> -------------------- 8< --------------------
>
> if ($wanted == 1) {
> require_mod_perl();
> if ($mod_perl::VERSION >= 1.99) {
> # so we don't pick 2.0 version if 1.0 is wanted
> die "You don't seem to have mod_perl 1.0 installed";
> }
> $selected = 1;
> }
> elsif ($wanted == 2) {
> #warn "Looking for mod_perl 2.0";
> require_mod_perl();
> if ($mod_perl::VERSION < 2.0) {
> die "You don't seem to have mod_perl 2.0 installed";
> }
> $selected = 2;
> }
>
> -------------------- 8< --------------------
>
> Our mod_perl -Version is 1.999021. This is greater than 1.99 and
> smaller than 2.0 ... so both options can not work. This is very strange.
It appears (though of course ICBW, because I don't really understand any
of this :) ) that mod_perl versions 1.99* are actually early versions of
mod_perl2 (that is, they require Apache 2, not Apache 1). I surmise that
you have Apache 2 installed: is this correct? It seems that
Apache2::Reload doesn't work with these older versions, so you will need
to install mod_perl-2.0, or rather mod_perl-2.0.3, since 2.0 itself is
no longer available. I would say that the error message is less than
helpful; something like 'To use this module with mod_perl2 you must have
at least v2.0 installed' would be much clearer, and just emitting a
straightforward dependancy on mod_perl-2.0 would be better still.
Ben
------------------------------
Date: Fri, 28 Mar 2008 09:27:09 -0700 (PDT)
From: ronny204@googlemail.com
Subject: Re: Installing module Apache2::Reload failed
Message-Id: <2b47a85b-46d2-47aa-a34e-054873638aac@e6g2000prf.googlegroups.com>
Dear Ben,
I think your idea is correct. But its very strange, at least to me,
that there ist no version working with our mod_perl 1.99... .
So I am going to check if we can change our mod_perl -version.
Ronny
------------------------------
Date: Fri, 28 Mar 2008 19:07:22 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: Readline using foreach and while
Message-Id: <fsk88r0347@news2.newsguy.com>
Ben Morrow wrote:
> Quoth "szr" <szrRE@szromanMO.comVE>:
>>
>> Actually the behaviors of "for (@ary)" and "for (@ary, ())" do seem
>> consistant if you really think about it. The resulting list is what
>> it iterates over (from the first element, to what ever *count* is...
>> in the former case *count* come fro mthe array, and since the
>> condition is checked at the start of each iteration, if the array is
>> added to, the count is incremented.
>>
>> In the latter case, a new list is created from contents of @ary + an
>> empty list, which gives you a new list, which contains the values of
>> @ary, but is a new seperate list, and thus is not effected by
>> changes to @ary because it has it's own copy of @ary's values.
>
> OK, now explain to me why
>
> my @ary = qw/a b c/;
> print map { /c/ and push @ary, 'd'; $_ } @ary;
>
> *doesn't* work like that :).
Actually it does. The difference is, map doesn't recheck the count every
time around like for/foreach do. If you print the contents of @ary after
the line with the map statement, it does indeed contain 'd' at the end.
This behavior seems to correct, as one would likely expect that the list
map returns when it is finished to be the same length as the one
/passed/ into map at the start. If you pass a 3 element list, you should
get back a 3 element list, should you not? Or do you consider this to be
a bug?
However, consider:
my @ary = qw/a b c/;
print map { /c/ and $_ = 'd'; $_ } @ary;
__OUTPUT__
abd
$_ is aliased to the current array element just like in for. Again, the
only difference I see if that map doesn't recheck the count of the
passed list for each iteration. Well, that and map returns a list :-)
To me, this behavior is part of what separates map from for/foreach.
--
szr
------------------------------
Date: Sat, 29 Mar 2008 02:48:53 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Readline using foreach and while
Message-Id: <l9n0c5-4jv.ln1@osiris.mauzo.dyndns.org>
Quoth "szr" <szrRE@szromanMO.comVE>:
> Ben Morrow wrote:
> > Quoth "szr" <szrRE@szromanMO.comVE>:
> >>
> >> Actually the behaviors of "for (@ary)" and "for (@ary, ())" do seem
> >> consistant if you really think about it. The resulting list is what
> >> it iterates over (from the first element, to what ever *count* is...
> >> in the former case *count* come fro mthe array, and since the
> >> condition is checked at the start of each iteration, if the array is
> >> added to, the count is incremented.
> >>
> >> In the latter case, a new list is created from contents of @ary + an
> >> empty list, which gives you a new list, which contains the values of
> >> @ary, but is a new seperate list, and thus is not effected by
> >> changes to @ary because it has it's own copy of @ary's values.
> >
> > OK, now explain to me why
> >
> > my @ary = qw/a b c/;
> > print map { /c/ and push @ary, 'd'; $_ } @ary;
> >
> > *doesn't* work like that :).
>
> Actually it does. The difference is, map doesn't recheck the count every
> time around like for/foreach do. If you print the contents of @ary after
> the line with the map statement, it does indeed contain 'd' at the end.
> This behavior seems to correct, as one would likely expect that the list
> map returns when it is finished to be the same length as the one
> /passed/ into map at the start. If you pass a 3 element list, you should
> get back a 3 element list, should you not?
Absolutely not. my %h = map { $_ => 1 } qw/a b c/; is quite a common
idiom.
<snip>
> $_ is aliased to the current array element just like in for. Again, the
> only difference I see if that map doesn't recheck the count of the
> passed list for each iteration.
No, you're misunderstanding the difference between a list and an array.
Evaluating an array in list context returns a list of its elements *as
they are now*; under most circumstances, it returns a list of aliases to
those elements, but any changes to the order of the elements in @ary are
not propagated into the list. Consider
my @ary = qw/a b c/;
sub foo {
my @keep = map "$_", @_; # kill the aliasing
unshift @ary, 'h';
$_[$_] .= $keep[$_] for 0..$#_;
}
foo @ary;
print for @ary;
> To me, this behavior is part of what separates map from for/foreach.
It separates for (LIST) from everything else that accepts a LIST. This is
why I called it 'weird'.
Ben
------------------------------
Date: Fri, 28 Mar 2008 20:42:33 -0700
From: fishfry <BLOCKSPAMfishfry@your-mailbox.com>
Subject: Re: sockets giving me gray hairs. server keeps dying
Message-Id: <BLOCKSPAMfishfry-44664A.20423328032008@comcast.dca.giganews.com>
In article
<584aaebe-3585-409f-b29c-6be83ba52669@s12g2000prg.googlegroups.com>,
lekonna <lekonna@gmail.com> wrote:
> Hi guys,
> i'm having bit of a hard time getting my very simple multiplexing
> socket server staying alive. It keeps exiting without giving any
> messages, and since i'm running the bugger in while(1) loop i don't
> quite get why the heck it does that.
>
One thing you can do any time a program is "dying for no reason," [which
of course really means, dying for some reason that we don't yet
understand :-)] is to declare a DIE handler, and in the handler, write a
log message and a stack trace.
Secondly, in the same vein, your program should already be copiously
sprinkled with log messages, saying "I'm doing this," and, "I'm getting
ready to do that." Of course you will disable those messages when you
roll your code to production; but during development, and especially
during EARLY development, they are invaluable. If you had a lot of log
messages in your code, you'd know the last thing your server did before
it died.
> Its a very basic echo server with some added features for keeping
> track of users. Basicly i wanted to learn how to use sockets in flash
> and needed something to echo the poo that i send back to me so i came
> up with this quick and dirty solution. Now unfortunately it seems that
> the trusty old work-horse perl keeps dying on me.
>
One thing I truly know in this world is that sockets work perfectly well
in Perl. I'm going to go way out on a limb here and say that the problem
is probably in your code :-)
> Heres the link to attachr with syntax highlighted version of the
> server implementation.
> http://attachr.com/10605
>
> very basic server with some ugly xml hacks in it.
>
> Is there a way to enable some sort of debug info on what actually goes
> wrong?
I didn't look at your code. But if you take my suggestions to write log
messages before and after every interesting thing your program does
(startup, init, creating/opening/connecting sockets, etc.); and
implementing DIE and WARN handlers, you will soon see what's going on.
The idea is to equip your program with the means to debug itself.
One more thing that comes to mind is that people learning to write
servers often have trouble with the logic of handling a connection
request using the accept() function. To service a connection request you
have to fork a child process to handle that client; or you have to
handle the client yourself, managing multiple sockets: the listening
socket, on which you receive connection requests; and one for each
connected client. Typically you need to use non-blocking sockets in
conjunction with the select() call. [And note that "select" is very
unfortunately overloaded in Perl to a totally different function that
has the exact same name but has nothing to do with it!]
It wouldn't hurt to review your accept() logic.
Hope this helps.
------------------------------
Date: Fri, 28 Mar 2008 10:36:22 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: using cgi.pm
Message-Id: <47ed1076$0$89876$815e3792@news.qwest.net>
Ela wrote:
> "Joost Diepenmaat" <joost@zeekat.nl> wrote in message
> news:877ifotgms.fsf@zeekat.nl...
>> In general, you just don't do that. If you want to put processing code
>> in separate files, just use those files from the same CGI program. IOW,
>> use modules. That's more efficient and less error prone than trying
>> to invoke stand-alone scripts from each other (not to mention that doing
>> that will probably not work out of the box for CGI scripts that read
>> POST data).
>>
>> HTH,
>> Joost.
>
> But in the sense of putting the search and fetch functions in the same cgi,
> how come results can be generated after accepting users' input parameters? A
> simple example based on my simplified codes will be appreciated~
>
> #!/usr/bin/perl
>
> use CGI qw(:standard);
>
> $query = new CGI;
No need to do that when using :standard. You can simply call
the methods and you can use one print for multiple values.
print header(),
startform(),
'Title: ', textfield(-name=>'title', -justification=>'RIGHT'),
submit(-name=>'button_name', -value=>'Get !'),
endform();
No idea what the 'justification' attribute for an input element does.
>
> print $query->header;
>
> print $query->startform;
> print "Title: ",$query->textfield(-name=>'title', -justification=>'RIGHT');
>
> print $query->submit(-name=>'button_name', -value=>'Get !');
> print $query->endform;
if ( my $title = $query->param('title') )
{
# possibly validate what's in $title before using it..
# use $title for something
# print the results as HTML
}
> print $query->end_html;
>
> #the following print can be executed successfully but the resultant page is
> just wield....
> print $query->param('title');
> print "<BR>";
>
>
------------------------------
Date: 28 Mar 2008 18:44:42 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: using cgi.pm
Message-Id: <Xns9A6F81A796B70castleamber@130.133.1.4>
"Ela" <ela@yantai.org> wrote:
> $query = new CGI;
IMO: You might want to name that scalar $cgi
> print $query->header;
So this ^^ looks less silly (again, IMO).
--
John
http://johnbokma.com/perl/
------------------------------
Date: Fri, 28 Mar 2008 08:29:21 -0700 (PDT)
From: Grant Denkinson <grantdenkinson@hushmail.com>
Subject: Visualising / overview tools
Message-Id: <dc2f5567-1e97-4f2d-88a2-3c7c238d8447@e23g2000prf.googlegroups.com>
Hi all.
I'm taking over a scientific programming project from a colleague,
part
of which is in about 60000 lines of perl.
Does anyone have recommendations for good tools to help me get an
overview of the code, perhaps some sort of visualisation of what calls
what etc.? We run Linux.
Grant
------------------------------
Date: Fri, 28 Mar 2008 15:53:44 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Visualising / overview tools
Message-Id: <8tgvb5-mr3.ln1@osiris.mauzo.dyndns.org>
Quoth Grant Denkinson <grantdenkinson@hushmail.com>:
> Hi all.
> I'm taking over a scientific programming project from a colleague,
> part
> of which is in about 60000 lines of perl.
>
> Does anyone have recommendations for good tools to help me get an
> overview of the code, perhaps some sort of visualisation of what calls
> what etc.? We run Linux.
B::Xref will generate a full cross-reference of what calls what, but
with a large program the output may be to unwieldy to be terribly
useful. How modular is the code, and how well documented? I would have
expected this sort of thing to be fairly clear from the docs.
Ben
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 1402
***************************************
