[Mastering-perl] Debugging, Profiling, and Cleaning Up Code

[Sean O'Riordain]

and speaking of logging, what about log4perl ?

cheers,
Sean


On 11/10/06, Florian Merges <fmerges at cpan.org> wrote:
>
>
> 2006/10/11, Adrian Howard <adrianh at quietstars.com>:
> > On 7 Oct 2006, at 11:46, brian d foy wrote:
> > [snip]
> > > I've added a bunch of stuff to the Debugging chapter:
> > >
> > >
> http://www.pair.com/~comdog/mastering_perl/Chapters/04.debugger.html
> >
> > I kinda expected the print/warn section to move on to a discussion of
> > logging modules, does that happen elsewhere? If not that would be
> > trez useful. Pretty much everybody I encounter has some mastery of
> > the print-style of debugging. Far fewer have any idea how to do
> > logging well.
> >
> > I'd stick in a warning about the problems with $SIG{ __DIE__ } and
> > $SIG{ __WARN__ } and persistent environments like mod_perl.
> >
> > fatalsToBrowsers - I'm in the "don't do this on live boxes" school
> > since if you do have a bug it might reveal bad things to evil folk.
> > Maybe worth warning folk of potential dangers?
>
>  This is like the warnings things... but I also agree that the errors should
> go dumped to a log and not to the client. Of course showing an error
> message, but not a program error dump...
>
> > > And I think I'm mostly done with the Profiling chapter:
> > >
> > >
> http://www.pair.com/~comdog/mastering_perl/Chapters/06.profiling.html
> >
> > I'd appreciate a little more emphasis on the dangers of unnecessary
> > optimisation near the start. I've seen people misuse Devel::SmallProf
> > - spending days agonising over two or three "slow" lines that make no
> > damn difference to anything.
> >
> > With Devel::Cover - might be worth mentioning Module::Build's built
> > in support for ./Build testcover.
> >
> > POD coverage modules?
> >
> > Memory profiling? - Devel::Size, Devel::Size::Report, Devel::DumpSizes ?
>
>
> Think givin' a mention to Devel::Size is good, sometimes I see myself using
> it to get an idea how much mem a bunch of objects will need...
>
> > > Next up is the Cleaning Up Code chapter, which need the last half
> > > written. That's all Perl::Critic stuff:
> > >
> > > http://www.pair.com/~comdog/mastering_perl/Chapters/
> > > 07.cleaning_up_code.html
> >
> > Nice apart from:
> >
> > "In general, I recommend turning off warnings once a program is in
> > production. Turn on warnings when you need to test or debug the
> > program, but after that, you don't need them. The warnings will just
> > fill up log files."
>
> This happen, when your code is not clean, hehe }:-), and for thinks that
> should be so, you can turn warnings off selectively...
>
> > which I consider.... odd advice :-) The point of log files is to spot
> > problems. Warnings are often indications of problems. That's why log
> > files filling up with warnings is a /good/ thing. That way you can
> > fix the problem!
>
> Is said that the warnings should be turned off once before releasing, but
> it's like allways, for a little program you do, where is not necessary to
> have something optimized, it really doesn't care... and I think it's better
> to have it one, 'cause so you don't have tu add or uncomment the stanza
> everytime you do a little change...
>
> Thinks about logging and so, modules like Log::Dispatch, and perl4j could
> also be mentioned, I use Log::Dispatch a lot in bigger apps.
>
> > Cheers,
> >
> > Adrian
>
>
> Kind regards,
>
> Florian
>
> > _______________________________________________
> > Mastering-perl mailing list
> > Mastering-perl at theperlreview.com
> >
> http://five.pairlist.net/mailman/listinfo/mastering-perl
> >
>
>
> _______________________________________________
> Mastering-perl mailing list
> Mastering-perl at theperlreview.com
> http://five.pairlist.net/mailman/listinfo/mastering-perl
>
>
>