Re: PATCH porting.pod First Mystery
[EMAIL PROTECTED] wrote: In private mail Stas Bekman [EMAIL PROTECTED] writes: oops, that should be the modperl list... at modperl-docs we discuss mostly site/docs techical issues and there are very few people on this list to get enough exposure for this kind of feedback request. Patch for The First Mystery section of the mod_perl porting guide as per my conversation with Stas at YAPC::Europe::2003. Takes out the suggestion of creating a Perl4-style library in the same directory as a means to port CGI scripts. Replaces it with something simpler and more reliable. Nice, but: +The easiest and the fastest way to solve the nested subroutines +problem is to change Cmy to Clocal Cour for all variables for +which you get the warning. The Chandler subroutines are never ... [...] + local our $counter = 0; local our? That should be either local or our, but not both. Do I miss something? The rest looks good, but that's not the simplest solution as you have to modify the variables. Granted, the original simplest solution has its troubles. I've also changed If you put your code into a library or module... to If you put all your code into modules... because if you put your code into a Perl4-style library and then require it in more than one registry script terrible things happen. I don't think this is the place to explain this so I think the guide should just say modules and leave it at that. Probably the library problem should be explained elsewhere in the guide. Once this one is sorted out, a patch for perl_reference.pod will follow. Sure, sounds good to me. __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DProf problems
i'll double check, but i'm fairly certain it's loaded first.
what if a module is loaded after the fact, but like this: eval { use
$module };
some modules are dynamically loaded at run time depending on certain
situations.
On Friday, August 29, 2003, at 04:26 PM, Stas Bekman wrote:
Brian Hirt wrote:
I've installed Apache::DProf, but it seems hardly any of the calls
are profiled. dprofpp shouws MOF::Dispatcher::handler as taking up
100% of the time, but there is no information recorded in for calls
within that function. MOF::Dispatcher::handler is calling thousands
of other functions and there is absolutely no record of any of those
calls in tmon.out.
Any ideas an what's going on? I'm running mp1.27 and compiled it
with EVERYTHING=1
Remember that any PerlHandler that was pulled in before Apache::DProf
in the httpd.conf or startup.pl file will not have code-debugging
information inserted. Make sure that you load before any code that you
plan to profile.
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DProf problems
On Sat, 2003-08-30 at 15:34, Brian Hirt wrote:
i'll double check, but i'm fairly certain it's loaded first.
If you post your conf, we could probably help you more.
what if a module is loaded after the fact, but like this: eval { use
$module };
Doesn't matter. You just have to initialize the debugger. I do this by
calling Apache::DB-init because I don't want to actually profile
anything during startup but I do need the debugger turned on when I
compile code at startup for DProf to work.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
