On Friday, January 10, 2003, at 12:07 pm, Mark Fowler wrote:
On Thu, 9 Jan 2003, Jim Martinez wrote:
Is there some way to improve this cycle : edit code -> refresh
browser ->
possibly look at the error log -> edit code -> ...
No one seems to have mentioned WWW::Mechanize (or if they have I'
On Thu, 9 Jan 2003, Jim Martinez wrote:
> Is there some way to improve this cycle : edit code -> refresh browser ->
> possibly look at the error log -> edit code -> ...
No one seems to have mentioned WWW::Mechanize (or if they have I've missed
it.) It's a simple module that allows you to interac
> 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)? Do you
> pepper code with :
>
> print "option:" . $option{$foo . "" if $debug;
>
Jim Martinez wrote:
[...]
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
On Thu, 9 Jan 2003, Thomas Bolioli wrote:
> I use my debugging module
> (http://cpan.perl.org/authors/id/T/TB/TBOLIOLI/Log-AndError-0.99.tar.gz)
> which prints to stderr (hence I got bit by the mod_cgi issues with
> read/write deadlocks on pipes) while tailing the logs, etc. I am looking
> to incl
I use my debugging module
(http://cpan.perl.org/authors/id/T/TB/TBOLIOLI/Log-AndError-0.99.tar.gz)
which prints to stderr (hence I got bit by the mod_cgi issues with
read/write deadlocks on pipes) while tailing the logs, etc. I am looking
to include a syslog and other output drivers to my mod w
mpm writes:
> Debugging of the applications now looks like:
> $ced->log('warn',"No price for this product")
Here's an an alternative that we've evolved from Modula-2 to C to Java
to Perl :-) Firstly, I try to distinguish between stuff I always
want to see and debugging messages. The former we ca
like.
Wes
Andrew Wyllie <[EMAIL PROTECTED]> on 01/09/2003 04:22:43 PM
Please respond to [EMAIL PROTECTED]
To:Jim Martinez <[EMAIL PROTECTED]>
cc:mod_perl list <[EMAIL PROTECTED]>
Subject:Re: development techniques
On Thu, 09 Jan 2003, Jim Martinez wrote:
(sni
On Thu, 9 Jan 2003, Jim Martinez wrote:
> Do you develop with an xterm tailing the logs, an emacs window ...
Yep.
> print "option:" . $option{$foo . "" if $debug;
> Fairly low tech, huh.
We used to do this. Along with the move from registry to full mod_perl,
We changed the way that we did this
--
I find "ab" to be very quick to type
&ab('processing...');&ab(\%whats_in_here);
use Data::Dumper;
sub ab {
return if exists $ENV{SERVER} && $ENV{SERVER} eq 'PRODUCTION';
my $msg=shift;
if (ref $msg) {
print STDERR
On Thu, 09 Jan 2003, Jim Martinez wrote:
> The start of a new year has me thinking of how I can improve things.
> Like the way I develop, debug and test code.
>
> 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 so
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 t
> 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{$f
13 matches
Mail list logo
