You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl-cvs@perl.apache.org by sb...@apache.org on 2001/06/17 17:26:47 UTC
cvs commit: modperl-2.0/Apache-Test/lib/Apache TestRun.pm
sbekman 01/06/17 08:26:47
Modified: Apache-Test/lib/Apache TestRun.pm
Log:
start the server if -run-tests is used before the server was started
Revision Changes Path
1.5 +4 -0 modperl-2.0/Apache-Test/lib/Apache/TestRun.pm
Index: TestRun.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- TestRun.pm 2001/04/04 17:27:16 1.4
+++ TestRun.pm 2001/06/17 15:26:46 1.5
@@ -241,6 +241,10 @@
if ($self->{opts}->{'start-httpd'}) {
exit 1 unless $self->{server}->start;
+ } elsif ($self->{opts}->{'run-tests'} and !$self->{server}->ping) {
+ # make sure that the server is up when -run-tests is used
+ print "the test server wasn't not running: starting it...\n";
+ exit 1 unless $self->{server}->start;
}
}
Re: colorizing the build's output
Posted by Ken Williams <ke...@forum.swarthmore.edu>.
dougm@covalent.net (Doug MacEachern) wrote:
>On Sun, 17 Jun 2001, Stas Bekman wrote:
>> What do you think about adding some semantics for the debug printing
>> during 'make test'. So users can visually tell warnings from errors, and
>> errors from notice statements.
>>
>> so we can use:
>>
>> mpt_warn("this is a warning");
>> mpt_error("this is an arror");
>> mpt_notice("this is a notice");
>>
>> (mpt stands for mod_perl_test) and
>>
>> sub mpt_error { print "!!!: ", join "\n", @_}
>> sub mpt_warn { print "***: ", join "\n", @_}
>> sub mpt_notice { print "---: ", join "\n", @_}
>>
>> or similar semantics, and the functions could handle the wrapping too (and
>> thus appending the right preamble to the beginning of every line).
>>
>> or may be we want to change the debug prints only for warn/error ones, so
>> the normal printing will stay as it is now.
>>
>> we can also overload these subs with a set of subs which use Curses (for
>> those who have it installed) and have the output colorized like
>> /usr/bin/colorgcc does. The latter uses Term::ANSIColor which seems to
>> come with the core perl (at least 5.6.0, not sure about earlier versions).
>>
>> finally we could ucfirst() the beginning of sentences :)
>
>this would be useful, maybe in its own module ModPerl::Trace that
>exports error(), warning(), notice(), debug(), etc.
Heck, why not call it Test::Notify or something more generic. Nothing
mod_perl-specific here. My guess is that Schwern would welcome the
fancy output into the Test:: class. =)
------------------- -------------------
Ken Williams Last Bastion of Euclidity
ken@forum.swarthmore.edu The Math Forum
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: colorizing the build's output
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 21 Jun 2001, Stas Bekman wrote:
> Another issue that bothers me is the use of globals to control the
> behavior of the module ($Level and $LogFH) if somebody forgets to localize
> these when overriding it breaks the behavior of this module in other
> places. Should we use OOP instead?
nah, stick with the exported functions and globals, much more convenient
in this case.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: colorizing the build's output
Posted by Stas Bekman <st...@stason.org>.
On Wed, 20 Jun 2001, Doug MacEachern wrote:
> On Thu, 21 Jun 2001, Stas Bekman wrote:
>
> > OK, here is the module that handles all the issues discussed today. See
> > the pod section for the docs and test example.
>
> looks good. could we make warnings be yellow like colorgcc?
Of course. In fact the color-map should be reviewed, I didn't give it much
thought. So your suggestions are welcome. The thing to remember is that
users might have terms running with different backgrounds, so somehow we
should make sure that prints will be still seen.
> i also realized that use vars is not required, just can't have the
> our's inside the BEGIN block, this will work:
> --- Apache/TestTrace.pm~ Wed Jun 20 17:42:34 2001
> +++ Apache/TestTrace.pm Wed Jun 20 17:42:43 2001
> @@ -3,7 +3,7 @@
> use strict;
>
> use Exporter ();
> -use vars qw(@Levels @Utils);
> +our (@Levels, @Utils);
Ok.
Another issue that bothers me is the use of globals to control the
behavior of the module ($Level and $LogFH) if somebody forgets to localize
these when overriding it breaks the behavior of this module in other
places. Should we use OOP instead?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: colorizing the build's output
Posted by Doug MacEachern <do...@covalent.net>.
On Thu, 21 Jun 2001, Stas Bekman wrote:
> OK, here is the module that handles all the issues discussed today. See
> the pod section for the docs and test example.
looks good. could we make warnings be yellow like colorgcc?
i also realized that use vars is not required, just can't have the
our's inside the BEGIN block, this will work:
--- Apache/TestTrace.pm~ Wed Jun 20 17:42:34 2001
+++ Apache/TestTrace.pm Wed Jun 20 17:42:43 2001
@@ -3,7 +3,7 @@
use strict;
use Exporter ();
-use vars qw(@Levels @Utils);
+our (@Levels, @Utils);
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: colorizing the build's output
Posted by Stas Bekman <st...@stason.org>.
OK, here is the module that handles all the issues discussed today. See
the pod section for the docs and test example.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: colorizing the build's output
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 20 Jun 2001, Stas Bekman wrote:
> we will be incompatible with 'warn' only, since it's taken by Perl
> already.
yeah, same as apache (which are really from syslog) would be great. just
use warning instead warn. of course, we are just building/testing, not
running a service, so emerg, alert and crit levels are not all that useful
when just error will do. but let's keep those anyway so we can have a
pretty rainbow of colors when things blow up :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: colorizing the build's output
Posted by Stas Bekman <st...@stason.org>.
On Wed, 20 Jun 2001, Stas Bekman wrote:
> On Tue, 19 Jun 2001, Doug MacEachern wrote:
> > do you plan to implement a $Level similar to Apache's LogLevel, so we
> > have the default set to error or warning for normal builds, but people
> > can turn it up for more verbose output. that would be cool.
also what levels do we want to support? Apache specifies these:
---------------
emerg
Emergencies - system is unusable.
"Child cannot open lock file. Exiting"
alert
Action must be taken immediately.
"getpwuid: couldn't determine user name from uid"
crit
Critical Conditions.
"socket: Failed to get a socket, exiting child"
error
Error conditions.
"Premature end of script headers"
warn
Warning conditions.
"child process 1234 did not exit, sending another SIGHUP"
notice
Normal but significant condition.
"httpd: caught SIGBUS, attempting to dump core in ..."
info
Informational.
"Server seems busy, (you may need to increase StartServers, or
Min/MaxSpareServers)..."
debug
Debug-level messages
"Opening config file ..."
---------------
we will be incompatible with 'warn' only, since it's taken by Perl
already.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: colorizing the build's output
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 20 Jun 2001, Stas Bekman wrote:
> > looks good, but i would change the first part to:
> > *expand = HAS_DUMPER ? sub { map { ... } } : sub { @_ };
>
> can you please explain why yours is better?
easier to read and expand() could be used outside the module whereas
my $expand cannot.
> I've also sent an email to Michael Schwern asking him whether he would
> like to integrate it into Test::Harness.
of course, this stuff doesn't really fit under Test:: either. we're not
testing anything, just tracing messages. i see it being more useful in
the build than the 'make test'. Log::Trace or something maybe, but i
would still stick with Apache::TestTrace for now and worry about the name
later, Apache::Trace can just become a wrapper around it.
> we cannot really use the import() trick here if we want to be able to rely
> on %opts.
nah, i wouldn't bother with import. the level should normally just be set
once.
> Also we might want to raise the level only for a specific code section,
> since we might want to debug only a specific code snippet:
yes indeed.
> Another possibility is to use package's global to make the level tweaking:
>
> {
> local $Apache::TestTrace::LEVEL = 'debug';
> ...
> }
> # $Apache::TestTrace::LEVEL gets restored to the previous value
that would be the most handy. can we do Level rather than LEVEL? i like
$StudlyCaps style for global variables that are 'public'.
> but then we will have to decide for each trace function whether to do
> something or to be NOP at run-time.
that's fine, we don't need to worry that much about speed with this
module. in general for the configure/build/xs-generation/test modules,
anything that is not actually used inside mod_perl we should prefer
usefulness over speed.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: colorizing the build's output
Posted by Stas Bekman <st...@stason.org>.
On Tue, 19 Jun 2001, Doug MacEachern wrote:
> On Wed, 20 Jun 2001, Stas Bekman wrote:
>
> > Can you give me an example of how would you want to use those? Why would
> > you want to have notify functions have this capability.
>
> can you give me examples of how you would want to use dumper() ?
> they would be the same reasons.
got it :)
> > Something like this?
> >
> > my $expand = sub {
> > HAS_DUMPER ?
> > map { ref $_ ? Data::Dumper::Dumper($_) : $_ } @_ :
> > @_;
> > }
> >
> > sub c_trace {
> > my $level = shift;
> > my $fh = \*STDERR; #could configure to something else
> > print $fh $colors{$level},
> > join("\n", $expand->(@_), ''), $colors{reset};
> > }
>
> looks good, but i would change the first part to:
> *expand = HAS_DUMPER ? sub { map { ... } } : sub { @_ };
can you please explain why yours is better? HAS_DUMPER is a compile time
constant, which means that if we have Data::Dumper my code resolves into:
my $expand = sub {
map { ref $_ ? Data::Dumper::Dumper($_) : $_ } @_;
}
so is $expand->(@_) resolving overhead makes it slower than aliased
expand(@_) in your version?
> > So shell we start with Apache::TestTrace for now?
>
> sounds good.
I've also sent an email to Michael Schwern asking him whether he would
like to integrate it into Test::Harness.
> do you plan to implement a $Level similar to Apache's LogLevel, so we
> have the default set to error or warning for normal builds, but people
> can turn it up for more verbose output. that would be cool.
yup, sounds cool! Will add this functionality. Just a question about
the way to change $Level. Is this how you would like it to be?
use Apache::TestTrace; # use $Level == warning
# setting hardcoded
Apache::TestTrace::level('info'); # $Level == info
# setting driven by command line args
Apache::TestTrace::level($opts{level})
if $opts{level}; # use whichever level was passed
we cannot really use the import() trick here if we want to be able to rely
on %opts.
Also we might want to raise the level only for a specific code section,
since we might want to debug only a specific code snippet:
my $old_level = Apache::TestTrace::level('debug');
...
Apache::TestTrace::level($old_level);
Another possibility is to use package's global to make the level tweaking:
{
local $Apache::TestTrace::LEVEL = 'debug';
...
}
# $Apache::TestTrace::LEVEL gets restored to the previous value
but then we will have to decide for each trace function whether to do
something or to be NOP at run-time.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: colorizing the build's output
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 20 Jun 2001, Stas Bekman wrote:
> Can you give me an example of how would you want to use those? Why would
> you want to have notify functions have this capability.
can you give me examples of how you would want to use dumper() ?
they would be the same reasons.
> Something like this?
>
> my $expand = sub {
> HAS_DUMPER ?
> map { ref $_ ? Data::Dumper::Dumper($_) : $_ } @_ :
> @_;
> }
>
> sub c_trace {
> my $level = shift;
> my $fh = \*STDERR; #could configure to something else
> print $fh $colors{$level},
> join("\n", $expand->(@_), ''), $colors{reset};
> }
looks good, but i would change the first part to:
*expand = HAS_DUMPER ? sub { map { ... } } : sub { @_ };
> So shell we start with Apache::TestTrace for now?
sounds good.
do you plan to implement a $Level similar to Apache's
LogLevel, so we have the default set to error or warning for normal
builds, but people can turn it up for more verbose output. that would be
cool.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: colorizing the build's output
Posted by Stas Bekman <st...@stason.org>.
On Tue, 19 Jun 2001, Doug MacEachern wrote:
> On Wed, 20 Jun 2001, Stas Bekman wrote:
>
> > $ perl -MModPerl::Trace=error,dumper,warning,notice,debug,todo -lwe \
> > 'error "error"; warning "warning"; notice "notice"; debug "debug"; \
> > todo "todo"; dumper [1..3]'
>
> cool. howbout instead of a dumper function, have the trace
> function(s) dump any args that are ref()'s ?
Can you give me an example of how would you want to use those? Why would
you want to have notify functions have this capability.
Something like this?
my $expand = sub {
HAS_DUMPER ?
map { ref $_ ? Data::Dumper::Dumper($_) : $_ } @_ :
@_;
}
sub c_trace {
my $level = shift;
my $fh = \*STDERR; #could configure to something else
print $fh $colors{$level},
join("\n", $expand->(@_), ''), $colors{reset};
}
> > is this OK? Apache-Test becomes dependant on ModPerl::, or was it
> > dependant already?
>
> no, Apache-Test must be independant of Apache-Test/../, but
> modperl-2.0 can depend on Apache-Test. so something like
> Apache::TestTrace would be ok.
I'm thinking about Ken's suggestion to have this code make its way into
Test:: . I think the main problem is back-compatibility. Authors relying
on Test:: will have to require the new version of it, in order for the new
code using these idioms to work. Though I'll ask Michael.
So shell we start with Apache::TestTrace for now?
> a few suggestions that would make it easier for things like supporting
> dumper() of args passed to trace functions, adding new levels, etc..
Yeah, sounds cool, you have beaten me to the code's beauty :)
> package ModPerl::Trace;
>
> use strict;
>
> use Exporter ();
> use vars qw(@Levels @Utils); #vars.pm is still useful after all
>
> BEGIN {
> @Levels = qw(warning debug notice error todo);
> @Utils = qw(dumper);
> }
>
> our @ISA = qw(Exporter);
> our @EXPORT = (@Levels, @Utils);
> our $VERSION = '0.01';
>
> use subs @Levels;
>
> use constant HAS_COLOR => eval {
> require Term::ANSIColor;
> };
>
> use constant HAS_DUMPER => eval {
> require Data::Dumper;
> };
>
> my %colors = ();
>
> if (HAS_COLOR) {
> $Term::ANSIColor::AUTORESET = 1;
> %colors = (
> error => Term::ANSIColor::color('bold red'),
> warning => Term::ANSIColor::color('blue'),
> notice => Term::ANSIColor::color('reset'),
> debug => Term::ANSIColor::color('green'),
> todo => Term::ANSIColor::color('underline'),
> reset => Term::ANSIColor::color('reset'),
> );
> }
> else {
> %colors = (
> error => '!!!',
> warning => '***',
> notice => ' ',
> debug => '==>',
> todo => 'todo',
> );
> }
>
> sub c_trace {
> my $level = shift;
> my $fh = \*STDERR; #could configure to something else
> print $fh $colors{$level}, join("\n", @_, ''), $colors{reset};
> }
>
> sub nc_trace {
> my $level = shift;
> my $fh = \*STDERR; #could configure to something else
> print $fh map { sprintf "%-4s: %s\n", $colors{$level}, $_ } @_;
> }
>
> {
> my $trace = HAS_COLOR ? \&c_trace : \&nc_trace;
>
> for my $level (@Levels) {
> no strict 'refs';
> *$level = sub { $trace->($level, @_) };
> }
> }
>
> *dumper = HAS_DUMPER ?
> sub { print STDERR +Data::Dumper::Dumper(@_) } :
> sub { error "Install Data::Dumper to use dumper" };
>
> 1;
> __END__
>
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: colorizing the build's output
Posted by Doug MacEachern <do...@covalent.net>.
On Wed, 20 Jun 2001, Stas Bekman wrote:
> $ perl -MModPerl::Trace=error,dumper,warning,notice,debug,todo -lwe \
> 'error "error"; warning "warning"; notice "notice"; debug "debug"; \
> todo "todo"; dumper [1..3]'
cool. howbout instead of a dumper function, have the trace
function(s) dump any args that are ref()'s ?
> is this OK? Apache-Test becomes dependant on ModPerl::, or was it
> dependant already?
no, Apache-Test must be independant of Apache-Test/../, but modperl-2.0
can depend on Apache-Test.
so something like Apache::TestTrace would be ok.
a few suggestions that would make it easier for things like supporting
dumper() of args passed to trace functions, adding new levels, etc..
package ModPerl::Trace;
use strict;
use Exporter ();
use vars qw(@Levels @Utils); #vars.pm is still useful after all
BEGIN {
@Levels = qw(warning debug notice error todo);
@Utils = qw(dumper);
}
our @ISA = qw(Exporter);
our @EXPORT = (@Levels, @Utils);
our $VERSION = '0.01';
use subs @Levels;
use constant HAS_COLOR => eval {
require Term::ANSIColor;
};
use constant HAS_DUMPER => eval {
require Data::Dumper;
};
my %colors = ();
if (HAS_COLOR) {
$Term::ANSIColor::AUTORESET = 1;
%colors = (
error => Term::ANSIColor::color('bold red'),
warning => Term::ANSIColor::color('blue'),
notice => Term::ANSIColor::color('reset'),
debug => Term::ANSIColor::color('green'),
todo => Term::ANSIColor::color('underline'),
reset => Term::ANSIColor::color('reset'),
);
}
else {
%colors = (
error => '!!!',
warning => '***',
notice => ' ',
debug => '==>',
todo => 'todo',
);
}
sub c_trace {
my $level = shift;
my $fh = \*STDERR; #could configure to something else
print $fh $colors{$level}, join("\n", @_, ''), $colors{reset};
}
sub nc_trace {
my $level = shift;
my $fh = \*STDERR; #could configure to something else
print $fh map { sprintf "%-4s: %s\n", $colors{$level}, $_ } @_;
}
{
my $trace = HAS_COLOR ? \&c_trace : \&nc_trace;
for my $level (@Levels) {
no strict 'refs';
*$level = sub { $trace->($level, @_) };
}
}
*dumper = HAS_DUMPER ?
sub { print STDERR +Data::Dumper::Dumper(@_) } :
sub { error "Install Data::Dumper to use dumper" };
1;
__END__
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: colorizing the build's output
Posted by Stas Bekman <st...@stason.org>.
On Mon, 18 Jun 2001, Doug MacEachern wrote:
> On Sun, 17 Jun 2001, Stas Bekman wrote:
>
> >
> > What do you think about adding some semantics for the debug printing
> > during 'make test'. So users can visually tell warnings from errors, and
> > errors from notice statements.
> >
> > so we can use:
> >
> > mpt_warn("this is a warning");
> > mpt_error("this is an arror");
> > mpt_notice("this is a notice");
> >
> > (mpt stands for mod_perl_test) and
> >
> > sub mpt_error { print "!!!: ", join "\n", @_}
> > sub mpt_warn { print "***: ", join "\n", @_}
> > sub mpt_notice { print "---: ", join "\n", @_}
> >
> > or similar semantics, and the functions could handle the wrapping too (and
> > thus appending the right preamble to the beginning of every line).
> >
> > or may be we want to change the debug prints only for warn/error ones, so
> > the normal printing will stay as it is now.
> >
> > we can also overload these subs with a set of subs which use Curses (for
> > those who have it installed) and have the output colorized like
> > /usr/bin/colorgcc does. The latter uses Term::ANSIColor which seems to
> > come with the core perl (at least 5.6.0, not sure about earlier versions).
> >
> > finally we could ucfirst() the beginning of sentences :)
>
> this would be useful, maybe in its own module ModPerl::Trace that
> exports error(), warning(), notice(), debug(), etc.
Attached the first version of this module. Test with:
$ perl -MModPerl::Trace=error,dumper,warning,notice,debug,todo -lwe \
'error "error"; warning "warning"; notice "notice"; debug "debug"; \
todo "todo"; dumper [1..3]'
I've tried it in the Apache::TestRun and it works, the only thing I'm not
sure about is the need to extend @INC:
package Apache::TestRun;
...
use lib qw(./lib);
use ModPerl::Trace;
...
is this OK? Apache-Test becomes dependant on ModPerl::, or was it
dependant already?
Of course feel free to adjust the colors :)
I've also added the todo() and dumper() methods, which I find useful
during development process.
Another feature that would be nice to add is to be able to overload any of
these subs with NOPS via import(), so for example we could leave the debug
calls around the system and enable them only when we want. Sort of like
Carp.pm does.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: colorizing the build's output
Posted by Doug MacEachern <do...@covalent.net>.
On Sun, 17 Jun 2001, Stas Bekman wrote:
>
> What do you think about adding some semantics for the debug printing
> during 'make test'. So users can visually tell warnings from errors, and
> errors from notice statements.
>
> so we can use:
>
> mpt_warn("this is a warning");
> mpt_error("this is an arror");
> mpt_notice("this is a notice");
>
> (mpt stands for mod_perl_test) and
>
> sub mpt_error { print "!!!: ", join "\n", @_}
> sub mpt_warn { print "***: ", join "\n", @_}
> sub mpt_notice { print "---: ", join "\n", @_}
>
> or similar semantics, and the functions could handle the wrapping too (and
> thus appending the right preamble to the beginning of every line).
>
> or may be we want to change the debug prints only for warn/error ones, so
> the normal printing will stay as it is now.
>
> we can also overload these subs with a set of subs which use Curses (for
> those who have it installed) and have the output colorized like
> /usr/bin/colorgcc does. The latter uses Term::ANSIColor which seems to
> come with the core perl (at least 5.6.0, not sure about earlier versions).
>
> finally we could ucfirst() the beginning of sentences :)
this would be useful, maybe in its own module ModPerl::Trace that
exports error(), warning(), notice(), debug(), etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
colorizing the build's output
Posted by Stas Bekman <st...@stason.org>.
What do you think about adding some semantics for the debug printing
during 'make test'. So users can visually tell warnings from errors, and
errors from notice statements.
so we can use:
mpt_warn("this is a warning");
mpt_error("this is an arror");
mpt_notice("this is a notice");
(mpt stands for mod_perl_test) and
sub mpt_error { print "!!!: ", join "\n", @_}
sub mpt_warn { print "***: ", join "\n", @_}
sub mpt_notice { print "---: ", join "\n", @_}
or similar semantics, and the functions could handle the wrapping too (and
thus appending the right preamble to the beginning of every line).
or may be we want to change the debug prints only for warn/error ones, so
the normal printing will stay as it is now.
we can also overload these subs with a set of subs which use Curses (for
those who have it installed) and have the output colorized like
/usr/bin/colorgcc does. The latter uses Term::ANSIColor which seems to
come with the core perl (at least 5.6.0, not sure about earlier versions).
finally we could ucfirst() the beginning of sentences :)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org