You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Stas Bekman <st...@stason.org> on 2001/12/14 09:14:09 UTC
colors subs in Apache::TestTrace
In Apache::SmokeTest I use warning/error subs from TestTrace to make the
generated output easy to read and distinguish important prints from less
important. But of course error and warning aren't the right names to
use. What's the best thing to do in this case? I was thinking about
adding a set of other subs to TestTrace derived from the used
highlighting color. e.g. red/yellow (basically a wrapper for
Term::ANSIColor, which also can do different things with
APACHE_TEST_NO_COLOR. What do you think. Look at SmokeTest to see what I
mean.
Also the thread about APACHE_TEST_NO_COLOR didn't come to conclusion,
should we replace the env var with --batch option (or add it as an
alternative)?
_____________________________________________________________________
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://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: colors subs in Apache::TestTrace
Posted by Doug MacEachern <do...@covalent.net>.
On Fri, 14 Dec 2001, Stas Bekman wrote:
> I didn't suggest to change colors, I suggested to add more methods :)
what i'm saying is there should only be one meaning for each color.
> scream "It's a hit!"; # 'blue'
info is blue.
> whisper "nothing important"; # 'yellow'
warning is yellow. etc.
if you want to switch colors in the existing levels, that's ok, but i
don't see why we should have different functions that output the same
color.
Re: colors subs in Apache::TestTrace
Posted by Stas Bekman <st...@stason.org>.
Doug MacEachern wrote:
> On Fri, 14 Dec 2001, Stas Bekman wrote:
>
>
>>In Apache::SmokeTest I use warning/error subs from TestTrace to make the
>>generated output easy to read and distinguish important prints from less
>>important. But of course error and warning aren't the right names to
>>use. What's the best thing to do in this case? I was thinking about
>>adding a set of other subs to TestTrace derived from the used
>>highlighting color. e.g. red/yellow (basically a wrapper for
>>Term::ANSIColor, which also can do different things with
>>APACHE_TEST_NO_COLOR. What do you think. Look at SmokeTest to see what I
>>mean.
>>
>
> i'd like colors to stay the same for the levels..
I didn't suggest to change colors, I suggested to add more methods :)
> but agree that the color
> helps to distinguish the output. i think the right thing to do would be
> to raise the default level to 'info' and start to use 'notice' and
> 'info' for the verbose outputs. if somebody wants less verbose, they can
> turn the level down.
Agreed, but in some cases like smoke testing it's hard to differentiate
between 'notice' and 'info' while coding (I guess because I'm not used
to these two, compared to warning/error :). I want to get out an output
and in some cases make it stand out less sometimes more. e.g. I could
use normal text for least important messages and blue for important
once. Using of red color for non-errors can be confusing if you get used
to red meaning danger.
run t/SMOKE and you will see what I mean.
To conclude I want to have a set of colors (functions), where there is
one very outstanding (e.g. blue cannot use red), one neutral (e.g. no
color?) and one bleak (yellow?), without having them tied to
error..debug levels. e.g.:
scream "It's a hit!"; # 'blue'
say "yet another script compiled"; # 'no color'
whisper "nothing important"; # 'yellow'
I actually like these names :) Makes our code more alive :)
>>Also the thread about APACHE_TEST_NO_COLOR didn't come to conclusion,
>>should we replace the env var with --batch option (or add it as an
>>alternative)?
>>
>
> oh yeah, i forgot to mention, no need for a new option. there is the -t
> file test operator:
> -t Filehandle is opened to a tty.
>
> so if -t STDOUT is true, enable colors, startup counter, etc., else turn
> them off. it will be false for cron jobs or anything that redirects
> stdout, like t/TEST -v > test.log
>
> that can be implemented with a env var or global, doesn't matter to me
> which. an env var can always be used to set the global, overridding the
> -t test.
Assuming that this works cross-platform this is great! I'll implement it
after I finish with my PerlIO/SubProc stuff unless you beat me to it.
_____________________________________________________________________
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://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: colors subs in Apache::TestTrace
Posted by Doug MacEachern <do...@covalent.net>.
On Fri, 14 Dec 2001, Stas Bekman wrote:
> In Apache::SmokeTest I use warning/error subs from TestTrace to make the
> generated output easy to read and distinguish important prints from less
> important. But of course error and warning aren't the right names to
> use. What's the best thing to do in this case? I was thinking about
> adding a set of other subs to TestTrace derived from the used
> highlighting color. e.g. red/yellow (basically a wrapper for
> Term::ANSIColor, which also can do different things with
> APACHE_TEST_NO_COLOR. What do you think. Look at SmokeTest to see what I
> mean.
i'd like colors to stay the same for the levels.. but agree that the color
helps to distinguish the output. i think the right thing to do would be
to raise the default level to 'info' and start to use 'notice' and
'info' for the verbose outputs. if somebody wants less verbose, they can
turn the level down.
> Also the thread about APACHE_TEST_NO_COLOR didn't come to conclusion,
> should we replace the env var with --batch option (or add it as an
> alternative)?
oh yeah, i forgot to mention, no need for a new option. there is the -t
file test operator:
-t Filehandle is opened to a tty.
so if -t STDOUT is true, enable colors, startup counter, etc., else turn
them off. it will be false for cron jobs or anything that redirects
stdout, like t/TEST -v > test.log
that can be implemented with a env var or global, doesn't matter to me
which. an env var can always be used to set the global, overridding the
-t test.