Mailing-List: contact test-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: test-dev@httpd.apache.org
Message-ID: <3C19C2BC.7050209@stason.org>
Date: Fri, 14 Dec 2001 17:13:32 +0800
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011012
MIME-Version: 1.0
To: test-dev@httpd.apache.org
Subject: Re: colors subs in Apache::TestTrace
References: <Pine.LNX.4.21.0112140036400.31377-100000@localhost>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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/