Re: Best approach for loading several modules
Thanks for the tip - its something I will definitely explore. My entire gripe with this problem has not been with performance or efficiency but with readability and easy maintainability of the many scripts in our main application - but we are getting there - and the great thing is there are so many options. Our current proprietary system (which embeds a C/BASIC type language in the HTML pages) doesn't scale well no matter how much hardware we throw at it, but has the benefit of having all the "messy" stuff like middleware and database connections, session handling etc. hidden away. It will be a case of culture shock for the developers to suddenly have to explicity include all the modules they need and perform all the initialisation stuff - so we are trying to make it as simple as possible to migrate, without a large increase in the size of the scripts. > Are you using OO perl and inheritance? I'm late on this thread, but what > about use'ing a common module which then use'es all the other modules > you need? It's well worth the effort IMHO... > > I realise the actual code isn't duplicated - but the script itself still > > needs the list of "use" directives regardless of whether you pre-load them > > and there doesn't seem to be an easy way to factor this common block of > > unsightly directives out into one file for use in multiple scripts that > > share the same resources.
Re: Best approach for loading several modules
Martin Wood wrote: > > > but code isn't duplicated if you pre-load your modules: > > > http://perl.apache.org/guide/performance.html#Preload_Perl_Modules_at_Server > > _S > > I realise the actual code isn't duplicated - but the script itself still > needs the list of "use" directives regardless of whether you pre-load them > and there doesn't seem to be an easy way to factor this common block of > unsightly directives out into one file for use in multiple scripts that > share the same resources. Are you using OO perl and inheritance? I'm late on this thread, but what about use'ing a common module which then use'es all the other modules you need? It's well worth the effort IMHO... -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
[OT] Re: Best approach for loading several modules
On Thu, 11 May 2000, Martin Wood wrote: > >Please read the sections posted by Geoff and others. The *already* posted > >link: > >http://perl.apache.org/guide/config.html#The_Confusion_with_use_at_the_ > >answers your question. > > Damn mod_perl guide, much too comprehensive for its own good! :) We are currently looking for the search engine that will simplify the using experience. But you still have to know the right keywords :) > > Please invest some time into reading before crying "help". Thank you. > > Believe me, I have had those infamous purple and cyan pages on screen all I didn't want to spoil you the surprise, but it's going to be the plain B&W starting from the next release. Blame Eric for that :) __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: Best approach for loading several modules
>Please read the sections posted by Geoff and others. The *already* posted >link: >http://perl.apache.org/guide/config.html#The_Confusion_with_use_at_the_ >answers your question. Damn mod_perl guide, much too comprehensive for its own good! :) > Please invest some time into reading before crying "help". Thank you. Believe me, I have had those infamous purple and cyan pages on screen all week! Just had difficulty finding a solution that would satisfy all of our initial requirements - hence the post (which I have no regrets of - from one day of list replies I can already see where we were going wrong with the horrible solution we were trying to implement, just needed to be pointed in the right direction. Thanks guys)
Re: Best approach for loading several modules
On Thu, 11 May 2000, Martin Wood wrote: > > but code isn't duplicated if you pre-load your modules: > > > http://perl.apache.org/guide/performance.html#Preload_Perl_Modules_at_Server > > _S > > I realise the actual code isn't duplicated - but the script itself still > needs the list of "use" directives regardless of whether you pre-load them > and there doesn't seem to be an easy way to factor this common block of > unsightly directives out into one file for use in multiple scripts that > share the same resources. Please read the sections posted by Geoff and others. The *already* posted link: http://perl.apache.org/guide/config.html#The_Confusion_with_use_at_the_ answers your question. Please invest some time into reading before crying "help". Thank you. __ Stas Bekman | JAm_pH--Just Another mod_perl Hacker http://stason.org/ | mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] | http://perl.orghttp://stason.org/TULARC/ http://singlesheaven.com| http://perlmonth.com http://sourcegarden.org --
Re: Best approach for loading several modules
Martin Wood wrote:
>
> Thanks for the replies so far all - things are already becoming clearer.
>
> > If you add a "standard" module to your set, how will it affect
> > existing apps if they don't directly need it or call it? Why have the
> > "use" statement at all if that particular module is not being used?
>
> So pre-load all modules needed for the site, but still selectively "use" the
> ones needed in each script and pray the list of common modules used doesn't
> change often! Good job we have a Vim macro guru on-site :)
>
> There just seems something inherently bad to me about having a lot of
> duplicate sections of code across 100+ scripts - wouldn't it be easier if
> there was some way all these use module directives could be filtered out
> into one "load common boring stuff" line and not having to worry about
> namespace problems?
>
You could do it with something like this:
for my $package (@PACKAGES) {
for my $module (@MODULES) {
eval "package $package; use $module; 1;";
}
}
This would then load all your default symbols for all modules
into all of your packages. Each Apache::Registry script has
its own package namespace however, so you will still have to
do your uses for the scripts, but if you have decomped most
of your code out of your Registry scripts, so that subs are
in their own packages, then you won't have a problem. So put
your subs in a common package, and then you will only have
one to "use" in each script.
Note that certain web solutions like Apache::ASP compile all
scripts into the same package namespace, so that if you use'd
modules in your global.asa, they would load all the relevant
symbols for all scripts when the global.asa is compiled.
I imagine one day that there might be some Apache::Registry
subclass that might compile all scripts into the same package
too, which you could name, and might help alleviate this problem.
-- Joshua
_
Joshua Chamas Chamas Enterprises Inc.
NodeWorks >> free web link monitoring Huntington Beach, CA USA
http://www.nodeworks.com1-714-625-4051
Re: Best approach for loading several modules
On Thu, 11 May 2000, Martin Wood wrote: > Our Apache::Registry CGIs need access to a dozen or so core modules - is > there an elegant solution to loading these without seeing a dozen or so use > statements at the head of the script? Yes. As Vivek pointed out, you can move them all into a startup.pl that you pull in from httpd.conf with PerlRequire in your httpd.conf. If you don't need to import subroutines fom the modules (which ideally you wouldn't, since it wastes some memory) you can then just remove the use calls from the individual scripts. On the other hand, if you must have the use statements because the modules need to export some subs into the namespace of each script, you could use the C preprocessor on your perl code. Take a look at this: http://theoryx5.uwinnipeg.ca/CPAN/data/Filter/Filter/cpp.html Of course, you can also just continue to use "do common.pl", but put it in BEGIN block so it doesn't run on every request. - Perrin
Re: Best approach for loading several modules
> but code isn't duplicated if you pre-load your modules: > http://perl.apache.org/guide/performance.html#Preload_Perl_Modules_at_Server > _S I realise the actual code isn't duplicated - but the script itself still needs the list of "use" directives regardless of whether you pre-load them and there doesn't seem to be an easy way to factor this common block of unsightly directives out into one file for use in multiple scripts that share the same resources. Martin
RE: Best approach for loading several modules
> -Original Message- > From: Martin Wood [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 11, 2000 10:38 AM > To: [EMAIL PROTECTED] > Subject: Re: Best approach for loading several modules > > > Thanks for the replies so far all - things are already > becoming clearer. > > > If you add a "standard" module to your set, how will it affect > > existing apps if they don't directly need it or call it? > Why have the > > "use" statement at all if that particular module is not being used? > > So pre-load all modules needed for the site, but still > selectively "use" the > ones needed in each script and pray the list of common > modules used doesn't > change often! http://perl.apache.org/guide/config.html#The_Confusion_with_use_at_the_ > Good job we have a Vim macro guru on-site :) > > There just seems something inherently bad to me about having a lot of > duplicate sections of code across 100+ scripts - but code isn't duplicated if you pre-load your modules: http://perl.apache.org/guide/performance.html#Preload_Perl_Modules_at_Server _S as Vivek said earlier, in general, the guide makes for wonderful reading :) --Geoff > wouldn't it > be easier if > there was some way all these use module directives could be > filtered out > into one "load common boring stuff" line and not having to worry about > namespace problems? > > Martin >
Re: Best approach for loading several modules
Thanks for the replies so far all - things are already becoming clearer. > If you add a "standard" module to your set, how will it affect > existing apps if they don't directly need it or call it? Why have the > "use" statement at all if that particular module is not being used? So pre-load all modules needed for the site, but still selectively "use" the ones needed in each script and pray the list of common modules used doesn't change often! Good job we have a Vim macro guru on-site :) There just seems something inherently bad to me about having a lot of duplicate sections of code across 100+ scripts - wouldn't it be easier if there was some way all these use module directives could be filtered out into one "load common boring stuff" line and not having to worry about namespace problems? Martin
Re: Best approach for loading several modules
> "MW" == Martin Wood <[EMAIL PROTECTED]> writes: MW> Our Apache::Registry CGIs need access to a dozen or so core modules - is MW> there an elegant solution to loading these without seeing a dozen or so use MW> statements at the head of the script? (We have over 100 different CGIs that The "use" statement does two things: 1) it loads the module if not already done and 2) it calls import() on the module to import any symbols into the current name space. If you add a "standard" module to your set, how will it affect existing apps if they don't directly need it or call it? Why have the "use" statement at all if that particular module is not being used? You really do want to pre-load the code for the modules using either PerlRequire or a startup script. I prefer the latter. You still need the "use" statement in each program that expects the module so that the import() gets done. If you know there is nothing to be imported, you can get away without the "use" but then you lose out in the self-documenting nature of the modules that this particular program requires to run. In short, you should leave the "use" calls in place on every script. Don't have "use" for modules you are not using. Pre-load your modules using a startup script. Reading the mod_perl guide is also a good thing to do to learn about optimizing memory usage (as is the tuning guide that comes with mod_perl.) -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-301-545-6996 GPG & MIME spoken herehttp://www.khera.org/~vivek/
Re: Best approach for loading several modules
Checkout Apache::RegistryLoader. --Jeff At 02:23 PM 5/11/00, Martin Wood wrote: >Hi there, > >Our Apache::Registry CGIs need access to a dozen or so core modules - is >there an elegant solution to loading these without seeing a dozen or so use >statements at the head of the script? (We have over 100 different CGIs that >share a common structure - it would be a nightmare maintaining a >modification to one of our standard modules if every CGI kept a list of its >own set). > >Currently we place all the use directives in one file and have a 'do >"startup.pl"' statement which is obviously very silly - but we run into >undefined subroutine / Exporter problems when using 'require "startup.pl"' > >We realise we could use the PerlRequire directive in the server >configuration to pre-load modules, yet whilst this could be ideal we don't >want to lose the flexibility in debugging our scripts from the command line >(we are still in the tentative mod_perl should we commit / shouldn't we >commit experimental stage). > >Is PerlRequire really the only solution? > >Thanks for any ideas, > >Martin > > > Jeff Beard _ Web:www.cyberxape.com Email: jeff at cyberxape.com Location: Boulder, CO, USA
Best approach for loading several modules
Hi there, Our Apache::Registry CGIs need access to a dozen or so core modules - is there an elegant solution to loading these without seeing a dozen or so use statements at the head of the script? (We have over 100 different CGIs that share a common structure - it would be a nightmare maintaining a modification to one of our standard modules if every CGI kept a list of its own set). Currently we place all the use directives in one file and have a 'do "startup.pl"' statement which is obviously very silly - but we run into undefined subroutine / Exporter problems when using 'require "startup.pl"' We realise we could use the PerlRequire directive in the server configuration to pre-load modules, yet whilst this could be ideal we don't want to lose the flexibility in debugging our scripts from the command line (we are still in the tentative mod_perl should we commit / shouldn't we commit experimental stage). Is PerlRequire really the only solution? Thanks for any ideas, Martin
