Re: Problem with mod_perl and subroutines in multiple files.
Benjamin Grabkowitz wrote: I am a new Perl developer and just found out about the great benefits of mod_perl. I see that you try to work with mod_perl 2.0. So here is a bit of advice: mod_perl 2.0 (1.99_0x) while getting better every day, still has quite a few bugs, so you may want to start with the stable mod_perl 1.0 (1.27) instead and then move on to 2.0 when the time comes. If you do want to stick with mp2, (and we do want people to start using it to expose the bugs as early as possible), please make sure to use the latest cvs version, since what you use is a way too old and lots of bugs were fixed since 1.99_05. See: http://perl.apache.org/download/source.html#mod_perl_2_0 Finally regarding your original question, you probably need to read this: http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs and may be spend some time around http://perl.apache.org/docs/1.0/guide/ for your own good ;) I had a Perl cgi script that ran fine. It consisted of 1 main.pl file and multiple subroutines that each had their own file in a directory called libs (it is in the same directory as main.pl). When I got mod_perl properly configured (or to what I thought was properly configured), I got strange errors like: ModPerl::PerlRun: Not a CODE reference at /var/www/cgi-bin/main.pl line 31. __ 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
Problem with mod_perl and subroutines in multiple files.
I am a new Perl developer and just found out about the great benefits of mod_perl. I had a Perl cgi script that ran fine. It consisted of 1 main.pl file and multiple subroutines that each had their own file in a directory called libs (it is in the same directory as main.pl). When I got mod_perl properly configured (or to what I thought was properly configured), I got strange errors like: ModPerl::PerlRun: Not a CODE reference at /var/www/cgi-bin/main.pl line 31. Line 31 turned out to be a function call. If I commented out line 31 it would give me the same error for the next line with a subroutine call. The strange thing is that the script would run for like 3 or 4 times after each apache restart. Now I kind of (I emphasize kind of) worked out a solution. If I take all my subroutine files and merge them to the end of main.pl. Everything runs fine, not only fine...but blazingly quick. Anyone have any ideas? My box info: RedHat 8.0 (pretty much a stock system...other than the RH updates) httpd-2.0.40-15 (apache) perl-5.8.0-55 mod_perl-1.99_05-3 I added the following to httpd.conf to get mod_perl working...please school me if I am totally out of line. BEGIN ADDITION TO HTTPD.CONF* PerlModule Apache2 PerlModule DBI SetHandler perl-script PerlHandler ModPerl::PerlRun PerlSendHeader On PerlOptions +ParseHeaders Options ExecCGI FollowSymLinks Includes END** Thank you for your time, -Ben Grabkowitz
Re: Subroutines taking time to return..
Hi again, On Thu, 21 Mar 2002, David Brown wrote: > OK, I have it working now. Guess I shold read ALL my mail before replying to any of it... 73, Ged.
Re: Subroutines taking time to return..
Hi there, On Thu, 21 Mar 2002, Perrin Harkins wrote: > When you call the script, do you get segfaults in the error log? Coming into this thread a little late, so sorry if you already said, what version of Perl are you using? I had problems with Devel::Dprof and dprofpp on 5.7.1 which were fixed by upgrading to 5.7.2 although Dprof itself didn't change at all. 73, Ged.
Re: Subroutines taking time to return..
OK, I have it working now. I had to manually create the dprof directory in APACHEROOT/logs (I had expected it to be created), and then set the permissions such that apache (running as user: nobody) could write to it. Sorted. Thanks for your guidance guys. - Original Message - From: "Perrin Harkins" <[EMAIL PROTECTED]> To: "David Brown" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, March 21, 2002 7:07 PM Subject: Re: Subroutines taking time to return.. > David Brown wrote: > > All good and well I thought.. But erm.. nothing is being created in the > > dprof directory in the server-root. > > When you call the script, do you get segfaults in the error log? > > Make sure that you do the DProf stuff, including Apache::DB->init(), > before you load any of your other modules. Otherwise, the debugging > symbols don't get put into your code.
Re: Subroutines taking time to return..
David Brown wrote: > All good and well I thought.. But erm.. nothing is being created in the > dprof directory in the server-root. When you call the script, do you get segfaults in the error log? Make sure that you do the DProf stuff, including Apache::DB->init(), before you load any of your other modules. Otherwise, the debugging symbols don't get put into your code. - Perrin
Re: Subroutines taking time to return..
David Brown wrote: > Thankyou, but I have read the documentation. > > Nothing gets written to a rootdir/dprof directory, not even an empty file > when the scripts are run. sorry, you should have told this :0) Could be write permissions? Can you profile a normal perl script? >>You aren't doing it wrong. Next step is to run the script and usually it >>helps to read the docs :) > > > > > -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Subroutines taking time to return..
Thankyou, but I have read the documentation. Nothing gets written to a rootdir/dprof directory, not even an empty file when the scripts are run. > You aren't doing it wrong. Next step is to run the script and usually it > helps to read the docs :)
Re: Subroutines taking time to return..
David Brown wrote: > Great feedback, many thanks. But as always, one problem becomes another ! > > I've compiled + installed Apache-DB > I've compiled + installed DProf-19990108 > > I've added this to my httpd.conf: > > PerlModule Apache::DProf > > I've added this to my modperl.conf (called by httpd.conf): > > use Apache::DProf; > use Apache::DB; > Apache::DB->init; > > When Apache startsup I get: > > [notice] Apache::DB initialized in child 55178 > > All good and well I thought.. But erm.. nothing is being created in the > dprof directory in the server-root. > > What am I doing wrong ? You aren't doing it wrong. Next step is to run the script and usually it helps to read the docs :) http://thingy.kcilink.com/modperlguide/performance/Code_Profiling_Techniques.html _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Subroutines taking time to return..
Great feedback, many thanks. But as always, one problem becomes another ! I've compiled + installed Apache-DB I've compiled + installed DProf-19990108 I've added this to my httpd.conf: PerlModule Apache::DProf I've added this to my modperl.conf (called by httpd.conf): use Apache::DProf; use Apache::DB; Apache::DB->init; When Apache startsup I get: [notice] Apache::DB initialized in child 55178 All good and well I thought.. But erm.. nothing is being created in the dprof directory in the server-root. What am I doing wrong ? Regards
Re: Subroutines taking time to return..
Perrin Harkins wrote: >>You cannot reliably measure CPU clocks with wallclock on the >>multi-processor machine, unless you are running on Dos :) >> > > Even so, wall time is what most people actually care about, and it's > fine to use if you're the only one doing work on that machine. Yes, for counting the total run-time of the code that does something. No, for benchmarking nearly-empty subroutines run times. Since the error here can be 1000% and more. You are still running on time-sharing machine and if your sub didn't fit into one CPU timeslice, but the other did, the relative difference can be tremendous, while in fact both subs consume approximately the same number of CPU clocks. This can lead to very wrong conclusions. >>Also search the archives, about a year ago I've posted a subclass to DBI that >measures the SQL execution profiling. I'm not sure if Tim has this unctionality in the latest DBI. > > DBIx::Profile does a good job of this. cool :) -- _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Subroutines taking time to return..
> You cannot reliably measure CPU clocks with wallclock on the > multi-processor machine, unless you are running on Dos :) Even so, wall time is what most people actually care about, and it's fine to use if you're the only one doing work on that machine. > Also search the archives, about a year ago I've posted a subclass to DBI > that measures the SQL execution profiling. I'm not sure if Tim has this > functionality in the latest DBI. DBIx::Profile does a good job of this. > You best bet is to use DProf as suggested Garth. Agreed. - Perrin
Re: Subroutines taking time to return..
David Brown wrote: > I've been profiling my MySQL driven Mod_Perl website by adding debug > messages throughout the code which relays what time has elapsed since the > script was invoked (using Time::HiRes) > > Now the script is pretty whizzy, serving up complete pages in circa 0.010 > seconds. > > I got to wondering how those 0.010 were being made up. Interestingly, all > of the database access is complete within 0.002 so I thought where do the > other 0.008 come from ? You cannot reliably measure CPU clocks with wallclock on the multi-processor machine, unless you are running on Dos :) See the performance chapter in the mod_perl guide. Also search the archives, about a year ago I've posted a subclass to DBI that measures the SQL execution profiling. I'm not sure if Tim has this functionality in the latest DBI. Though it also measures wallclock time if I remember correctly :( You best bet is to use DProf as suggested Garth. _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Subroutines taking time to return..
Hi there, On Wed, 20 Mar 2002, David Brown wrote: > I've been profiling my MySQL driven Mod_Perl website [snip] > (using Time::HiRes) [snip] > I expected all the complicated DB access stuff to make up the time MySQL is pretty quick. :) > instead it seems to be consuming 0.005 in returning from the subroutine to > the main script. > > What's that all about ? [snip] > > It SEEMS the subroutine is taking an inordinate amount of time returning to > the main procedure.. why would this be ? What else is the machine doing? Is it reapeatable (i.e. not just OS timeslices or something)? Post the code? 73, Ged.
Re: Subroutines taking time to return..
Have you tried using Apache::DProf? Using this is a lot easier than
trying to add tons of debug messages. If you haven't used it or the
regular DProf, it does what your doing automatically. It generates a
file of data that you run 'dprofpp' on and you can get a list of the top
10 or so most time consuming functions. Using Apache::DProf usually
reveals time consuming methods in my code that I would never have
expected to take so long.
In your case, however thourough you were in placing debug statements,
its possible (and likely) that you've missed the key subroutine.
G
On Wed, 2002-03-20 at 09:59, David Brown wrote:
> I've been profiling my MySQL driven Mod_Perl website by adding debug
> messages throughout the code which relays what time has elapsed since the
> script was invoked (using Time::HiRes)
>
> Now the script is pretty whizzy, serving up complete pages in circa 0.010
> seconds.
>
> I got to wondering how those 0.010 were being made up. Interestingly, all
> of the database access is complete within 0.002 so I thought where do the
> other 0.008 come from ?
>
> I found the following happened (pseudo code)
>
> # Checkpoint A - Elapsed : 0.000
>
> &buildpage;
>
> # Checkpoint D - Elapsed 0.010 seconds
>
> sub buildpage
> {
> # Checkpoint B - Elapsed: 0.001
>
> # Do some DB accessing etc. make a nice webpage
>
> # Checkpoint C - Elapsed 0.002
> }
>
> --
>
> I expected all the complicated DB access stuff to make up the time, but
> instead it seems to be consuming 0.005 in returning from the subroutine to
> the main script.
>
> What's that all about ?
>
> Points:
>
> 1. A global variable exists throughout the script to build the webpage
> 2. Global file handles are used to access the DB (to retain across
> subsequent requests)
> 3. No LOCAL or MY variables are defined in the subroutine.
> 4. As the webpage is being built into a global variable, the "buildpage"
> subroutine doesn't RETURN a value to the calling script.
>
> It SEEMS the subroutine is taking an inordinate amount of time returning to
> the main procedure.. why would this be ?
>
> ( I'm running Free/BSD, Apache/1.3.22, Mod_perl 1.26 )
>
>
>
>
Subroutines taking time to return..
I've been profiling my MySQL driven Mod_Perl website by adding debug
messages throughout the code which relays what time has elapsed since the
script was invoked (using Time::HiRes)
Now the script is pretty whizzy, serving up complete pages in circa 0.010
seconds.
I got to wondering how those 0.010 were being made up. Interestingly, all
of the database access is complete within 0.002 so I thought where do the
other 0.008 come from ?
I found the following happened (pseudo code)
# Checkpoint A - Elapsed : 0.000
&buildpage;
# Checkpoint D - Elapsed 0.010 seconds
sub buildpage
{
# Checkpoint B - Elapsed: 0.001
# Do some DB accessing etc. make a nice webpage
# Checkpoint C - Elapsed 0.002
}
--
I expected all the complicated DB access stuff to make up the time, but
instead it seems to be consuming 0.005 in returning from the subroutine to
the main script.
What's that all about ?
Points:
1. A global variable exists throughout the script to build the webpage
2. Global file handles are used to access the DB (to retain across
subsequent requests)
3. No LOCAL or MY variables are defined in the subroutine.
4. As the webpage is being built into a global variable, the "buildpage"
subroutine doesn't RETURN a value to the calling script.
It SEEMS the subroutine is taking an inordinate amount of time returning to
the main procedure.. why would this be ?
( I'm running Free/BSD, Apache/1.3.22, Mod_perl 1.26 )
subroutines
Hello All,
This might be a very obvious question to many of you, but for me it's
still somewhat unclear.
I am running Apache 1.3.19 mod_perl/1.24_01 on a RedHat 7.1 box (PC).
I have 2 versions of code running under 2 different virtual hosts. As
you probably guessed, my subroutine definitions are getting overriden,
and subroutines from package on one tree, get called by programs in the
other tree.
The mod_perl documentation suggests that by using the Apache::PerlVINC
module it is possible to load
the appropriate module based upon the name of the virtual host used.
The 2 questions I have are:
1) as my modules are not used as PerlHandler (as is the case with the
example in the online documentation 'PerlHandler Apache::Status'), I am
not quite sure how to configure Apache to simply
reload a "simple" module when a request is made against a specific
virtual host.
Previously, I used the PerlScript directive to load the modules:
httpd.conf
-
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI -Indexes
PerlScript/path_to_cgi/main.pl
--
main.pl
-
use lib (/path_to_cgi/main.pl)
use Module1;
use Module2;
...
sub subroutine1 {}
sub subroutine2 {}
-
How can I configure it so that when a request is made against
- http://qa/cgi-bin/main.plex => /path_to_qa/main.plex is loaded (with
all underlying modules)
- http://devel/cgi-bin/main.plex => /path_to_devel/main.plex is loaded
(with all underlying modules)
2) and if it is possible to do this, are the modules cached via mod_perl
(Apache::Registry) when several consequtive requests are made against
the same vhost (say http://qa/)
Thanks in advance!
Arshavir
Re: Apache::ASP error re: subroutines
Andrew Koebrick wrote: > > Howdy, > > I am attempting to move a few subroutines from my Apache::ASP pages into a central >module, but get the error: > > Undefined subroutine &Apache::ASP::Demo::date_swap called at (eval 6) line 67. , >/usr/lib/perl5/site_perl/5.6.0/Apache/ASP.pm line 1506 PerlSetVar GlobalPackage is set to Apache::ASP::Demo I bet, and you called the sub date_swap() which was not defined there. > > Is there something funky in the Apache::ASP environment regarding how/where modules >are handled? The functions work when in the page, so I dont think there is an >internal error there. I am calling the module with a basic "use ASK" (ASK.pm is the >module name). The module has appropriate ownership/rights. > If you sub is in ASK.pm, then you can reference it like: &ASK::date_swap() or you could define the sub in the global.asa, which takes on the package name from GlobalPackage, so the sub will be in the same package that all your scripts are compiled into. > I am especially curious why it is looking for dateswap under Apache::Demo::XXX > This is the package that your ASP scripts & includes are compiled into. Also there is a new mailing list for Apache::ASP at [EMAIL PROTECTED], but I have been slow to update the docs at the ASP web site & README. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks >> free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Apache::ASP error re: subroutines
Howdy, I am attempting to move a few subroutines from my Apache::ASP pages into a central module, but get the error: Undefined subroutine &Apache::ASP::Demo::date_swap called at (eval 6) line 67. , /usr/lib/perl5/site_perl/5.6.0/Apache/ASP.pm line 1506 Is there something funky in the Apache::ASP environment regarding how/where modules are handled? The functions work when in the page, so I dont think there is an internal error there. I am calling the module with a basic "use ASK" (ASK.pm is the module name). The module has appropriate ownership/rights. I am especially curious why it is looking for dateswap under Apache::Demo::XXX Any assistance appreciated. This is my first module and so my error could be anywhere, as my ignorance is everywhere. ASK Andrew Koebrick Web Coordinator/Librarian MN-Planning (Office of Strategic and Long Range Planning) 658 Cedar St., Suite 300 St. Paul, MN 55155 651-296-4156 phone 651-296-3698 fax www.mnplan.state.mn.us
Re: Apache::ASP question: undefined subroutines
Carl Lipo wrote: > > Does anyone know what causes these kinds of errors? The 'subroutine' that > the output is referring to is the name of the page (in this case > search.htm) that is being loaded and that sits in the content directory -- > there are no real missing subroutines...Maddeningly, if I hit reload > enough times the page will finally load at some point and then error a few > reloads later. > > The page (search.htm) sits on an NFS mount (could that be a problem?). > > Errors Output > > 1.Undefined subroutine > &InterNAP::NFT::_home_staff_carl_htdocs_apps_nft_search_htmxINL called at > /usr/local/lib/site_perl/Apache/ASP.pm line 1395. , >/usr/local/lib/site_perl/Apache/ASP.pm line 1397 > Somehow, your perl sub that is the compiled version of a page gets undefined. In order to track down the problem, set Debug to -1, and get me the error_log output ( in a private email ) from a fresh server start until the error occurs. I need to see how the subroutine is being undefined, and whether Apache::ASP might be responsible for this. You can also try my latest dev release to see if that helps, but I don't think we'll be solving the real problem if we did that. What version are you running BTW? --Joshua _ Joshua Chamas Chamas Enterprises Inc. NodeWorks >> free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Apache::ASP question: undefined subroutines
Does anyone know what causes these kinds of errors? The 'subroutine' that the output is referring to is the name of the page (in this case search.htm) that is being loaded and that sits in the content directory -- there are no real missing subroutines...Maddeningly, if I hit reload enough times the page will finally load at some point and then error a few reloads later. The page (search.htm) sits on an NFS mount (could that be a problem?). Errors Output 1.Undefined subroutine &InterNAP::NFT::_home_staff_carl_htdocs_apps_nft_search_htmxINL called at /usr/local/lib/site_perl/Apache/ASP.pm line 1395. , /usr/local/lib/site_perl/Apache/ASP.pm line 1397 Debug Output 1.Undefined subroutine &InterNAP::NFT::_home_staff_carl_htdocs_apps_nft_search_htmxINL called at /usr/local/lib/site_perl/Apache/ASP.pm line 1395. , /usr/local/lib/site_perl/Apache/ASP.pm line 1397 Here is the ASP Cconfiguration information for the app: SetHandler perl-script PerlHandler Apache::ASP Apache::SSI PerlSetVar Filter On PerlSetVar IncludesDir . PerlSetVar StateDB DB_File PerlSetVar CookiePath /apps/nft PerlSetVar Global . PerlSetVar StateDir /tmp/.state-asp/nft PerlSetVar GlobalPackage InterNAP::NFT PerlSetVar AllowSessionState 1 PerlSetVar SessionTimeout 60 PerlSetVar Debug 2 PerlSetVar MailHost mailhost-stu.sea.internap.com PerlSetVar MailErrorsTo [EMAIL PROTECTED] PerlSetVar CONFIG_FILE /usr/local/etc/nft/nft.xml Any ideas would be greatly appreciated -- its so intermittent, its driving us crazy! Carl Lipo EMAIL: [EMAIL PROTECTED] IT Systems ArchitectPAGER: 888.393.5620 InterNAP Network Services OFFICE: 206.504.5442 601 Union Street, Suite 1000FAX: 206.264.1833 Seattle, WA 98101 CELL: 206.579.0163 Unauthorized use, disclosure or distribution of information within this message is prohibited.
Re: To-Experts: BIG problem: my variables in nested subroutines, whic h call each other
I'm seconding Ime's suggestion, and adding one piece, you don't have to use anonymous subroutines for everything..., that would be.., well, a big pain. Named subroutines where EVERYTHING it uses is passed in via references. Also it's return values are sent back via reference as well. References "under the covers" are pointers. So if you were to pass something to a perl function via a reference, like a hash, the hash when it got back to it's calling context would be modified..., this is pretty usefull. (perldoc perlsub && perldoc perlref BTW) The last thing is maybe you should look into isolating a lot of this stuff into modules. I'm sure your sub's are shared quite frequently between many scripts..., well, there is no need to suck up all that extra memory, just pull that into your own module set. Thanks, Shane. The rule is... NO GLOBALS! :-) Of course, every rule is made to broken in certain situations.
Re: To-Experts: BIG problem: my variables in nested subroutines,whic h call each other
| QUESTION: But how should I transform the script, if the anonymous subs call
| each other?
| I get always the following error:
| Undefined soubroutine &main:: called at line .
| I don't know how to solve this. Is there any solution for this? Can I make
| any prototype defs for such subroutines?
A good programming practice is to never let
a sub {} depend nor use any variables which are not explicitly
passed to it. If severel subs should have some kind of globally
used structures to work with, explicitly pass it by reference
to each sub. If you follow that basic rule, you will write code
which is both maintainable and is perfectly suitable for a mod_perl
environment.
Ime
To-Experts: BIG problem: my variables in nested subroutines, which call each other
Hi! I should migrate Perl-CGIs to mod_perl for performance reasons. We use many subroutines in our CGIs, which read and write global (my-defined) variables. Our plain subroutines are not nested, but they are when the mod_perl wrapper is put around them at execution time. In this special case, some values are not updated. You get this error: Variable "$" will not stay shared at line (#1) This problem is also discribed under: http://perl.apache.org/guide/perl.html#my_Scoped_Variable_in_Nested_S This page says to convert all subroutines to "anonymous" subroutines. This works fine, as long as anonymous subroutines call other anonymous subs defined before. Ok, now you can order all subroutines, so that they are always defined before they are called. QUESTION: But how should I transform the script, if the anonymous subs call each other? I get always the following error: Undefined soubroutine &main:: called at line . I don't know how to solve this. Is there any solution for this? Can I make any prototype defs for such subroutines? BIG THANKS IN ADVANCE, Christoph. yLine Internet Services AG
Re: How do I package my DBI subroutines?
Hi there, On Wed, 19 Jan 2000, Keith Kwiatek wrote: > We have recently installed a new machine with Apache/1.3.9 > mod_perl/1.21 mod_ssl/2.4.10 OpenSSL/0.9.4 perl 5.004_04 configured > A perl transaction handler that works fine on Apache/1.3.6 > mod_perl/1.21 5.00503 is now intermittantly dying on the new box > with the following error; > Can't call method "register_cleanup" on an undefined value at > /usr/lib/perl5/5.00503/CGI.pm at line 263 Did you get a reply yet? Your installation is apparently out of order. You claim to have configured perl 5.004_04 on the new box yet the error message says: /usr/lib/perl5/5.00503/CGI.pm at line 263 ^^^ which is the wrong version of Perl. This doesn't seem like a good idea to me. I'd delete the lot and reinstall everything from scratch. > I have some dbi subroutines that I want my mod_perl program to > use. how do I go about packaging these (or whatever the correct > terminology is) I think you'll find everything you need for this in Stas' Guide. 73, Ged.
How do I package my DBI subroutines?
Hello, I have some dbi subroutines that I want my mod_perl program to use. how do I go about packaging these (or whatever the correct terminology is) ? Don't I just create a .pm module and then "USE" it? I tried this, and it keeps comming back saying "Undefined subroutine". Thanks for any and all help! Keith
RE: Embperl Subroutines
>
> One thing that I am doing now is making use of Embperl [$ sub $] [$
> endsub $] for defining subroutines. If I read the documentation
> correctly these subroutines will be 'imported' into any page that I
> import them into. I see no mention of reuse of these subroutines, each
> page seems to get it's own compiled copy in it's namespace.
>
No, the subroutines are compiled in one package, and only the names are
imported in each page from which you call Execute with the import parameter.
So the subroutines get resued. It's just the same as Perl's "use".
> I am wondering if during the Execute I can set the PACKAGE that the
> subroutines are compiled into like:
>
> Execute( { inputfile => '/include/subs.emb', package => 'Subs', import
> => 1 } );
>
> and then use
>
> [- Subs::subroutine -]
>
> in my pages.
>
> I could run this once in my startup.pl, pre-compile the subroutines and
> reuse them.
>
You can do so. Use import => 0, to only compile your subroutines and not
import the names in the namespace of your startup.pl:
Execute( { inputfile => '/include/subs.emb', package => 'Subs', import =>
0 } );
Gerald
-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151
WWW:http://www.ecos.de Fax: +49 6133 925152
-
Embperl Subroutines
Hello Everyone,
I am in the process of developing an Embperl/Mysql site and have a
couple of questions.
One thing that I am doing now is making use of Embperl [$ sub $] [$
endsub $] for defining subroutines. If I read the documentation
correctly these subroutines will be 'imported' into any page that I
import them into. I see no mention of reuse of these subroutines, each
page seems to get it's own compiled copy in it's namespace.
I am wondering if during the Execute I can set the PACKAGE that the
subroutines are compiled into like:
Execute( { inputfile => '/include/subs.emb', package => 'Subs', import
=> 1 } );
and then use
[- Subs::subroutine -]
in my pages.
I could run this once in my startup.pl, pre-compile the subroutines and
reuse them.
Thoughts,
Owen
