There is a good technique in the mod_perl cookbock that talks about using
a Debug module with exported constants. If you program to the API where
all of your code is compiled into bytecode at server startup into
discrete packages then this means that all of your debug if() sections
sprinkled throughout the code are not included as part of the run time
footprint. This can be quite nice if you have largish chunks of code that
should run only in debug mode.
I guess this might work for registry scripts too, the 1st time the are
compiled.
On Thu, 9 Jan 2003 [EMAIL PROTECTED] wrote:
>
> > Do you develop with an xterm tailing the logs, an emacs
> > window (or other
> > editor) to edit the script and/or the packages (and on some occassions
> > httpd.conf), and a web browser (on an alternate virtual
> > desktop)?
>
> Bingo. :-)
>
> Do you
> > pepper code with :
> >
> > print "option:" . $option{$foo . "<br>" if $debug;
>
> If it's a longer-term debugging option that I might want again later then I
> might make a debug() method where I'll do
> debug('this worked ok') and the debug() method might examine a flag to see
> whether it should do anything with that message.
> Or a log() method that recognizes various levels of messages and obeys a
> debug_level setting or something. I once used a Java package (the name
> escapes me but it was probably something simple like jLog) that worked sort
> of this way, though it also had some xml config files and such... anyways,
> I'm sure there are plenty of perl modules to do something similar, but the
> debug() is a fairly effective 2 minute alternative. If's it just a quick
> one-time debug, I'll typically just use a warn or similar.
>
> >
> > Fairly low tech, huh.
> >
> > At apachecon, a speaker (who neither bragged nor rambled)
> > mentioned lwp
> > use instead of (or to complement) the web browser portion.
> >
> > Will the use of lwp instead of a browser improve my coding
> > ability (either
> > in terms of speed or just improving my perl coding)? Seems
> > like I'd have
> > to spend too much time with the lwp script (tell it to first
> > request the
> > page then choose option A and B then hit the "submit" button ... )
>
> This sounds more like a testing suite than regular old
> debugging-while-you-go. Probably a place for both.
>
> >
> > Is there some way to improve this cycle : edit code ->
> > refresh browser ->
> > possibly look at the error log -> edit code -> ...
>
> Honestly, this method has always been very efficient for us and most of the
> time we don't need anything more sophisticated for devel/debug. Now for
> more formal testing, that gets trickier for us and we're currently looking
> for a good way to build some automated tests of our code and our web
> interface without it getting too unwieldy. This will probably be where we
> spend a lot of time in the first part of the year. Maybe LWP will be handy
> here.
>
> -Fran
>
--
+ Jon Larsen; Chief Technology Officer, Richweb.com
+ GnuPG Public Key http://richweb.com/jlarsen.gpg
+ Richweb.com: Providing Internet-Based Business Solutions since 1995
+ Business Telephone: (804) 359.2220
+ Jon Larsen Cell Phone: (804) 307.6939
