RE: When perl is not quite fast enough
-Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: 16 December 2002 13:22 To: [EMAIL PROTECTED] Subject: When perl is not quite fast enough While reading Mark Fowler excelent Perl Advent Calendar (http://www.perladvent.org/2002/) 6th entry: http://www.perladvent.org/2002/6th/, in the references section I've noticed a link to Nicolas Clark's notes from his YAPC::EU::2002 presentation, on how to make your perl code faster: http://www.ccl4.org/~nick/P/Fast_Enough/ Dear ModPerl Lister, I have two questions: 1) In this list, I have seen folks asking general Perlish questions told to take their discussions elsewhere, along with the useless recommendation that they browse lists.perl.org - I have done this several times and joined a few of the lists, but only ever found lists that were rather beginner. I have also lurked in some of the groups.yahoo.com pearly lists without finding the right level. - can folks name any specific useful intermediate/advanced Perl lists? i.e. Perl 4+ years in a commercial env 2) I have one common approach to speed improvement that is not mentioned at all, to do with symbol table manipulation for functions, that I would like to polish via a list discussion - is this list appropriate for a thread discussing Perlish performance in general? I would guess that symbol table fiddles might be risky in a mod_perlish env. TIA Jeff
Re: Problem compiling mod_perl 1.27 on Windows
Randy Kobes wrote: On Mon, 16 Dec 2002, Steve Hay wrote: Is there some other way, for Win32, to achieve what the PERL_USELARGEFILES=0 hack tried to do? This seems hard to do without recompiling either the standard Apache sources (to enable large_files support) or else the standard ActivePerl 8xx sources (to disable large_files support). Sounds like recompiling Perl from the ActivePerl 804 sources with large_files support disabled is my best bet. Am I correct in thinking that all I need to do to achieve this is change uselargefiles='define' back to uselargefiles='undef' in win32/config.vc, or is there anything else that I need to fiddle with too? - Steve
What's On-topic and what's Off-topic on this list
I've the feeling that many subscribers are quite confused about the on-topic/off-topic policy on this list. In general, we try to keep threads mod_perl-centric. Because when the list starts to be dumping grounds for other related things, with a side effect of surging the list's traffic, those who were interested in pure mod_perl discussions, simply leave. And among those who leave we lose current or potential contributors. It's extremely hard to tell what's on-topic and what's not, because mod_perl programmers touch an enourmous amount of areas at their work. And sometimes this list is the only place where you can get an advice on certain topics, which happen to be related to mod_perl. But... my rule of thumb of deciding what's off-topic is very simple: think whether there is another good place to discuss a question in hand. May be an example will help to explain that approach. If somebody asks a beginners question on perl; usually how to write their code better, or why some code doesn't work, you have to agree that there are plenty other forums where this can be discussed (e.g. perlmonks.org). Now, when somebody asks about a proper way to generate unique hardly guessable session keys, that's a grey zone; on one side this is not a mod_perl specific question, on the other side it is, because under mod_perl you can take a benefit of process persistance and the way your keys are generated are a bit different. If you ask about performance improvement, this is kind of questions that are always welcome here, because I doubt there is any other forum where there are as many experts in performance as in the mod_perl community. But again, this is a grey zone. Obviously when something doesn't work under mod_perl, but works under mod_cgi, this is a very ontopic question. So, the next time you are about to ask a question which is not clearly on topic, first think whether you can get your answers elsewhere. If you don't where to ask, and you have browsed the help docs, ask about the right resource (just like Jeff did). If you have failed to find an answer elsewhere, after truly looking for it, I guess it's fine to ask here as a last resort, explaining your situation. But some people dare to post a statement: I know that you can answer my question, so I'm asking it here. That's ugly. I feel that we need to add some sort of explanation of the on/off-topic posts issue to http://perl.apache.org/maillist/email-etiquette.html. Perhaps somebody who's writing is better than mine can contribute that. I feel that I brag too much around and people lose the point. So if somebody can write a clear, concise version of my bragging, or even better your own thoughts, please do that. Finally, it's everybody's list. If you don't like the way things are, change them. But please don't complain if you do nothing to help others (that's unrelated to your post, Jeff :). __ 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
[mp2] Having to reload apache when perl modules change
Hi again group. A quick question (but this might not be the right place). If this is the wrong place to ask, please point me in the direction of the right place. I have a web app written using mod_perl2 and apache::ASP. When I change the code in a perl module, I have to restart apache to make the changes appear to all children. Is there a way of avoiding this - maybe with an apache directive - so that all modules are re-read by all children without a restart ? Thanks Richard
Re: [mp2] Having to reload apache when perl modules change
Richard Curtis wrote: Hi again group. A quick question (but this might not be the right place). If this is the wrong place to ask, please point me in the direction of the right place. you're in the right place, don't worry :) I have a web app written using mod_perl2 and apache::ASP. When I change the code in a perl module, I have to restart apache to make the changes appear to all children. Is there a way of avoiding this - maybe with an apache directive - so that all modules are re-read by all children without a restart ? Apache::Reload ships standard with mod_perl 2.0 and is pretty much the same as with 1.0. See that manpage or docs/api/mod_perl-2.0/Apache/Reload.pod for more details. HTH --Geoff
DumpHeader Apache Perl Mod
Config: Apache::DumpHeaders 0.94 http://search.cpan.org/author/ABH/Apache-DumpHeaders-0.94/DumpHeaders.pm OS: Mandrake Linux 9.0 Apache: Apache-AdvancedExtranetServer/1.3.26 (Mandrake Linux/5mdk) mod_perl/1.27 Server Built: Sep 6 2002 19:31:19 mod_perl is functioning correctly as I tested it with the test file that ships with mod_perl: mod_perl-testscript.pl I followed the instructions for building and installing an Apache Perl mod, issuing the command perl -e DumpHeaders.pm; works fine. In the commonhttpd.conf file, I put the commands: IfModule mod_perl.c Location / PerlLogHandler Apache::DumpHeaders PerlSetVar DumpHeaders_File test.txt /Location /IfModule If I didn't wrap them in the IfModule.. Apache wouldn't load correctly. There are several .conf files in this Apache version: commonhttpd.conf httpd.conf httpd-perl.conf The commonhttpd.conf gets included in the main httpd.conf file. Problem: - I don't quite understand how this mod is supposed to work. The instructions say that it should write a file that contains the dump of headers.. but I don't see a file being written anywhere. The archive that Apache::DumpHeaders was in, didn't include any examples or a demo so I really don't know how it's supposed to be used. Being a log handler, I would think that it's something that gets executed for every page (which would be fine). I hope this is the correct place for this type on inquiry. Thanks Chris
Re: [mp1.0] linking libperl.so fails because ofG: command not found
Kenny, I am not sure if I can help you much, but I was succesful in building this combination. The main differences I see between our configuration is that you are using SunOS in Intel wheras I am using SPARC and that you obviously tried to build mod_perl as DSO. What were the command lines you used to configure mod_perl and Apache? Do you need mod_perl running as a DSO? Regards, Frank Kenny Smith [EMAIL PROTECTED] 13.12.2002 18:57 An: [EMAIL PROTECTED] Kopie: Thema: [mp1.0] linking libperl.so fails because of G: command not found Hello, I'd like to report an installation bug. I've looked around and if this has already been reported, or is mentioned in documentation, I apologize for the repeat. The symptom is when make tries to link libperl.so it dies with G: command not found I tracked down PERL_LD was blank in apaci/Makefile. I put gcc in there, and it linked and built properly. One one of the subsequent lines there was a -G at the start of PERL_LDDLFLAGS, so I assume that is where the G came from. Versions: SunOS 5.8 x86 apache 1.3.27 mod_perl 1.27 gcc version 2.95.3 20010315 (release) autoconf (GNU Autoconf) 2.53 GNU Make version 3.79.1 If there is any other information you need, please let me know. Kenny Smith JournalScape.com
Re: [mp1.0] linking libperl.so fails because of G: command not found
Hi Frank, This is how I configured apache: ./configure --prefix=/usr/local/kenny --enable-module=rewrite --enable-shared=rewrite --enable-suexec --suexec-caller=nobody --suexec-docroot=/usr/www --enable-module=so and this is how I configured mod_perl: perl Makefile.PL \ USE_APXS=1 \ WITH_APXS=/usr/local/apache/bin/apxs \ EVERYTHING=1 The problem was that it just wasn't filling in that one value in the configure script, so it didn't know what binary to use to link after compilation. Kenny Smith [EMAIL PROTECTED] wrote: Kenny, I am not sure if I can help you much, but I was succesful in building this combination. The main differences I see between our configuration is that you are using SunOS in Intel wheras I am using SPARC and that you obviously tried to build mod_perl as DSO. What were the command lines you used to configure mod_perl and Apache? Do you need mod_perl running as a DSO? Regards, Frank Kenny Smith 13.12.2002 18:57 An: [EMAIL PROTECTED] Kopie: Thema: [mp1.0] linking libperl.so fails because of G: command not found Hello, I'd like to report an installation bug. I've looked around and if this has already been reported, or is mentioned in documentation, I apologize for the repeat. The symptom is when make tries to link libperl.so it dies with G: command not found I tracked down PERL_LD was blank in apaci/Makefile. I put gcc in there, and it linked and built properly. One one of the subsequent lines there was a -G at the start of PERL_LDDLFLAGS, so I assume that is where the G came from. Versions: SunOS 5.8 x86 apache 1.3.27 mod_perl 1.27 gcc version 2.95.3 20010315 (release) autoconf (GNU Autoconf) 2.53 GNU Make version 3.79.1 If there is any other information you need, please let me know. Kenny Smith JournalScape.com
DumpHeader Apache Perl Mod
NOTE: I hope this isn't a dupe, not sure if the email address was correct. Config: Apache::DumpHeaders 0.94 http://search.cpan.org/author/ABH/Apache-DumpHeaders-0.94/DumpHeaders.pm OS: Mandrake Linux 9.0 Apache: Apache-AdvancedExtranetServer/1.3.26 (Mandrake Linux/5mdk) mod_perl/1.27 Server Built: Sep 6 2002 19:31:19 mod_perl is functioning correctly as I tested it with the test file that ships with mod_perl: mod_perl-testscript.pl I followed the instructions for building and installing an Apache Perl mod, issuing the command perl -e DumpHeaders.pm; works fine. In the commonhttpd.conf file, I put the commands: IfModule mod_perl.c Location / PerlLogHandler Apache::DumpHeaders PerlSetVar DumpHeaders_File test.txt /Location /IfModule If I didn't wrap them in the IfModule.. Apache wouldn't load correctly. There are several .conf files in this Apache version: commonhttpd.conf httpd.conf httpd-perl.conf The commonhttpd.conf gets included in the main httpd.conf file. Problem: - I don't quite understand how this mod is supposed to work. The instructions say that it should write a file that contains the dump of headers.. but I don't see a file being written anywhere. The archive that Apache::DumpHeaders was in, didn't include any examples or a demo so I really don't know how it's supposed to be used. Being a log handler, I would think that it's something that gets executed for every page (which would be fine). I hope this is the correct place for this type on inquiry. Thanks Chris
Re: Problem compiling mod_perl 1.27 on Windows
On Tue, 17 Dec 2002, Steve Hay wrote: Randy Kobes wrote: On Mon, 16 Dec 2002, Steve Hay wrote: Is there some other way, for Win32, to achieve what the PERL_USELARGEFILES=0 hack tried to do? This seems hard to do without recompiling either the standard Apache sources (to enable large_files support) or else the standard ActivePerl 8xx sources (to disable large_files support). Sounds like recompiling Perl from the ActivePerl 804 sources with large_files support disabled is my best bet. That would most probably fix the problem with mod_perl. Doing this may lead to an incompatibility in principle with trying to use a particular ppm package (having an xs component) provided by ActiveState, but since you have a compiler, that's not a problem for you. Am I correct in thinking that all I need to do to achieve this is change uselargefiles='define' back to uselargefiles='undef' in win32/config.vc, or is there anything else that I need to fiddle with too? I'm not sure Probably the safest thing to do is to compare the relevant files (Makefile, config*, *.h) under the win32/ subdirectory of the ActivePerl sources with those in the CPAN Perl sources. -- best regards, randy
Re: What's On-topic and what's Off-topic on this list
One thing that's useful for both people who don't know where else to turn
and people who don't want anything that's not pure mod_perl is simply to
preface your subject line with [OT] ... it's then very simple to filter
out unwanted messages in any mail reader.
- nick
PS Stas, I think maybe you meant to s/brag/ramble/g ... one thing I've
never seen you guilty of is bragging :)
Nick Tonkin {|8^)
On Tue, 17 Dec 2002, Stas Bekman wrote:
I've the feeling that many subscribers are quite confused about the
on-topic/off-topic policy on this list.
In general, we try to keep threads mod_perl-centric. Because when the list
starts to be dumping grounds for other related things, with a side effect of
surging the list's traffic, those who were interested in pure mod_perl
discussions, simply leave. And among those who leave we lose current or
potential contributors.
It's extremely hard to tell what's on-topic and what's not, because mod_perl
programmers touch an enourmous amount of areas at their work. And sometimes
this list is the only place where you can get an advice on certain topics,
which happen to be related to mod_perl. But... my rule of thumb of deciding
what's off-topic is very simple: think whether there is another good place to
discuss a question in hand.
May be an example will help to explain that approach.
If somebody asks a beginners question on perl; usually how to write their code
better, or why some code doesn't work, you have to agree that there are plenty
other forums where this can be discussed (e.g. perlmonks.org). Now, when
somebody asks about a proper way to generate unique hardly guessable session
keys, that's a grey zone; on one side this is not a mod_perl specific
question, on the other side it is, because under mod_perl you can take a
benefit of process persistance and the way your keys are generated are a bit
different. If you ask about performance improvement, this is kind of questions
that are always welcome here, because I doubt there is any other forum where
there are as many experts in performance as in the mod_perl community. But
again, this is a grey zone. Obviously when something doesn't work under
mod_perl, but works under mod_cgi, this is a very ontopic question.
So, the next time you are about to ask a question which is not clearly on
topic, first think whether you can get your answers elsewhere. If you don't
where to ask, and you have browsed the help docs, ask about the right resource
(just like Jeff did). If you have failed to find an answer elsewhere, after
truly looking for it, I guess it's fine to ask here as a last resort,
explaining your situation. But some people dare to post a statement: I know
that you can answer my question, so I'm asking it here. That's ugly.
I feel that we need to add some sort of explanation of the on/off-topic posts
issue to http://perl.apache.org/maillist/email-etiquette.html. Perhaps
somebody who's writing is better than mine can contribute that. I feel that I
brag too much around and people lose the point. So if somebody can write a
clear, concise version of my bragging, or even better your own thoughts,
please do that.
Finally, it's everybody's list. If you don't like the way things are, change
them. But please don't complain if you do nothing to help others (that's
unrelated to your post, Jeff :).
__
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
Re: When perl is not quite fast enough
Jeff AA wrote: I have two questions: 1) In this list, I have seen folks asking general Perlish questions told to take their discussions elsewhere, along with the useless recommendation that they browse lists.perl.org - I have done this several times and joined a few of the lists, but only ever found lists that were rather beginner. I have also lurked in some of the groups.yahoo.com pearly lists without finding the right level. - can folks name any specific useful intermediate/advanced Perl lists? i.e. Perl 4+ years in a commercial env In addition to perlmonks.org, the usenet groups and IRC have the highest concentration of experienced Perl coders. I would guess that symbol table fiddles might be risky in a mod_perlish env. No more so than any other place. The biggest risk is that symbol table hacks are usually bizarre and hard to read. The Apache::PerlRun module modifies the symbol table in order to reset globals, and I've done really simple things with it to automatically build accessor methods (which can be better than AUTOLOAD with mod_perl because of memory sharing). - Perrin
RE: [mp1.0] linking libperl.so fails because ofG: command not f ound
We had some trouble using DSO on Solaris in that it chewed up memory. But it id work. If it is just something where the shell variable G wasn't being set, perhaps simply going through the Makefiles will help? sorry i can't be more help -Original Message- From: Kenny Smith [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 10:23 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [mp1.0] linking libperl.so fails because of G: command not found Hi Frank, This is how I configured apache: ./configure --prefix=/usr/local/kenny --enable-module=rewrite --enable-shared=rewrite --enable-suexec --suexec-caller=nobody --suexec-docroot=/usr/www --enable-module=so and this is how I configured mod_perl: perl Makefile.PL \ USE_APXS=1 \ WITH_APXS=/usr/local/apache/bin/apxs \ EVERYTHING=1 The problem was that it just wasn't filling in that one value in the configure script, so it didn't know what binary to use to link after compilation. Kenny Smith [EMAIL PROTECTED] wrote: Kenny, I am not sure if I can help you much, but I was succesful in building this combination. The main differences I see between our configuration is that you are using SunOS in Intel wheras I am using SPARC and that you obviously tried to build mod_perl as DSO. What were the command lines you used to configure mod_perl and Apache? Do you need mod_perl running as a DSO? Regards, Frank Kenny Smith 13.12.2002 18:57 An: [EMAIL PROTECTED] Kopie: Thema: [mp1.0] linking libperl.so fails because of G: command not found Hello, I'd like to report an installation bug. I've looked around and if this has already been reported, or is mentioned in documentation, I apologize for the repeat. The symptom is when make tries to link libperl.so it dies with G: command not found I tracked down PERL_LD was blank in apaci/Makefile. I put gcc in there, and it linked and built properly. One one of the subsequent lines there was a -G at the start of PERL_LDDLFLAGS, so I assume that is where the G came from. Versions: SunOS 5.8 x86 apache 1.3.27 mod_perl 1.27 gcc version 2.95.3 20010315 (release) autoconf (GNU Autoconf) 2.53 GNU Make version 3.79.1 If there is any other information you need, please let me know. Kenny Smith JournalScape.com -- This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
Re: What's On-topic and what's Off-topic on this list
Hi all, On Tue, 17 Dec 2002, Nick Tonkin wrote: One thing that's useful for both people who don't know where else to turn and people who don't want anything that's not pure mod_perl is simply to preface your subject line with [OT] ... it's then very simple to filter out unwanted messages in any mail reader. Heh, which is why I keep telling people to read http://perl.apache.org/maillist/email-etiquette.html :) 73, Ged.
Re: AUTOLOAD in mod_perl (was Re: When perl is not quite fastenough)
I may be veering off-topic, but I've started doing similar things in my own code (generating accessor methods via AUTOLOAD). I ended up writing `Class::Autoload,' which I intend to upload to CPAN when I'm done with documentation and testing. Basically, it exports an AUTOLOAD function that will work with the %FIELDS hash to insert accessor methods into the symbol table as needed. There's also a compile() method that can be used to precompile the methods, which I thought was relevent, given the mod_perl/memory discussion. It also provides for read-only methods, and a typing system like that of `Class::Class.' If there's interest, I'll clutter up the list some more with the POD. On Tue, 2002-12-17 at 11:13, kyle dawkins wrote: Perrin (et al... cc'ing this back to the list) Thanks for this information... it is confirming what I originally thought, so I don't need to change my code (yet). But I wanted to post it back to the list to everyone else can benefit from it. I personally tend to avoid AUTOLOAD, only because it is a piece of perl magic that can be super-confusing to developers coming to perl (and mod_perl) from other languages (um, Java) and I think there's a voodoo-level involved that's a bit high for my tastes. In the one place I use it, I don't generate anything, just trap calls to methods with AUTOLOAD and perform a lookup based on the arguments. If it really is that slow, maybe I'll even rewrite that to use something other than AUTOLOAD. Cheers! Kyle Dawkins Central Park Software On Tuesday, Dec 17, 2002, at 13:13 US/Eastern, Perrin Harkins wrote: kyle dawkins wrote: Sorry to mail you directly... can you just give me two cents on your comment below about AUTOLOAD, mod_perl and memory sharing? I use AUTOLOAD in one module to perform accessors and I wonder if there's a better way to save memory. AUTOLOAD is kind of slow, so most people put something in there to define their accessors as subs by manipulating the symbol table. It's easy, and Damian's book has an example. In mod_perl, you want any methods that you expect to be called to be defined in the parent process so they will be shared. I do this by building all of the accessors in a BEGIN block in my module which is called when I use it in startup.pl. - Perrin
Re: AUTOLOAD in mod_perl (was Re: When perl is not quite fast enough)
Christopher Grau wrote:
I may be veering off-topic, but I've started doing similar things in my
own code (generating accessor methods via AUTOLOAD). I ended up writing
`Class::Autoload,' which I intend to upload to CPAN when I'm done with
documentation and testing.
Mine was very simple and didn't need to handle any odd cases, which was
why I didn't bother using a CPAN module. I would probably check
Class::MethodMaker before doing it this way again.
I had this in a shared class:
Package Util;
sub build_accessors {
my ($class, $pkg, $attr_names) = @_;
no strict 'refs';
foreach my $attr_name (@{$attr_names}) {
*{$pkg . ::$attr_name} = sub { return $_[0]-{$attr_name}; };
}
}
And then I would put something like this in the classes that needed it:
BEGIN {
my @attr_names;
@attr_names = qw(
foo
bar
baz
);
Util-build_accessors(__PACKAGE__, \@attr_names);
}
- Perrin
FW: DumpHeader Apache Perl Mod
Config: Apache::DumpHeaders 0.94 http://search.cpan.org/author/ABH/Apache-DumpHeaders-0.94/DumpHeaders.pm OS: Mandrake Linux 9.0 Apache: Apache-AdvancedExtranetServer/1.3.26 (Mandrake Linux/5mdk) mod_perl/1.27 Server Built: Sep 6 2002 19:31:19 mod_perl is functioning correctly as I tested it with the test file that ships with mod_perl: mod_perl-testscript.pl I followed the instructions for building and installing an Apache Perl mod, issuing the command perl -e DumpHeaders.pm; works fine. In the commonhttpd.conf file, I put the commands: IfModule mod_perl.c Location / PerlLogHandler Apache::DumpHeaders PerlSetVar DumpHeaders_File test.txt /Location /IfModule If I didn't wrap them in the IfModule.. Apache wouldn't load correctly. There are several .conf files in this Apache version: commonhttpd.conf httpd.conf httpd-perl.conf The commonhttpd.conf gets included in the main httpd.conf file. Problem: - I don't quite understand how this mod is supposed to work. The instructions say that it should write a file that contains the dump of headers.. but I don't see a file being written anywhere. The archive that Apache::DumpHeaders was in, didn't include any examples or a demo so I really don't know how it's supposed to be used. Being a log handler, I would think that it's something that gets executed for every page (which would be fine). I hope this is the correct place for this type on inquiry. Thanks Chris
RE: AUTOLOAD in mod_perl (was Re: When perl is not quite fastenough)
There is a number of modules on CPAN that already do similar things Ben -Original Message- From: Christopher Grau [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 12:05 PM To: [EMAIL PROTECTED] Subject: Re: AUTOLOAD in mod_perl (was Re: When perl is not quite fastenough) I may be veering off-topic, but I've started doing similar things in my own code (generating accessor methods via AUTOLOAD). I ended up writing `Class::Autoload,' which I intend to upload to CPAN when I'm done with documentation and testing. Basically, it exports an AUTOLOAD function that will work with the %FIELDS hash to insert accessor methods into the symbol table as needed. There's also a compile() method that can be used to precompile the methods, which I thought was relevent, given the mod_perl/memory discussion. It also provides for read-only methods, and a typing system like that of `Class::Class.' If there's interest, I'll clutter up the list some more with the POD. On Tue, 2002-12-17 at 11:13, kyle dawkins wrote: Perrin (et al... cc'ing this back to the list) Thanks for this information... it is confirming what I originally thought, so I don't need to change my code (yet). But I wanted to post it back to the list to everyone else can benefit from it. I personally tend to avoid AUTOLOAD, only because it is a piece of perl magic that can be super-confusing to developers coming to perl (and mod_perl) from other languages (um, Java) and I think there's a voodoo-level involved that's a bit high for my tastes. In the one place I use it, I don't generate anything, just trap calls to methods with AUTOLOAD and perform a lookup based on the arguments. If it really is that slow, maybe I'll even rewrite that to use something other than AUTOLOAD. Cheers! Kyle Dawkins Central Park Software On Tuesday, Dec 17, 2002, at 13:13 US/Eastern, Perrin Harkins wrote: kyle dawkins wrote: Sorry to mail you directly... can you just give me two cents on your comment below about AUTOLOAD, mod_perl and memory sharing? I use AUTOLOAD in one module to perform accessors and I wonder if there's a better way to save memory. AUTOLOAD is kind of slow, so most people put something in there to define their accessors as subs by manipulating the symbol table. It's easy, and Damian's book has an example. In mod_perl, you want any methods that you expect to be called to be defined in the parent process so they will be shared. I do this by building all of the accessors in a BEGIN block in my module which is called when I use it in startup.pl. - Perrin
AUTOLOAD in mod_perl (was Re: When perl is not quite fast enough)
Perrin (et al... cc'ing this back to the list) Thanks for this information... it is confirming what I originally thought, so I don't need to change my code (yet). But I wanted to post it back to the list to everyone else can benefit from it. I personally tend to avoid AUTOLOAD, only because it is a piece of perl magic that can be super-confusing to developers coming to perl (and mod_perl) from other languages (um, Java) and I think there's a voodoo-level involved that's a bit high for my tastes. In the one place I use it, I don't generate anything, just trap calls to methods with AUTOLOAD and perform a lookup based on the arguments. If it really is that slow, maybe I'll even rewrite that to use something other than AUTOLOAD. Cheers! Kyle Dawkins Central Park Software On Tuesday, Dec 17, 2002, at 13:13 US/Eastern, Perrin Harkins wrote: kyle dawkins wrote: Sorry to mail you directly... can you just give me two cents on your comment below about AUTOLOAD, mod_perl and memory sharing? I use AUTOLOAD in one module to perform accessors and I wonder if there's a better way to save memory. AUTOLOAD is kind of slow, so most people put something in there to define their accessors as subs by manipulating the symbol table. It's easy, and Damian's book has an example. In mod_perl, you want any methods that you expect to be called to be defined in the parent process so they will be shared. I do this by building all of the accessors in a BEGIN block in my module which is called when I use it in startup.pl. - Perrin
pass-thru/redirect/DECLINE to *.jpg
I have a completely mod_perl handler-based web app set up as so: Location ~ ^/myapp PerlHandler Client::WWW SetHandler perl-script PerlSetVar ConfigFile /home/ajm6q/myapp/data/www-config /Location The Client::WWW handler decides what to do based on the path_info of the URI (passing off responsibility in a ChainOfResponsibility pattern): http://www.mysite.com/myapp - home /myapp/newuser - new user functionality /myapp/deluser - delete user functionliaty And so on. What I'm having difficulty grasping is how to best handle image, js, css or other static resource requests that fall under the ^/myapp Location ... Client::WWW is currently trying to handle http://mysite.com/myapp/images/dot.gif To further complicate issues, the ConfigFile contains information about where various resources reside (perhaps /home/ajm6q/myapp/data/images for example). These are not under the server's DocumentRoot. I think my options are: 1. Reset the DocumentRoot in each Location to point to /home/ajm6q/myapp/data/, and have Client::WWW return DECLINED if the request is for a static resource, so that the request will drop back to Apache ... not sure this would even work, and makes the config file a tad worthless. 2. Install a translation handler that sets the filename of the request appropriately; not sure if this would prevent Client::WWW from handling the request, but would allow a DECLINED drop back to Apache to work without mucking with DocumentRoot ... I think. 3. Have Client::WWW do a subrequest (via lookup_file), and run that directly. 4. ??? TIMTOWTDI is getting me down right about now. Thanks for your advice, -Aaron
Re: [mp1.0] linking libperl.so fails because of G: command notfound
Hi Kenny, We use SunOS 5.8 with mod_perl 1.27 on SPARC processors. We don't use DSO but build mod_perl statically into httpd. Here is the configure we use for mod_perl: CC=cc \ /opt/perl5/bin/perl Makefile.PL APACHE_SRC=../apache-1.3.27/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 and for apache: CC=cc CFLAGS=-O -DEAPI \ ./configure --prefix=/web/adm/apache_1.3.27 \ --activate-module=src/modules/perl/libperl.a (this is actually a simplified version; we also enable a bunch of other shared modules) Note that 'cc' above is the Sun C compiler (ours is installed in /opt/SUNWspro/bin/cc). If you use gcc make sure you use it for both mod_perl and apache. I hope this helps! Keith This is how I configured apache: ./configure --prefix=/usr/local/kenny --enable-module=rewrite --enable-shared=rewrite --enable-suexec --suexec-caller=nobody --suexec-docroot=/usr/www --enable-module=so and this is how I configured mod_perl: perl Makefile.PL \ USE_APXS=1 \ WITH_APXS=/usr/local/apache/bin/apxs \ EVERYTHING=1
Release date for mod_perl 2.0
I am starting a new project that makes use of functionality required in Apache 2. Naturally, I would like to use mod_perl, but mod_perl 2.0 is still in beta. Can anyone offer any information about when they feel mod_perl will be stable enough for use in a production environment? I intend to use it with the prefork MPM in Apache, if that has any relevance to how stable mod_perl 2.0 is in that mode (since there should be no multithreading issues). I'm in a difficult position because the project will be completed in a couple of months. If the consensus is that mod_perl 2.0 will be released by that point, then everything will be fine (I'll develop using the beta code). If it is still months from being stable enough for release, I will have to investigate alternatives. Thanks in advance, -- Devin Heitmueller Senior Software Engineer Netilla Networks Inc
Re: Release date for mod_perl 2.0
On Dec 17 Devin Heitmueller wrote: Can anyone offer any information about when they feel mod_perl will be stable enough for use in a production environment? Sometime next year. See: [EMAIL PROTECTED]">http://mathforum.org/epigone/modperl/krekrouslor/[EMAIL PROTECTED] Now, back to lurking. Jim
Re: DumpHeader Apache Perl Mod
On Tue, 17 Dec 2002, Chris Dickerson wrote: IfModule mod_perl.c Location / PerlLogHandler Apache::DumpHeaders PerlSetVar DumpHeaders_File test.txt /Location /IfModule If I didn't wrap them in the IfModule.. Apache wouldn't load correctly. Er; then mod_perl is probably not enabled in the httpd that is using that configuration file. There are several .conf files in this Apache version: commonhttpd.conf httpd.conf httpd-perl.conf I don't know how Mandrake has set it up. If they change things around, they should have documentation on how it works. -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: pass-thru/redirect/DECLINE to *.jpg
Hi there, On Tue, 17 Dec 2002, Aaron J Mackey wrote: I have a completely mod_perl handler-based web app set up as so: Location ~ ^/myapp PerlHandler Client::WWW SetHandler perl-script PerlSetVar ConfigFile /home/ajm6q/myapp/data/www-config /Location [snip] What I'm having difficulty grasping is how to best handle image, js, css or other static resource requests that fall under the ^/myapp Location I'd tend to put image files etc in a directory of their own outside any which might be involved in Perl scripting, thus avoiding this issue. Is that not easy in your case? It seems a bit wasteful to have a mod_perl Apache process involved at all in serving .jpg and other static files. Why not run a two-Apache setup and let the non-mod_perl server serve them without even letting a heavyweight process see the request? It's described in the Guide. 73, Ged.
Re: Release date for mod_perl 2.0
On 17 Dec 2002, Devin Heitmueller wrote: [...] I'm in a difficult position because the project will be completed in a couple of months. If the consensus is that mod_perl 2.0 will be released by that point, then everything will be fine (I'll develop using the beta code). If it is still months from being stable enough for release, I will have to investigate alternatives. It will get stable faster if you choose to use it. :-) - ask -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: pass-thru/redirect/DECLINE to *.jpg
From: Ged Haywood [EMAIL PROTECTED] It seems a bit wasteful to have a mod_perl Apache process involved at all in serving .jpg and other static files. Why not run a two-Apache setup and let the non-mod_perl server serve them without even letting a heavyweight process see the request? It's described in the Guide. Not necessarily. There are always exceptions. For example, take a look at http://pics.beamartyr.net/ All of the pictures there go through mod_perl handlers which translate the entire path into a unique database entry. The application then stats the file on the filesystem, and does: my $fh=$pic-open; #returns the filehandle $r-send_fd($fh); close($fh); return OK; I used send_fd because it seemed from the documentation that it is a easier/better(?) method than rewriting the URI and setting default-handler. Is that not so? Issac
mod_perl fails tests
I am having some trouble installing mod_perl on my redhat linux 8.0 box. I successfully installed apache 2.0.43 from source and placed it in the /usr/local/apache2 directory. In addition, I downloaded the latest version of mod_perl from cvs. I successfully used the following command to generate the makefile: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1. Even though the make process was successful the make test process was not. As clear as I can tell from the error message that I listed below, mod_perl is looking for apache components in /home/software/apache_cvs/modperl-2.0/t/conf/httpd .conf which is clearly wrong since my httpd.conf file is in /usr/local/apache2/conf. Here is the error message: waiting for server to start: ...[Tue Dec 17 17:37:17 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:17 2002] [info] 5 APR:: modules loaded [Tue Dec 17 17:37:17 2002] [info] base server + 6 vhosts ready to run tests ..[Tue Dec 17 17:37:19 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:20 2002] [info] 5 APR:: modules loaded .[Tue Dec 17 17:37:20 2002] [info] base server + 6 vhosts ready to run tests Syntax error on line 693 of /home/software/apache_cvs/modperl-2.0/t/conf/httpd.conf: Can't locate CGI.pm in @INC (@INC contains: /home/software/apache_cvs/modperl-2.0/blib/lib/Apache2 /home/software/apache_cvs/modperl-2.0/blib/arch/Apache2 /home/software/apache_cvs/modperl-2.0/Apache-Test/lib /home/software/apache_cvs/modperl-2.0/lib /home/software/apache_cvs/modperl-2.0/blib/lib /home/software/apache_cvs/modperl-2.0/blib/arch /home/software/apache_cvs/modperl-2.0/t/response /home/software/apache_cvs/modperl-2.0/t/protocol /home/software/apache_cvs/modperl-2.0/t/hooks /home/software/apache_cvs/modperl-2.0/t/filter /home/software/apache_cvs/modperl-2.0/t /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/perlmodule-vh /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/main /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl) at (eval 22) line 3. !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 Thanks for your help- Rodney
Re: mod_perl fails tests
On Tue, 17 Dec 2002 [EMAIL PROTECTED] wrote: I am having some trouble installing mod_perl on my redhat linux 8.0 box. I successfully installed apache 2.0.43 from source and placed it in the /usr/local/apache2 directory. In addition, I downloaded the latest version of mod_perl from cvs. I successfully used the following command to generate the makefile: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1. I have a question related to this: Why the param MP_INST_APACHE2=? It would be good to be able to install apache in a user defined location, rather than only one location possible. This makes upgrades a bit risky. I maybe wrong, as documentation for apache2 is nowhere as clear as for apache 1.3*. Regards, Jie Even though the make process was successful the make test process was not. As clear as I can tell from the error message that I listed below, mod_perl is looking for apache components in /home/software/apache_cvs/modperl-2.0/t/conf/httpd .conf which is clearly wrong since my httpd.conf file is in /usr/local/apache2/conf. Here is the error message: waiting for server to start: ...[Tue Dec 17 17:37:17 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:17 2002] [info] 5 APR:: modules loaded [Tue Dec 17 17:37:17 2002] [info] base server + 6 vhosts ready to run tests ..[Tue Dec 17 17:37:19 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:20 2002] [info] 5 APR:: modules loaded .[Tue Dec 17 17:37:20 2002] [info] base server + 6 vhosts ready to run tests Syntax error on line 693 of /home/software/apache_cvs/modperl-2.0/t/conf/httpd.conf: Can't locate CGI.pm in @INC (@INC contains: /home/software/apache_cvs/modperl-2.0/blib/lib/Apache2 /home/software/apache_cvs/modperl-2.0/blib/arch/Apache2 /home/software/apache_cvs/modperl-2.0/Apache-Test/lib /home/software/apache_cvs/modperl-2.0/lib /home/software/apache_cvs/modperl-2.0/blib/lib /home/software/apache_cvs/modperl-2.0/blib/arch /home/software/apache_cvs/modperl-2.0/t/response /home/software/apache_cvs/modperl-2.0/t/protocol /home/software/apache_cvs/modperl-2.0/t/hooks /home/software/apache_cvs/modperl-2.0/t/filter /home/software/apache_cvs/modperl-2.0/t /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/perlmodule-vh /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/main /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl) at (eval 22) line 3. !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 Thanks for your help- Rodney
Re: mod_perl fails tests
That parameter is a *mod_perl* not an *apache* one it decides where the .pm files and such are installed whether in a directory 'Apache' or 'Apache2'. It will become the default eventually. But for now, its useful If you had 2 webservers 1.3.x and 2.0.x using the same version of perl say 5.8.x . Its lack of is also useful for Maintaining comaptibility with 1.x Modules not yet ported over. On Wed, 2002-12-18 at 01:23, Jie Gao wrote: On Tue, 17 Dec 2002 [EMAIL PROTECTED] wrote: I am having some trouble installing mod_perl on my redhat linux 8.0 box. I successfully installed apache 2.0.43 from source and placed it in the /usr/local/apache2 directory. In addition, I downloaded the latest version of mod_perl from cvs. I successfully used the following command to generate the makefile: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1. I have a question related to this: Why the param MP_INST_APACHE2=? It would be good to be able to install apache in a user defined location, rather than only one location possible. This makes upgrades a bit risky. I maybe wrong, as documentation for apache2 is nowhere as clear as for apache 1.3*. Regards, Jie Even though the make process was successful the make test process was not. As clear as I can tell from the error message that I listed below, mod_perl is looking for apache components in /home/software/apache_cvs/modperl-2.0/t/conf/httpd .conf which is clearly wrong since my httpd.conf file is in /usr/local/apache2/conf. Here is the error message: waiting for server to start: ...[Tue Dec 17 17:37:17 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:17 2002] [info] 5 APR:: modules loaded [Tue Dec 17 17:37:17 2002] [info] base server + 6 vhosts ready to run tests ..[Tue Dec 17 17:37:19 2002] [info] 19 Apache:: modules loaded [Tue Dec 17 17:37:20 2002] [info] 5 APR:: modules loaded .[Tue Dec 17 17:37:20 2002] [info] base server + 6 vhosts ready to run tests Syntax error on line 693 of /home/software/apache_cvs/modperl-2.0/t/conf/httpd.conf: Can't locate CGI.pm in @INC (@INC contains: /home/software/apache_cvs/modperl-2.0/blib/lib/Apache2 /home/software/apache_cvs/modperl-2.0/blib/arch/Apache2 /home/software/apache_cvs/modperl-2.0/Apache-Test/lib /home/software/apache_cvs/modperl-2.0/lib /home/software/apache_cvs/modperl-2.0/blib/lib /home/software/apache_cvs/modperl-2.0/blib/arch /home/software/apache_cvs/modperl-2.0/t/response /home/software/apache_cvs/modperl-2.0/t/protocol /home/software/apache_cvs/modperl-2.0/t/hooks /home/software/apache_cvs/modperl-2.0/t/filter /home/software/apache_cvs/modperl-2.0/t /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/perlmodule-vh /home/software/apache_cvs/modperl-2.0/t/htdocs/testdirective/main /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl) at (eval 22) line 3. !!! server has died with status 255 (t/logs/error_log wasn't created, start the server in the debug mode) make: *** [run_tests] Error 143 Thanks for your help- Rodney
RE: [mp1.0] linking libperl.so fails because of G: command not found
Hi Keith, Thanks for the reply. I've already figured been able to compile and get mod_perl running... I'm trying to report a bug in the configure script. It didn't set the PERL_LD variable in the Makefile. I want to try to find out why so that it can be fixed, so that other unsuspecting users don't have this same problem. :) Kenny Smith -Original Message- From: Keith McGlauflin [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 17, 2002 12:38 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [mp1.0] linking libperl.so fails because of G: command not found Hi Kenny, We use SunOS 5.8 with mod_perl 1.27 on SPARC processors. We don't use DSO but build mod_perl statically into httpd. Here is the configure we use for mod_perl: CC=cc \ /opt/perl5/bin/perl Makefile.PL APACHE_SRC=../apache-1.3.27/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 and for apache: CC=cc CFLAGS=-O -DEAPI \ ./configure --prefix=/web/adm/apache_1.3.27 \ --activate-module=src/modules/perl/libperl.a (this is actually a simplified version; we also enable a bunch of other shared modules) Note that 'cc' above is the Sun C compiler (ours is installed in /opt/SUNWspro/bin/cc). If you use gcc make sure you use it for both mod_perl and apache. I hope this helps! Keith This is how I configured apache: ./configure --prefix=/usr/local/kenny --enable-module=rewrite --enable-shared=rewrite --enable-suexec --suexec-caller=nobody --suexec-docroot=/usr/www --enable-module=so and this is how I configured mod_perl: perl Makefile.PL \ USE_APXS=1 \ WITH_APXS=/usr/local/apache/bin/apxs \ EVERYTHING=1
