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 2004/03/02 02:58:36 UTC
A-T: making the debug tracing functionality usable in production?
I'm getting used to use:
debug "foo", \@bar
when writing my code and I want to continue using it in my real modules. The
problem with Apache::TestTrace that even though you can control the tracing
level, they aren't compile time checks. Meaning that it's going to be costly
to keep trace calls in the production code.
What I was thinking is to introduce a subclass of Apache::TestTrace, which
will operate exactly the same as its parent. But it won't be possible to
change the trace level post-compile time, which will allow to optimize away
calls like 'debug' if the level is not right.
Or do you think this functionality doesn't belong to the Apache::Test framework?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: A-T: making the debug tracing functionality usable in production?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>>probably not. see Log::Log4perl and Log::Dispatch for existing
>>>frameworks
>>>so you don't have to reinvent the wheel :)
>>
>>
>>Not so much about reinventing the wheel, but about not creating unneeded
>>dependencies.
>
>
> the whole dependency issue is more of a religious debate. personally, I
> tend to see "no dependencies" it as silly. dependencies are what CPAN is
> all about - I see no need to add (and more importantly, maintain) modules in
> the core distribution that do practically the same thing as other actively
> maintained CPAN modules just because you don't want to require installation
> of additional 3rd party modules when using your own 3rd party ones.
I fail to see what this has to do with "religion". If my modules are
independant they work out of box. Creating dependancies potentially creates
obstacles for my users. .e.g. if the module my module depends on suddenly breaks.
Besides that, I have no problem with dependencies.
>>Or may be it belongs to Apache::Log. or if you don't want to pollute
>>Apache namespace, ModPerl::Log, which we should probably move warn and
>>other calls to anyway, since they aren't a part of Apache API. I like
>>the idea.
>
>
> We already have all kinds of logging stuff in Apache::Log that's Apache API
> specific, so definitely not there.
s/is/is not/?
> but please reconsider adding modules to core that duplicate (or even come
> close to duplicating) available CPAN modules.
I don't have any code, I was just pinging whether there is an interest. Thanks
for the followup, Geoff.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: A-T: making the debug tracing functionality usable in production?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> probably not. see Log::Log4perl and Log::Dispatch for existing
>> frameworks
>> so you don't have to reinvent the wheel :)
>
>
> Not so much about reinventing the wheel, but about not creating unneeded
> dependencies.
the whole dependency issue is more of a religious debate. personally, I
tend to see "no dependencies" it as silly. dependencies are what CPAN is
all about - I see no need to add (and more importantly, maintain) modules in
the core distribution that do practically the same thing as other actively
maintained CPAN modules just because you don't want to require installation
of additional 3rd party modules when using your own 3rd party ones.
>
> Or may be it belongs to Apache::Log. or if you don't want to pollute
> Apache namespace, ModPerl::Log, which we should probably move warn and
> other calls to anyway, since they aren't a part of Apache API. I like
> the idea.
We already have all kinds of logging stuff in Apache::Log that's Apache API
specific, so definitely not there.
but please reconsider adding modules to core that duplicate (or even come
close to duplicating) available CPAN modules.
--Geoff
Re: A-T: making the debug tracing functionality usable in production?
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
> Stas Bekman wrote:
>
>>I'm getting used to use:
>>
>> debug "foo", \@bar
>>
>>when writing my code and I want to continue using it in my real modules.
>>The problem with Apache::TestTrace that even though you can control the
>>tracing level, they aren't compile time checks. Meaning that it's going
>>to be costly to keep trace calls in the production code.
>>
>>What I was thinking is to introduce a subclass of Apache::TestTrace,
>>which will operate exactly the same as its parent. But it won't be
>>possible to change the trace level post-compile time, which will allow
>>to optimize away calls like 'debug' if the level is not right.
>>
>>Or do you think this functionality doesn't belong to the Apache::Test
>>framework?
>
>
> probably not. see Log::Log4perl and Log::Dispatch for existing frameworks
> so you don't have to reinvent the wheel :)
Not so much about reinventing the wheel, but about not creating unneeded
dependencies.
Or may be it belongs to Apache::Log. or if you don't want to pollute Apache
namespace, ModPerl::Log, which we should probably move warn and other calls to
anyway, since they aren't a part of Apache API. I like the idea.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: A-T: making the debug tracing functionality usable in production?
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
Stas Bekman wrote:
> I'm getting used to use:
>
> debug "foo", \@bar
>
> when writing my code and I want to continue using it in my real modules.
> The problem with Apache::TestTrace that even though you can control the
> tracing level, they aren't compile time checks. Meaning that it's going
> to be costly to keep trace calls in the production code.
>
> What I was thinking is to introduce a subclass of Apache::TestTrace,
> which will operate exactly the same as its parent. But it won't be
> possible to change the trace level post-compile time, which will allow
> to optimize away calls like 'debug' if the level is not right.
>
> Or do you think this functionality doesn't belong to the Apache::Test
> framework?
probably not. see Log::Log4perl and Log::Dispatch for existing frameworks
so you don't have to reinvent the wheel :)
--Geoff