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
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: 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 C to C C for all variables for > +which you get the warning. The C 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