Re: Apache::DBI with mod_perl 2.0
Zac Morris wrote:
Ahhh, ok more clarity. :)
Forgive me if I'm just not doing my detective work in poking around for
documentation, but is there a doc that contains all the kludges or
assumed modules I need to already have in place?
All the docs that we have now are at
http://perl.apache.org/release/docs/index.html
Most of the kludges are documented here:
http://perl.apache.org/release/docs/2.0/user/compat/compat.html
There are much more to come, but it'll take time. For now there is more
than enough docs to get yourself started. If something is unclear or
missing please shout aloud.
I'm assuming that the bulk of these things are handled via a CPAN
Apache::bundle install, and because mod_perl2 is still beta we don't have
that in place yet?
yes, but Apache::Module is an XS module using mod_perl 1.0's API, so it
won't be in the Apache::Bundle for 2.0. This patch may go in soon:
Index: lib/Apache/compat.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/compat.pm,v
retrieving revision 1.61
diff -u -r1.61 compat.pm
--- lib/Apache/compat.pm4 Jun 2002 12:40:53 - 1.61
+++ lib/Apache/compat.pm25 Jun 2002 15:17:56 -
@@ -91,7 +91,8 @@
}
sub module {
-require Apache::Module;
+eval { require Apache::Module };
+die Please install Apache::Module from CPAN if $@;
return Apache::Module::loaded($_[1]);
}
Thanks for all this info, learning more and more every day. :)
cool :)
__
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: liapreq problems
Brian Zammit wrote: I'm not sure if this is the right place to request assistance with this perl module installation issue. Please direct me to the proper person if possible. I have been trying to install the libapreq-1.0 module through CPAN and through the tar (Makefile.PL) to no avail. I keep getting various errors. The following error is what I get when trying to install through the Makefile.PL method. Any ideas on how to fix this? Is there a global variable called @INC that has to include the i386 directory? the issue is clear. You've installed perl and mod_perl from RPM (or other) packages compiled on different machine. So your perl package is using i686-linux for its arch specific libs, but on the machine mod_perl was compiled on it was i386-linux. recompile the mod_perl package (SRPM?) and then proceed to install apreq again. you could probably do some manual moves but I don't advise you to do that. --- [root@borg libapreq-1.0]# perl Makefile.PL make install Can't locate mod_perl.pm in @INC (@INC contains: /usr/local/lib/perl5/5.6.1/i686-linux /usr/local/lib/perl5/5.6.1 /usr/local/lib/perl5/site_perl/5.6.1/i686-linux /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl .) at Makefile.PL line 12. BEGIN failed--compilation aborted at Makefile.PL line 12. [root@borg libapreq-1.0]# slocate mod_perl.pm /usr/lib/perl5/site_perl/5.6.1/i386-linux/mod_perl.pm --- Thanks for your time, Brian. -- __ 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: Apache 2.0.39 and mod_perl
Kent, Mr. John wrote:
Greetings,
Attempting to build mod-perl with Apache-2.0.39
Following the instructions on:
http://perl.apache.org/release/docs/2.0/user/install/install.html
When I get to
CREATE THE BUILD ENVIRONMENT
and run
% perl Makefile.PL MP_AP_PREFIX=/home/stas/src/httpd-2.0.39
Get!!! Unable to open /users/webuser/src/httpd-2.0.39/include/apr.h: No such
file or directory
!!! Unable to open /users/webuser/src/httpd-2.0.39/include/apr.h: No such
file or directory
!!! Unable to open /users/webuser/src/httpd-2.0.39/include/apr.h: No such
file or directory
Repeated ...
/users/webuser/src/httpd-2.0.39/include is there, there just isn't any apr.h
file.
There is an ap_release.h file, should I copy that to apr.h?
Because in the source it's in httpd-2.0/srclib/apr/include/apr.h and
once installed it's in where_installed/include/apr.h
The install is indeed borked with MP_AP_PREFIX. I've never noticed this
problem since I'm still using MP_APXS, so for now try using MP_APXS
instead of MP_AP_PREFIX which is the path to the installed apxs, e.g. on
my machine it's MP_APXS=/home/stas/httpd/prefork/bin/apxs. This other
option was needed because of win32 and supposed to become the only
option to simplify things.
I've patched Build.pm to find apr.h and complete the build, but not sure
if that's the right thing. It's still incomplete since 'make test' won't
find apxs|httpd.
Index: lib/Apache/Build.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.102
diff -u -r1.102 Build.pm
--- lib/Apache/Build.pm 23 Jun 2002 21:46:09 - 1.102
+++ lib/Apache/Build.pm 25 Jun 2002 03:33:43 -
@@ -764,7 +764,9 @@
my $dir = $self-ap_includedir;
-my $header = $dir/apr.h;
+my $header = $self-{MP_AP_PREFIX}
+? $dir/../srclib/apr/include/apr.h
+: $dir/apr.h;
open my $fh, $header or do {
error Unable to open $header: $!;
return undef;
__
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 to mod_perl?
md wrote: Hello, I'm working on a dynamic site that I originally thought I would do with mod_perl. Now after reviewing the requirements and available hardware, I wonder if mod_perl will be my best solution. The machine will not be a huge box (though I wasn't provided much in the way of specs) and will only have 256M of RAM. There will be static content, incuding 5-10 images per page. The client has only given me sparse information, but claimed that he currently had 4,000 unique visitors a day and wanted to move to 10,000-15,000 unique visitors per day (he didn't give me page view stats). I may or may not be able to set up multiple instances of Apache. Given limited hardware (esp. RAM), am I better off to go with mod_perl (larger Apache processes with limited RAM) or CGI (smaller apache processes but the usual cons)? Don't get mislead by the memory requirements. If your code will run 10 times faster you will need *at least* 10 times less servers to do the job. But it's not uncommon to get even better speedups. So chances are that mod_perl will be a win in any case. Read the guide for restricting the memory used, shared memory, etc., and you are all set. It includes some numbers, showing how much memory you really need if you follow the guidelines. The only situation when mod_cgi could be a win over mod_perl is when you have almost zero code loaded and most of your operations are CPU or IO/bound, so mod_perl's precompilation/caching won't help much. but that's a very rare situation. In any case we are talking about registry scripts, aren't we? In that case it takes very little time to turn it on and off and test what is better. Unless you are talking about writing full fledged mod_perl API handlers, which is only when your should plan/analyze before you code. __ 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: (newbie) Problems compiling XML::LibXSLT
Sorry Scott, this is the *mod_perl* list. And this kind of questions is very non-desired here, since it has absolutely nothing to do with mod_perl. The XML::LibXSLT manpage includes the email of the author (hey Matt :) and he will be able to help you directly or point you to the mailing list that is created for this purpose if any. Please refrain from posting this kind of questions to this list in the future and stick to the mod_perl topics. Thanks. __ 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 to mod_perl?
Peter Bi wrote: wait a second ... don't forget using proxy: it saves you a lot of dynamical calls, especially if you have also a database. good point, Peter. And there are many others. It's the best if you can take some time and read the guide before you start coding. It includes a big chunk of the wisdow that passed through this list in the last 5 years. In your case I'd suggest reading at least: http://perl.apache.org/release/docs/1.0/guide/strategy.html http://perl.apache.org/release/docs/1.0/guide/scenario.html http://perl.apache.org/release/docs/1.0/guide/performance.html and probably these two: http://perl.apache.org/release/docs/general/perl_reference.html http://perl.apache.org/release/docs/1.0/guide/porting.html __ 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: Problems with PerlModule
Nikolaus Rath wrote: Hallo! Is it possible that PerlModule doesn't modify %INC? With PerlModule CGI in the Apache configuration, all scripts with use CGI produce warnings like: Subroutine put redefined at /usr/lib/perl5/5.6.1/CGI.pm line 517. Subroutine print redefined at /usr/lib/perl5/5.6.1/CGI.pm line 523. Subroutine cgi_error redefined at /usr/lib/perl5/5.6.1/CGI.pm line 529. Subroutine save_request redefined at /usr/lib/perl5/5.6.1/CGI.pm line [..] in the server log. (use strict and use warnings are active). Without PerlModule, all scripts run without warnings. And even with Perl use CGI; /Perl everything works fine. The CGI module is only an example. I have similar problems with several other modules. When reporting problems you *must* provide the information about your environment and used version as explained here: http://perl.apache.org/release/docs/1.0/guide/help.html#How_to_Report_Problems I believe that this particular problem has been solved in the recent mod_perl versions. -- __ 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: [JOB] Crack OOP Perl whitebox tester wanted
Phil Dobbin wrote: On 20/6/02 at 20:30, [EMAIL PROTECTED] (Tom Mornini) wrote: If you're a good Perl programmer who has a strong sense of the way it should be and can be simultaneously mean, nasty, angry, distrustful and [...] Sorry if I haven't kept up with this thread but, is this really the way the mod_perl list is going to go? Any clarification appreciated :-) Yes Phil, this is how it was since the beginning (1996) and the majority seems to be happy about this trend. If you want more info please read the archives, where this thread has been discussed to death many times. For those who are still confused here is a short summary: OK: - *mod_perl* job offers posts - *mod_perl* job seekers posts both using the [JOB] or similar tag, so those uninterested can skip it. See: http://perl.apache.org/release/maillist/email-etiquette.html#Tags NOT OK: - non-mod_perl offers/seekers posts - companies looking for projects posts - posts from the OK group without proper subject tags Though if you are a company providing a commercial *mod_perl* support, do submit the relevant URL for inclusion at this page: http://perl.apache.org/release/help/commercial.html Hope this explains all the confusions and keeps everybody happy. __ 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: [ANNOUNCE] Apache::DBI 0.89
Perrin Harkins wrote: Ask Bjoern Hansen wrote: In the last almost 3 years only two bugs has been found. Edmund no longer has time to make releases and such, so I fixed the last bug and made a new release which is available on CPAN. Thanks for taking over maintenance on this. Any thoughts about how to add support for threading in perl 5.8/mod_perl 2 to this? It might be premature, since the DBI/DBD modules are not necessarilly thread safe. the preforked mpm will use the same old Apache::DBI the threaded mpms will need a new version/mode of Apache::DBI using threads::shared, currently available only for 5.8.0-tobe, unless things will get backported to 5.6.2. Currently it seems that the threaded mpms will be safe to use only with 5.8.0, unless again things will get backported. Otherwise chances are that 5.8.0 will be a requirement. Originally Doug was planning on Apache::DBIPool described in his 2.0 overview: http://perl.apache.org/release/docs/2.0/user/overview/overview.html#Apache__DBIPool but since we now have threads::shared it's not needed anymore. __ 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
Fwd: Perl 5.8.0 Release Candidate 2
is quite normal, but a slow system may easily take an hour or more. If all tests are successful, make test will say All tests successful (unsurprisingly). If all tests are not successful, you may get a more detailed report by changing to the t/ subdirectory and running the harness script, something like this cd t ./perl harness You may need to set up your dynamic library path before that (the final message of make test should tell all the needed details). The more detailed report will be very useful when your report problems. Knowing your exact configuration is essential, too: usually running the myconfig script from the build directory produces this information. Note that some systems or configurations have known problems, see perldelta for details, no need to report them. In case you still see errors, please document them via the perlbug system, as detailed in the INSTALL file, section Reporting Problems. Finally note that if you happen to have a less common platform, like some of the rarer UNIXes, or something even more exotic, we will be glad to hear even of successes, not just about possible problems. =head2 Installing Once you are happy with the test results of Perl itself (or you are just feeling extraordinarily brave), you may consider installing it. The Perl development team has tried to guarantee that popular Perl applications like CGI, LWP, mod_perl and DBI/DBD work with 5.8.0. Note work, not necessarily work without warnings: for example DBD::Oracle works, but during compilation and testing you may see various warnings. Also in some cases not all the functionality of the modules may be available (yet). However... THIS IS A REAL NEW PERL RELEASE THAT IS BINARY INCOMPATIBLE WITH ANY PREVIOUS PERL RELEASE. THIS MEANS THAT YOUR OLD EXTENSIONS (.xs code, those Perl modules requiring a C compiler) WILL NOT WORK AND WILL HAVE TO BE RECOMPILED. (Pure Perl modules should continue working.) INSTALLING THIS PERL RELEASE WILL OVERWRITE YOUR CURRENT PERL RELEASE. (For example, /usr/bin/perl will become Perl 5.8.0.) DO NOT INSTALL THIS INTO PRODUCTION USE UNLESS YOU REALLY MEAN IT. If you still feel like installing this, you can do so by make install. If you want to install this, but want to install it into some less dangerous place (and not overwrite your current installation), do the following make realclean sh Configure -des -Dprefix=/test/perl580 -Uinstallusrbinperl make all make test and then the make install. The -Dprefix will place the Perl installation at the said directory (the Perl executable will be /test/perl580/bin/perl), and the -Uinstallusrbinperl will avoid overwriting /usr/bin/perl with a copy of the Perl 5.8.0 executable. =head1 Testing The Perl Installation You should test both your own code, and other code that you use. =head2 Testing Your Own Code Test your own code with perl 5.8.0, but in case of surprises read the perldelta.pod carefully before judging something as a bug. In some cases the behaviour of Perl has changed. =head2 Testing Perl Modules You should try reinstalling your favourite CPAN modules to guarantee that they will continue working under Perl 5.8. Note that if you find some module either failing its tests or you see the tests emitting warning messages, please first and foremost report these problems to the author of the module. Advise him/her about the impending 5.8.0 release and where to get the RC2 (you might for example point the author to this very message). Since there are hundreds of modules available, the Perl 5 developer team is not qualified to be experts on all of them; it is much faster if the module author resolves any problems. In some cases you may also consider contacting some mailing lists to ask for help (and to spread awareness of the upcoming 5.8.0), for example if your operating system or the modules have mailing lists of their own. =head2 That's it. =head1 AUTHOR Jarkko Hietaniemi on behalf of the Perl 5 developer team =cut __ 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: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI0.89)
Per Einar Ellefsen wrote: At 18:26 21.06.2002, Zac Morris wrote: I actually have a question along these lines I'm new to mod_perl myself, and I've just installed a new setup with Apache2 and the mod_perl2 beta. That's all working well and my old cgi-bin type stuff works under mod_perl great. Now I'm trying to get more into the mod_perl specific stuff and when I: use Apache::DBI I'm getting a can't find Apache.pm To use Apache::DBI do I need the old mod_perl 1 also installed running some kind of dual mode? Or is that not even an option since I'm running Apache2. I'm learning quick so if this is covered someplace just give me a quick pointer. As Apache::DBI hasn't been tested with mod_perl 2.0 yet, you will need to: 1) make sure you are using the prefork MPM for Apache (as Stas said, Apache::DBI can only work with that one) 2) You will probably need to run mod_perl 2.0 in compat mode: put PerlModule Apache::compat but first you need: PerlModule Apache2 or 'use Apache2' in startup.pl. see: http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules in your httpd.conf, before loading other modules (like Apache::DBI). You will probably also want to see the 2.0 docs at http://perl.apache.org/release/docs/ start here: http://perl.apache.org/release/docs/2.0/user/intro/start_fast.html but since it seems that you've it installed already, proceed here: http://perl.apache.org/release/docs/2.0/user/config/config.html#Enabling_mod_perl though I haven't tried, you should be able to use Apache::DBI with the compat layer and preforked mpm/ __ 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: Apache::DBI with mod_perl 2.0 (was Re: [ANNOUNCE] Apache::DBI0.89)
but first you need: PerlModule Apache2 or 'use Apache2' in startup.pl. see: http://perl.apache.org/release/docs/2.0/user/config/config.html#Accessing_the_mod_perl_2_0_Modules Nope, he did a clean mod_perl 2 install, without MP_INST_APACHE2 I think... so doesn't have an Apache.pm because mod_perl 1 wasn't installed before. ah, ok then, but most likely MP_INST_APACHE2 is going to be the default, so if later you need to install mod_perl 1.0 you don't have to wipe your 2.0 install first. so better start getting used to it :) -- __ 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: Naming convention for Apache 2 modules.
[CC'ing Andreas again] Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that using the CPAN.pm module to download the module would fetch the newest version of the module, regardless of whether you wanted the one for mod_perl 2.0 or mod_perl 1.0. That's true :( I hope Andreas can make PAUSE index both versions so CPAN.pm will display the two, but for that we need some sort convention so PAUSE can use to decide on. Andreas, any ideas regarding this issue? Thanks! __ 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: Error Handling
Gregory Matthews wrote:
Thank you for the link.
[Gregory, please remember to keep the threads on the list and not to
take them private without being asked to and worse, not sharing the
knowledge with the rest of the community]
This is the route I would like to go (My::Exeption). Could you please
provide a simple example of how I would utilize this in my code.
If you have the mod_perl cookbook, check the recipe 8.6 (it's not online).
otherwise depending on your needs you simply generate the response and
set the return code accordingly. For example as 8.6 suggests:
use Apache::Constants qw(SERVER_ERROR);
$r-custom_response(SERVER_ERROR, send more coffee);
Can somebody please submit a patch to this doc
http://perl.apache.org/release/docs/general/perl_reference.html#Exception_Handling_for_mod_perl
with a nice complete example, which does the exception handling and
generates a custom error response to user plus does the logging? The
existing material is nice, but misses real examples.
For example, I've uploaded Exeption.pm to the My directory.
I've inserted use My::Exeption; into my code.
Now, if I want to catch an internal server error and display a custom
message based on what caused the error, how would I call this module
from my code?
For example, say I try to load a module, use HTML::Template, which is
not available.
that would be a complile time error, which you cannot catch with eval
{}, you must use 'require() HTML::Template' for performing the run-time
testing.
This would cause an internal server error that I would
like to catch and display in neatly formatted HTML stating that.
The idea is that you try {} catch {} in perl:
eval {
require oops_i_did_it_again;
};
if ($@) {
my_exception_handler($@);
}
now inside my_exception_handler you do whatever you want, log to
error_log and send a nice error message to a user, or just log and
return SERVER_ERROR, or just send a message to a user if it's a user
error. Matt's section was showing how to use AUTOLOAD to autovivify
packages for each exception, but in really it should be a solid set of
classes that you should write. So start from the example above and work
from there.
The simplest my_exception_handler does:
sub my_exception_handler { die $_[0] }
__
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: Naming convention for Apache 2 modules.
Ian D. Stewart wrote: On 2002.06.18 09:57 Stas Bekman wrote: [CC'ing Andreas again] Stas is right. The only problem I see with MP_INST_APACHE2 is the fact that using the CPAN.pm module to download the module would fetch the newest version of the module, regardless of whether you wanted the one for mod_perl 2.0 or mod_perl 1.0. That's true :( I hope Andreas can make PAUSE index both versions so CPAN.pm will display the two, but for that we need some sort convention so PAUSE can use to decide on. Andreas, any ideas regarding this issue? An alternative approach could involve placing the functionality specific to mod_perl 2.0 in a sub-module, then conditionally importing that submodule depending on the value of $Apache::Registry::VERSION. This is not the case for the complex modules involving C, XS, custom directives and lots of code. As a module author I'd rather have a separate code base without gazillions of #ifdefs and perl side version checking. It's very unlikely that you will be able to extract mod_perl 2.0 specific functionality into a sub-module, because most of the Apache:: modules are using the mod_perl 2.0 API everywhere in the code. __ 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: mod_perl module documentation
Rich Bowen wrote: It has long frustrated me that there was no mod_perl module documentation, in the style of the standard Apache module documentation. I don't mean to bash the docs that are there - clearly, they are of exceptional quality. But I wanted something like the standard module docs. So, rather than complaining, which would seem to be, at best, in poor taste, given the quantity of stuff that folks like Stas have already written, I've started on a mod_perl module doc, based on the Apache 2.0 module documentation XML template. You can see the first cut at http://www.apacheadmin.com/mod_perl.html I know, it is gravely lacking, and needs help. And I intend to do something about that. But I have a few questions before I burn a lot of time on that. If you plan to leave it just as it's now (bare bones) it's ok. But if you plan to really write full fledged docs, please don't. Why duplicated efforts and confuse users with inconsistent documentation which is already *huge*. Have you see the work we have done in the last half a year? http://perl.apache.org/release/docs/ I've been working on docs similar to your doc recently: http://perl.apache.org/release/docs/2.0/user/config/config.html http://perl.apache.org/release/docs/2.0/user/handlers/handlers.html not very different than yours but adhers to the rest of the documentation. We already have 106 pods (2.3MB) and growing. So if you want to help please join the docs list and let's talk there: http://perl.apache.org/release/maillist/docs-dev.html#Subscription_Information we may come up with an idea to make Apache style docs as well, but only bare bones with pointers to the real docs. let's talk over docs-dev. Where, if anywhere, should such a document go? Yeah, it can stay where it is, but I would not think that anyone would think to look there. we have it already. Has someone already done this, and I'm just missing it? I know that there is similar information at http://www.apacheref.com/ref/mod_perl.html but I was hesitant to steal that wholesale. Besides, everyone should buy Ralf's book, and I don't want to dilute that in any way. ;-) Is there currently, or are there any plans for, a mod_perl documentation cvs repository, where something like this could live? the repository exists for some 9 months, called modperl-docs Anyways, tell me what you think. I have the original XML, which is vastly more useful than the HTML output, and would be glad to give that to anyone that wants it. see above __ 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: mod_perl2.0 / TIPool
Doug MacEachern wrote: On Thu, 13 Jun 2002, Stathy G. Touloumis wrote: Is there an idea of when the TIPool API will be available for mod_perl 2.0? probably never now that threads::shared has been implemented in perl-5.8, which can be used to provide the same functionality (i think). threads::shared came to be after writing about the Perl interface to TIPool. what about perl 5.8.0? __ 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: Perl_Tstack_sp_ptr
Paul G. Weiss wrote:
Sorry if this has been covered - I searched to no avail.
I'm getting the following error when trying to start
an Apache 2.0.36 with ModPerl::Registry:
/usr/libexec/ld-elf.so.1:
/usr/lib/perl5/site_perl/5.6.1/i386-freebsd-thread-multi/auto/Apache/Request
Rec/RequestRec.so: Undefined symbol Perl_Tstack_sp_ptr
All relevant build info is below. Has anyone seen and conquered this?
Confirmed, I've a similar problem on linux with 5.6.1
/home/stas/httpd/prefork/bin/httpd: relocation error:
/home/stas/apache.org/mp-5.6.1-prefork/ModPerl-Registry/t/../../blib/arch/Apache2/auto/Apache/RequestIO/RequestIO.so:
undefined symbol: Perl_sv_2pv
it happens when I run the test suite in:
ModPerl-Registry:
and I've traced it down to:
print exists $ENV{QUERY_STRING} $ENV{QUERY_STRING};
Though I don't understand why there is relocation error, the libperl.so
lib includes the symbol:
nm
/home/stas/perl/5.6.1-ithread/lib/5.6.1/i686-linux-thread-multi/CORE/libperl.so
| grep Perl_sv_2pv
0009ae10 T Perl_sv_2pv
and mod_perl is linked against it:
ldd src/modules/perl/mod_perl.so
libperl.so =
/home/stas/perl/5.6.1-ithread/lib/5.6.1/i686-linux-thread-multi/CORE/libperl.so
(0x40023000)
__
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: sub init() ... does this have any special purpose?
Mark Korey wrote: I was once told that in order for mod_perl CGI code to work properly all functionality/logic needed to reside in a function named init(). Now that I'm pouring over mod_perl documentation getting things running, I haven't found any mention of this. So ... is there any special purpose w/in mod_perl for sub init? or is it just a common naming convention? or is it baloney? There is nothing special about init(). Are you talking about initializing globals? or the closure effect with registry? That's two possible issues people may talk about a sub whose name can be init() or else. In your example there is no need for init(). __ 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: Perl_Tstack_sp_ptr
could this be a version of freebsd with broken threads support? i've
heard many cases of that. chances are if you rebuild perl without
-Dusethreads and apache with the prefork mpm, this problem won't be
there.
so the problem that I see on linux is unrelated?
this tested with prefork Apache cvs and perl built as:
./Configure -des -Dprefix=/home/stas/perl/5.6.1-ithread \
-Dusethreads -Doptimize='-g' -Duseshrplib -Dusedevel
Stas Bekman wrote:
Paul G. Weiss wrote:
Sorry if this has been covered - I searched to no avail.
I'm getting the following error when trying to start
an Apache 2.0.36 with ModPerl::Registry:
/usr/libexec/ld-elf.so.1:
/usr/lib/perl5/site_perl/5.6.1/i386-freebsd-thread-multi/auto/Apache/Request
Rec/RequestRec.so: Undefined symbol Perl_Tstack_sp_ptr
All relevant build info is below. Has anyone seen and conquered this?
Confirmed, I've a similar problem on linux with 5.6.1
/home/stas/httpd/prefork/bin/httpd: relocation error:
/home/stas/apache.org/mp-5.6.1-prefork/ModPerl-Registry/t/../../blib/arch/Apache2/auto/Apache/RequestIO/RequestIO.so:
undefined symbol: Perl_sv_2pv
it happens when I run the test suite in:
ModPerl-Registry:
and I've traced it down to:
print exists $ENV{QUERY_STRING} $ENV{QUERY_STRING};
Though I don't understand why there is relocation error, the libperl.so
lib includes the symbol:
nm
/home/stas/perl/5.6.1-ithread/lib/5.6.1/i686-linux-thread-multi/CORE/libperl.so
| grep Perl_sv_2pv
0009ae10 T Perl_sv_2pv
and mod_perl is linked against it:
ldd src/modules/perl/mod_perl.so
libperl.so =
/home/stas/perl/5.6.1-ithread/lib/5.6.1/i686-linux-thread-multi/CORE/libperl.so
(0x40023000)
__
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
--
__
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: installation problems
will wrote: I am trying to install mod perl as part of Apache-ASP and am stuck at the following error: Apache.exe -k start are you mixing Apache 2.0 with mod_perl 1.0? -k is an Apache 2.0 option whenever reporting problems you have to tell us what you are doing and what versions you are using see: http://perl.apache.org/release/docs/1.0/guide/help.html#How_to_Report_Problems http://perl.apache.org/release/docs/2.0/user/help/help.html#Reporting_Problems Can't locate Cwd.pm in @INC (@INC contains: .) at (eval 1) line 1. I've searched the web and haven't found any solutions. I have checked the perl @INC using 'perl -V' and the path to Cwd.pm is there: @INC: C:/Perl/lib C:/Perl/site/lib . but it only seems to actually be looking at the current directory. Not sure what to do next, or where to change these paths. I'm wondering if I need \s instead of /s? thanks for any help? will -- __ 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: [OT] mod_perl obfuscation / T-shirt ?
I was thinking about doing a mod_perl Obfuscation for some time, and today I found some time and wrote up something .. It's not that much obfusacated, but it looks nice (mod_perl in ASCII art) and works (see the POD after the code..) tres cool. yes, very cool Thomas, looks like a good idea for the new modperl site's obfuscation section :) __ 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: Apache Error Log
steve wrote: Hey people.. Wondering if someone could help me with this... Please do not repost your question 3 times! I recently started using modperl2/apache2. Everything seems to work ok except for Apache's error logging. I don't seem to get my apache stderr untill I shutdown/restart the server. Then it prints out the whole thing in one big batch. I read somewhere that modperl possibly takes over the logging handler for apache but I tried a PerlOptions -Log in the conf file and that doesn't seem to help. '-' turns options off, not the other way around. http://perl.apache.org/release/docs/2.0/user/config/config.html#PerlOptions_Directive And it's +Log by default. I posted my configuration along with this.. i don't really know what I'm doing when it comes to modperl2 so any help is appreciated.. thanks Are you talking about warn() and similar calls? You have to post a short code that we can reproduce the problem with and your build as explained here: http://perl.apache.org/release/docs/2.0/user/help/help.html#Reporting_Problems Also check: http://perl.apache.org/release/docs/2.0/api/mod_perl-2.0/Apache/Log.html __ 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: OSC early bird and mod_perl T-Shirts
Leon Brocard wrote: Stas sent the following bits through the ether: SB 2. We want T-Shirts. Is there some kind company to sponsor the SB mod_perl T-Shirts this year? I've just convinced my company (http://www.fotango.com/) to sponsor 50 tshirts with the mod_perl logo on. Once we get it all sorted out, we'll print them in the UK and fly them over with us to OSCON. I guess they will be allocated in a first-come first-served order. More details when I get it sorted out. That's fantastic Leon! Thanks for convincing your company to do that for us. To those who want to print mod_perl T-Shirts for themselves we need a nice design which can then be put on the site. So if you know a designer willing to help us here, please do that! And of course if other companies can contribute too, that would be great. I doubt 50 T-shirts will satify everybody :) __ 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: File-upload problem with netscape and Internet-Explorer
[EMAIL PROTECTED] wrote:
Hello,
I build a simple File-Upload form:
html
form action=test_upload enctype=multipart/form-data method=post
input type=text name=text
input type=FILE name=Tfile accept=*/*
input type=submit value=upload
/form/html
and a script test_upload, which is called from the form:
%perl
my $file = $r-upload;
my $ftype = $file-info-{'Content-Type'};
my $fsize = $file-size;
my $fname = $file-filename;
$m-out($ftype : $fsize : $fname);
/%perl
%ARGS
$Tfile = undef
/%ARGS
With netscape this works well, but with opera and internet-explorer
(tested with 6.0), $r-upload isnt defined? What am i doing wrong here?
Bye, Olaf
Try:
http://perl.apache.org/release/docs/1.0/guide/snippets.html#File_Upload_with_Apache__Request
__
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
OSC early bird and mod_perl T-Shirts
1. http://use.perl.org/article.pl?sid=02/06/06/1810253 gnat writes Early registration for the Open Source Convention (which includes The Perl Conference) ends June 10. You can save up to $750 if you register before then. 2. We want T-Shirts. Is there some kind company to sponsor the mod_perl T-Shirts this year? __ 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
tutorials (was: Re: rfc Apache::Dynagzip)
Per Einar Ellefsen wrote: At 15:36 05.06.2002, Valerio_Valdez Paolini wrote: On Tue, 4 Jun 2002, Slava Bizyayev wrote: I don't know should it be a kitchen of every system administrator, or somebody could volunteer to serve the public web site about the current conditions of different web clients and recommended masks?.. I can't host it on my devl4, because it is a development machine. That would be better to find some stable place, like mod_perl, or apache project ;-). Can you provide a compatibility list? I think that the new mod_perl site is looking for new articles, may be the first part of Apache::Dynagzip man page is a good candidate... You could add also known bugs and features. But I cannot decide what goes on mod_perl site :) Just like I would have said it myself :-) We're clearly looking for information, and I was especially watching this thread for possible inclusion. We have a nice place to do this, it's in our Browser bugs section. Depending on the size of the document, it might go there or in its own doc. Anyway, we welcome any submissions. Format is standard Pod. See http://cvs.apache.org/viewcvs.cgi/modperl-docs/admin/style.pod?rev=1.8content-type=text/vnd.viewcvs-markup for style information, but don't worry too much about that, we'll fix that as we go. I just want to add some clarifications to Per Einar comment. Are we looking for not strictly mod_perl but closely related material, which matters to the majority of mod_perl programmers? The short answer: Tutorials - yes manpages - no articles - take23.org The long answer: Tutorials cover some interesting topics using several implementations. Tutorials are pretty much static and don't require much maintenance. We heartly welcome these. The ongoing discission of MVC is a good example of a tutorial candidate, templating comparison and *generic* tips and tricks are other ones. Manpages, which aren't the core module are not very welcome at this moment, as they usually require high level of maintenance, and we have hardly resources to cope with perl.apache.org. So at least for now, manpages aren't welcome. If you have feature tutorials, either submit those to take23.org or any other online zine. perl.com is looking for such articles. so does apacheweek.com. probable there are others. The new perl.apache.org is not a dump place for docs. The more irrelevant stuff we throw there the less added value the site will have, the harder it'll be to find something and the whole idea of expanding docs will do more bad than good. So new tutorials are definitely welcome, but re-read the first para to see the definition of a good candidate and so the existing tutorials at: http://perl.apache.org/release/docs/tutorials/index.html before submitting your tutorial. If your idea of tutorial doesn't fit into perl.apache.org's tutorial's idea, we will gladly link to it. --- Now back to the topic. If you can submit to us known problems with browsers and solutions that would be great. But please don't submit the Apache::Dynagzip manpage. __ 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: DBI Bug
t/REPORT don't print any problem Udlei, please read the info at the URL I gave to you again. It says: Whenever you send a bug report make sure to include the information about your system by doing the following: % cd modperl-2.0 % t/REPORT mybugreport Also it explains how to get the backtrace (which is very essential): http://perl.apache.org/release/docs/2.0/user/help/help.html#Resolving_Segmentation_Faults __ 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: tutorials (was: Re: rfc Apache::Dynagzip)
Slava Bizyayev wrote: It's going to be something like Features of Content Compression for Different Web Clients for Part IV: Client side facts and bugs. We'll be able to discuss details next week. Sounds great, looking forward to it. Probably the best post it here first, so we can get it reviewed and commented on before we add it to the docs. __ 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: Perl 5.6.1 INIT blocks
D.J. Miller II wrote: Howdy, I'm trying to find out if Perl 5.6.1 INIT blocks are supported by mod_perl. By supported, I mean that the INIT blocks are executed each time the scripts containing them are run under mod_perl, not just at compilation time like BEGIN blocks. In fact they aren't supported at all, when you try to run them from inside requests -- you will get an error: Too late to run INIT block at ... In the ToDo file of the mod_perl 1.26 distribution I find: --- POSSIBLE NEW FEATURES --- - require +ExecCGI for Perl in .htaccess, etc. [...] - CHECK blocks? [Michael J Schout [EMAIL PROTECTED]] INIT blocks? [T.J. Mather [EMAIL PROTECTED]] In the 1.27 distribution there's no ToDo file, but no mention of INIT or CHECK block support in the Changes file, either. ToDo has moved into the STATUS file. __ 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: Apache-server_root_relative(); not found
m31 wrote: Thank you all for your help. You are correct, I didn't dawn on me that my ServerRoot is somewhat different than my document root. I was expecting it to return my documenrt root. (embarasment...hence SERVER_ROOT_relative()) Well, I printed out my @INC to screen, and now I have directories that do not exist in it from putting the wrong path in the server_root_relative method, can any-one tell me how to remove this dir from @INC? I treid a few ways but to no sucess. Please be more specific. What have you done to @INC so it includes non-existing dirs? You must have added them. A *short* code fragment is the best so we can reproduce the problem. Please be patient with idiocracy, I'm just a student trying to get ahead. Don't worry :) Just try to provide more details in first place, so there will be less ping-pong emails here. __ 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: Apache.pm failed to load!
[Please make sure to reply to the list on follow-ups, and not to the person who has answered your question. Thank you!] James Kirkland wrote: Hi, Thanks for replying. I continue to get the errors when adding that line to httpd.conf. Is there any specific point in the file to place it? When do you get this error James Kirkland wrote: Hi, I am getting the Apache.pm failed to load! error. I need help to resolve: [root@fisher mysql]# perl -MApache -e 1 You shouldn't be testing mod_perl modules from the command line. it won't work. If it happens under mod_perl, see: http://perl.apache.org/release/docs/1.0/guide/troubleshooting.html#_Apache_pm_failed_to_load__ __ 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: Apache.pm failed to load!
James Kirkland wrote: Hi, I am getting the Apache.pm failed to load! error. I need help to resolve: [root@fisher mysql]# perl -MApache -e 1 You shouldn't be testing mod_perl modules from the command line. it won't work. If it happens under mod_perl, see: http://perl.apache.org/release/docs/1.0/guide/troubleshooting.html#_Apache_pm_failed_to_load__ -- __ 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: DBI Bug
Perrin Harkins wrote: Udlei Nattis wrote: hi, sorry my english ;) when i add this line in httpd.conf PerlModule DBI or use DBI(); in startup.conf apache dont start, i receive this error: /usr/local/apache-2.0/bin/apachectl: line 192: 12547 Segmentation fault $HTTPD /usr/local/apache-2.0/bin/apachectl start: httpd could not be started i test it in Apache 2.0/Perl 5.8.0RC1/Modperl 1.99.02/03 Apache 2.0/Perl 5.7.3/Modperl 1.99.02/03 Apache 2.0/Perl 5.6.1/Modperl 1.99.02/03 Apache 2.0-cvs/All Perls/All Modperls It definitely works with the Apache 1.x/mod_perl 1.x/perl 5.6.1 combo. Maybe someone else can verify that they've run DBI under mod_perl 2? Works for me with 1.99, but see below. You might need to use the pre-fork MPM when using DBI, depending on how well your database driver works with threads. You should also make sure you compile all of these with the same compiler, to ensure compatibility between libraries. Folks, when you see a question like this, don't waste your time guessing in the dark without having the so needed details posted first. Just point them here: http://perl.apache.org/release/docs/2.0/user/help/help.html#Reporting_Problems You don't have to search for this item, it's in the shortcuts menu on the left. __ 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: Apache-server_root_relative(); not found
m31 wrote: I think we've narrowed it down to three choices, but why would my @INC list one thing from the terminal and another from mod_perl? Are they two seperate @INC's? mod_perl adds a few dirs to @INC on its own, but I still cannot understand what is your problem. Let's say you want to add '/Library/www/lib' to @INC. So inside startup.pl you do: use lib qw(/Library/www/lib); and that's it! Remember that you cannot affect @INC for the whole server from your handlers/scripts, as it gets reset after each request to the value it had after startup, so you can only change it during startup. -- __ 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: Apache-server_root_relative(); not found
m31 wrote:
HI, sorry if this is the wrong place, I am new to the mailing list.
This is the right place. If you are new to mod_perl, you probably want
to read the docs first. See: http://perl.apache.org/release/docs/
I have apache/1.3.23 and mod_perl/1.27 (I just upgraded) and perl/5.6.0
When I try:
BEGIN {
use Apache ();
use lib Apache-server_root_relative('lib/perl');
}
I get compilation errors saying that it can't locate object method
server_root_relative via pachage Apache. BEGIN failed.
Can any-one help me out or point me in the right direction?
Are you sure you are testing this under mod_perl? Also please be more
specific, where did you put this code: in a startup file, a script or a
handler?
You cannot test code including Apache API without running under mod_perl.
__
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: Apache-server_root_relative(); not found
On Mon, 3 Jun 2002, m31 wrote:
Yes, I'm running it under mod_perl/1.27 which I compiled as a DSO with
apxs. This also gave me errors under 1.25, I just pushed @INC to solve
it but I would like to use server_root_relative. I have it in a startup
script, the one from the eagle book. It goes like:
#! /usr/bin/perl
BEGIN {
use Apache ();
use lib Apache-server_root_relative('lib/perl');
}
use Apache::Registry ();
use Apache::Constants ();
use CGI qw(-compile :all);
use CGI::Carp ();
use DBI ();
1;
Which I had it to change to: push(@INC, '/Library/www/lib/perl');
because the server_root_relative gave me errors. I read some where that
in order to test with startup scripts you need to use the
Apache::FakeRequest? Even if so, if I ignore the errors and just restart
apache, it wont find 'lib/perl', so I have to push @INC manually then do
a graceful restart for it to work. I am running OSX 10.1.4/Darwin. Dont
think that has anything to do with it though.
There are two separate issues here:
1. you try to test perl code which only runs under mod_perl. but according
to your report you don't have a problem calling server_root_relative()
when you start the server. So this is not a problem, right?
2. your problem is that Apache-server_root_relative('lib/perl') doesn't
return what you expect. Is your ServerRoot set to '/Library/www'?
__
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: PERL Internals access
Burton, Craig wrote: If anyone there can give me some pointers to how to access the syntax tree for an executing Perl program, _from within that program_, I would be very grateful. I suspect this may not be possible. The O::Backend system seems to require the Perl program execute with overloaded Ops (example : Terse) and so the normal execution of the code is forfeited. I have fiddled with Devel::OpProf to get at what internal opcodes have executed, but really want to have my perl program somehow obtain the same large text dump created by a -MO=Terse printing, as part of my program's execution. I don't want to call Terse over the source .pl file either... sorry! Is something like B::Generate is what you are looking for? e.g. see: http://www.perl.com/pub/a/2002/05/07/optree.html Simon had an interesting paper in the last OSC's proceeding paper. I don't know if it's available online. It was called: B::Generate + Source Filters = use Python; In any case you probably want to move this discussion to some other perl specific list/forum, unless it has something to do with mod_perl. __ 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
5.8.0 RC1 has been released; please help testing it
. If all tests are successful, make test will say All tests successful (unsurprisingly). If all tests are not successful, you may get a more detailed report by changing to the t/ subdirectory and running the harness script, something like this cd t ./perl harness You may need to set up your dynamic library path before that (the final message of make test should tell all the needed details). The more detailed report will be very useful when your report problems. Knowing your exact configuration is essential, too: usually running the myconfig script from the build directory produces this information. Note that some systems or configurations have known problems, see perldelta for details, no need to report them. In case you still see errors, please document them via the perlbug system, as detailed in the INSTALL file, section Reporting Problems. Finally note that if you happen to have a less common platform, like some of the rarer UNIXes, or something even more exotic, we will be glad to hear even of successes, not just about possible problems. =head2 Installing Once you are happy with the test results of Perl itself (or you are just feeling extraordinarily brave), you may consider installing it. The Perl development team has tried to guarantee that popular Perl applications like CGI, LWP, mod_perl and DBI/DBD work with 5.8.0. Note work, not necessarily work without warnings: for example DBD::Oracle works, but during compilation and testing you may see various warnings. Also in some cases not all the functionality of the modules may be available (yet). However... THIS IS A REAL NEW PERL RELEASE THAT IS BINARY INCOMPATIBLE WITH ANY PREVIOUS PERL RELEASE. THIS MEANS THAT YOUR OLD EXTENSIONS (.xs code, those Perl modules requiring a C compiler) WILL NOT WORK AND WILL HAVE TO BE RECOMPILED. (Pure Perl modules should continue working.) INSTALLING THIS PERL RELEASE WILL OVERWRITE YOUR CURRENT PERL RELEASE. (For example, /usr/bin/perl will become Perl 5.8.0.) DO NOT INSTALL THIS INTO PRODUCTION USE UNLESS YOU REALLY MEAN IT. If you still feel like installing this, you can do so by make install. If you want to install this, but want to install it into some less dangerous place (and not overwrite your current installation), do the following make clean sh Configure -des -Dprefix=/test/perl580 -Uinstallusrbinperl make all make test and then the make install. The -Dprefix will place the Perl installation at the said directory (the Perl executable will be /test/perl580/bin/perl), and the -Uinstallusrbinperl will avoid overwriting /usr/bin/perl with a copy of the Perl 5.8.0 executable. =head1 Testing The Perl Installation You should test both your own code, and other code that you use. =head2 Testing Your Own Code Test your own code with perl 5.8.0, but in case of surprises read the perldelta.pod carefully before judging something as a bug. In some cases the behaviour of Perl has changed. =head2 Testing Perl Modules You should try reinstalling your favourite CPAN modules to guarantee that they will continue working under Perl 5.8. Note that if you find some module either failing its tests or you see the tests emitting warning messages, please first and foremost report these problems to the author of the module. Advise him/her about the impending 5.8.0 release and where to get the RC1 (you might for example point the author to this very message). Since there are hundreds of modules available, the Perl 5 developer team is not qualified to be experts on all of them; it is much faster if the module author resolves any problems. In some cases you may also consider contacting some mailing lists to ask for help (and to spread awareness of the upcoming 5.8.0), for example if your operating system or the modules have mailing lists of their own. =head2 That's it. =head1 AUTHOR Jarkko Hietaniemi on behalf of the Perl 5 developer team =cut __ 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: separating C from V in MVC
I think it'll be great to present the current discussion as a tutorial, so others can make a better use of the ideas thrown here, rather digging in archives. This could be a great addition to our growing tutorials section for the new site we are working on: http://perl.apache.org/release/docs/tutorials/index.html Any takers? While we are at it, if you are interested in writing tutorials on all kinds of topics related to mod_perl but don't fit into modperl docs (dbi, sql, caching, high availability, cool tricks, world domination, etc.) let us know at the docs-dev mailing list (or contact me) and we will help you with the details. Thanks! __ 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: Best compile options for perl 5.8 for mod_perl 1.x and 2.x
Chip Turner wrote: Subject pretty much says it all. What are the requisite 5.8 compile options, besudes ithreads, for proper functioning with either mod_perl branch? Or ones that should be avoided? it may be different on your OS (read the INSTALL doc), but on linux 2.4 I compile with all the defaults (-des): ./Configure -des -Dprefix=/home/stas/perl/ithread \ -Dusethreads -Duseshrplib and I add: -Doptimize='-g' so I can debug problems (don't put it in for production use) -Duseshrplib builds a shared libperl Also you don't need -Dusethreads (which is a bit slower) if you don't plan on using perl threads and threaded Apache mpms (i.e. when you use prefork) __ 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: Confusion: Perl/mod_perl ????
Doug Silver wrote: On Thu, 30 May 2002, Jeff McLean wrote: I have been programming in Perl for about 3 weeks now, and I just started doing some Perl CGI. I have Apache 2 installed on my linux system, but and my perl scripts work fine, but I don't knwo whether or not I'm using Perl (as in /usr/bin/perl) or mod_perl. I thought up untill recently that Apache has it's own version of Perl that it uses for CGI scripts (mod_perl) but I am now having doubts. Could someone please tell me exactly what the difference is between Perl and mod_perl, and how exactly mod_perl is used (.i.e. is it just for writing apache modules or is it just for CGI, or what) I'm big-time confuesd here. First go to the http://perl.apache.org/ site to get the full story. In short, think of mod_perl as a module that you start up with Apache that allows all of the perl scripts to run faster because the server doesn't have to launch a subprocess because mod_perl is in a sense Apache's version of perl. There are a lot of options/etc (this *is* perl we're talking about), so keep that in mind as you read through the documentation for what is applicable to your website. Actually the new site (which should be released realy soon now) has a nice and easy intro to mod_perl (thanks to Bill Moseley and others who helped): http://perl.apache.org/release/start/index.html So Jeff, you may want to start from this URL first. __ 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: Configuring mod_perl on Debian
Ian D. Stewart wrote:
On 2002.05.27 12:57 Andrew McNaughton wrote:
Sounds to me like you're not setting your content-type correctly for
some
reason. Have a look at the headers being sent out. It's either not
sending this header, or it's sending something the browser doesn't
know
what to do with.
This is the content of test.pl
BEGIN-SCRIPT
--
#!/usr/bin/perl
# your httpd.conf should have something like this:
# Alias /perl/ /real/path/to/perl-scripts/
# Location /perl
# SetHandler perl-script
# PerlHandler Apache::Registry
# PerlSendHeader On
# Options +ExecCGI
# /Location
print Content-type: text/html\n\n;
print bDate: , scalar localtime, /bbr\n;
print %ENV: br\n, map { $_ = $ENV{$_} br\n } keys %ENV;
--
END-SCRIPT
Based on this, I would expect the content to be set to text/html and the
page to be displayed to be a listing of the current environment.
Galeon identifies the content type as application/x-perl. This would
seem to indicate to me that Apache is serving the script directly
instead of executing the script and serving the output. According to
the mod_perl Guide, the ExecCGI option (which I have set for Location
/perl) is supposed to avoid this situation.
issue a request from the command line and look at the saved response.
Use lwp's GET, or 'lynx -dump' or any other favorite downloading utility.
__
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: back-tracking
Lucas M. Saud wrote: hi, i'm writting a module to highlighting of Perl syntactical structures, but the current code is very slow... :( i need some help to implementing a method of back-tracking or one way to revising a token that has already been formatted without reformatting the entire string? it's possible? if anyone interess, contact-me and i will send the source code... I fail to see what this has to do with the mod_perl list :( This kind of questions is *not* welcome here. __ 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: Carp interaction with mod_perl
Christian Gilmore wrote: How does the Carp module interact with mod_perl? Is there a built-in catch for croak or does it actually kill the child process, for instance? seems not to have any effect, i.e. it doesn't kill the process __ 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: Reloading Modules
Ted Prah wrote:
Hi again,
I'm having trouble seeing module changes when I reload
a script that uses it.
That's because Reload.pm doesn't re-exports the symbols when reloading
the module and test.pl doesn't call import() because it sees the module
in %INC, therefore it still sees the old sub till the moment it gets
recompiled. Below you will find a complete analysis.
I'm using Apache::Reload and my test
script/module is as follows:
test.pl
#!/usr/local/bin/perl
use strict;
use warnings;
use My::Test qw(:subs);
print Content-type: text/plain\r\n\r\n;
test1();
Test.pm
package My::Test;
use strict;
use warnings;
BEGIN {
use Exporter ();
our (@ISA, @EXPORT, @EXPORT_OK, %EXPORT_TAGS);
@ISA = qw(Exporter);
@EXPORT= qw();
@EXPORT_OK = qw();
%EXPORT_TAGS = (
subs = [qw(test1)],
);
Exporter::export_ok_tags('subs');
}
sub test1 { print In test1 func\n; }
1;
adjust the test.pl to do:
test1(); print \test1, \n;
#test2(); print \test2, \n;
and My::Test.pm to:
...
warn test1:, \test1, \n;
#warn test2:, \test2, \n;
sub test1 { print In test1 func\n; }
#sub test2 { print In test2 func\n; }
...
The first time you run the script you will see:
output:
In test1 func
CODE(0x85ad38c)
error_log:
test1:CODE(0x85ad38c)
you can see that both test1 and My::Test::test1 point to the same sub.
When I modify sub test1, and I reload - no changes appear
in the browser. The following gets printed to error_log:
Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/Test.pm line 22.
output:
In test1 func
CODE(0x85ad38c)
error_log:
test1:CODE(0x84ee110)
as you see the test1 is not the same as My::Test::test1
When I touch test.pl - the changes appear. The following gets printed
to error_log:
Subroutine test1 redefined at /export/home/httpd/cgi-bin/My/test.pl line 5
output:
In test11 func
CODE(0x84ee110)
now it points to the recent My::Test::test1
In that way you can debug any mysteries in Perl code.
Now, how to solve this problem. For example comment out
require $key;
in Reload.pm
that way, test.pl will see that My::Test is not in %INC, and require it
+ call its import() method.
Tell if this worked and we may adjust Reload.pm to have a special mode
where it makes Perl forget about modified modules and let the code that
loaded them in first place do the loading (and therefore the importing).
Finally, if I add a new subroutine test2 to Test.pm, export it, and
update the test.pl script to call test2, the script fails with an
Internal
Server Error. The following gets printed to error_log:
test2 is not exported by the My::Test module at
/export/home/httpd/cgi-bin/My/test.pl line 5
[Wed May 22 15:26:12 2002] [error] Can't continue after import errors at
/export/home/httpd/cgi-bin/My/test.pl line 5
BEGIN failed--compilation aborted at /export/home/httpd/cgi-bin/
My/test.pl line 5.
Then, when I restart the server, the script runs fine.
Hmm, this one is different. Seems like a bug in Exporter.
if you remove Reload.pm from the setup, so it won't confuse you and
adjust the code to do:
do My/Test.pm;
My::Test-import(':subs');
you will see that it fails as well. This code acts like Reload.pm, but
always reloads the module. So it's not Reload.pm's fault.
Is anybody else familiar with this Exporter's (mis)behavior?
The solution that I see is to use something like this:
package My::Test;
use strict;
use warnings;
sub import {
my $package = shift;
no strict 'refs';
for (@_) {
*{ (caller)[0] . ::$_ } = \{$_};
}
}
sub test1 { print In test1 func\n; }
sub test2 { print In test2 func\n; }
1;
If somebody else can see the problem with Exporter may be we need to run
it through p5p.
__
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
Fwd: ApacheCon session submissions: deadline is this Friday!
Original Message Subject: ApacheCon session submissions: deadline is this Friday! Date: Tue, 28 May 2002 13:15:57 -0400 From: Rodent of Unusual Size [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Organization: The Apache Software Foundation To: ASF members [EMAIL PROTECTED] Please make sure that all the appropriate project lists get a copy.. -- #ken P-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -- __ 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 ---BeginMessage--- -BEGIN PGP SIGNED MESSAGE- Greetings! Just a reminder: this Friday is the deadline for presentation proposals for the ApacheCon 2002 US conference in Las Vegas in November 2002.. To submit a proposal, visit URL:http://ApacheCon.Com/html/cfp.html. If you're not sure about a topic, or how well it might be received, you can ask other ApacheCon attendees by posting a message on the conference discussion list (see the Web page with the list details at URL:http://ApacheCon.Com/html/lists.html). Similarly, if you plan (or want) to attend the conference and want to request a particular topic, join the discussion list and say so. Not only will the planners then know, but you might trigger someone into proposing your ideal session! - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ Millennium hand and shrimp! -BEGIN PGP SIGNATURE- Version: PGPfreeware 6.5.8 for non-commercial use http://www.pgp.com iQCVAwUBPPO5sprNPMCpn3XdAQEsDAP/QCP8kv5WtiKCj+5Maof2qkwrJ8/LBkVi 4gJvuEgZQda2m2HzUfcAr7+mtSEEV3p8aispEes/bDCVLKWyPbnbc5PCTeLhN99c SXbjtTNzZf7lQeb36M/QLlrHgnP8ovUqln3w2P3AGETnl1gbiPnpA52cXW/L3vRH tZr55PXOY3I= =kib0 -END PGP SIGNATURE- ---End Message---
Re: Reloading Modules
Ted Prah wrote:
Thanks for the input Stats. I found your debugging methodology
to be very informative and especially useful in a mod_perl environment.
I tried your suggestion of commenting out
require $key;
in Reload.pm, but it did not work for me. I'd be happy to try
any other suggestions you might have.
But did you debug whether the module was reloaded from test.pl with the
modified Reload.pm? If so was the import() called? If not, try to have
it as a separate call:
require My::Test;
My::Test-import(':subs');
Your code to work around Exporter worked fine. However,
I think I'll stick with using Exporter so that I can make use
of the export tags.
But it doesn't seem to work? You can easily extend the import() function
I've suggested to suppport tags.
__
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: Invoke PHP scripts?
Ryan Thompson wrote: Thomas Klausner wrote to [EMAIL PROTECTED]: Hi! On Tue, May 28, 2002 at 09:48:14PM -0600, Ryan Thompson wrote: I'm developing a large-ish web site in which I would like to use a combination of mod_perl (90%) and PHP (10%). I have run into a roadblock trying to include the output of a PHP script from a mod_perl script. How about using notes()? http://perl.apache.org/release/docs/1.0/guide/snippets.html#Passing_Notes_Between_mod_perl_and_other__non_Perl__Apache_Modules __ 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: compile time errors
m31 wrote: Jie Gao wrote: On Tue, 21 May 2002, m31 wrote: I'm sorry (i wass in a rush), the errors come up when I run make test, the `perl Makefile.pl` works fine. (on OSX 10.1.4 (Darwin 5.4), Perl/5.6.0, mod_perl/1.25, apache/1.3.23) $ make test ...some more stuff /usr/bin/perl t/TEST 0 Can't locate object method new via package URI::URL at ../blib/lib/Apache/test.pm line 252. make: *** [run_tests] Error 255 http://groups.yahoo.com/group/modperl/message/42895 Jie Thankx, I added use URI::URL and I get past that but now it tells me: /httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t zsh: no such file or directory: /httpd do you pay attention to the printouts? See above. httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 22 I check t/log/.. and there's nothing in there, I have a full working vers of apache running, so I'm asuming its trying to make a fake request for testing. Any ideas? -- __ 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: Apache::GTopLimit
Perrin Harkins wrote: Stas Bekman wrote: Hmm, when a new process starts it shares *everything* with the parent. Why do you say that it's not? It doesn't share everything with the parent. As soon as it forks there is unshared memory, and after the first request it handles there is usually more. Over time, the average amount of shared memory among child processes seems to gradually decrease. Restarting fixes this. What you are saying is that when the server is started afresh, the newly started child processes share more memory with the parent, than newly started child processes some time later. Am I correct? __ 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: Apache::GTopLimit
Perrin Harkins wrote: Stas Bekman wrote: What you are saying is that when the server is started afresh, the newly started child processes share more memory with the parent, than newly started child processes some time later. Am I correct? Yes, exactly. Any ideas why? I always do a full restart, so I've never noticed the problem. __ 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: Apache::GTopLimit
Gregory Matthews wrote: Stas: Since you wrote the script, do you recommend some good default settings in GTopLimit to start with, i.e., Not really. It all depends on how many modules do you use and how big they are when compiled. I repeat many times in the guide, that all the examples are only examples. pretty much each setup is unique and there is no one-fit all setting. use Apache::GTopLimit; Apache::GTopLimit-set_max_size(1); Apache::GTopLimit-set_min_shared_size(4000); Apache::GTopLimit-set_max_unshared_size(6000); Use Apache::VMonitor and it'll give you a good idea what are the settings that you want. Since it shows you the shared and max sizes. $Apache::GTopLimit::CHECK_EVERY_N_REQUESTS = 2; This one is easy. If your processes are losing the shared memory slowly, raise this number, so less checks will be made. Otherwise keep it small. Again work with Apache::VMonitor and you will figure out the perfect setup. I would like to start with recommended defaults and tweak if necessary from there. See above. __ 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: Apache::GTopLimit
Perrin Harkins wrote: Stas Bekman wrote: Perrin Harkins wrote: Stas Bekman wrote: What you are saying is that when the server is started afresh, the newly started child processes share more memory with the parent, than newly started child processes some time later. Am I correct? Any ideas why? Not really. I thought maybe it was because of something changing in the parent process, but that doesn't seem possible. There was a long thread a little while back about turning swap off and on again to solve this. I've never tried that. I think restarting every 24 hours is a good idea anyway, because I've seen strange things happen now and then when a server is up for a long time. But that's unrelated to whether you kill the processes or not. Has anyone seen a similar behavior as described at the top of this post, when you have no swapping at all? I think restarting every 24 hours is a good idea anyway, because I've seen strange things happen now and then when a server is up for a long time. It probably depends on what you do. I've restarted my production servers once in a few months, when something was going wrong. But as I said it depends on what do you do with mod_perl. __ 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: GTop
Gregory Matthews wrote: When trying to install GTop, I received the following Note (probably harmless): No library found for -lgtop Note (probably harmless): No library found for -lgtop_sysdeps Note (probably harmless): No library found for -lgtop_common Note (probably harmless): No library found for -lglib Can't exec glib-config: No such file or directory at (eval 18) line 12. Note (probably harmless): No library found for -lgtop Note (probably harmless): No library found for -lgtop_sysdeps Note (probably harmless): No library found for -lgtop_common Note (probably harmless): No library found for -lglib You have to install first the development libraries (including glib-config). Either fetch them from http://fr.rpmfind.net/linux/rpm2html/search.php?query=libgtop if you on linux, or try the source: ftp://ftp.gnome.org/pub/GNOME/stable/sources/gtop/ __ 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: Reloading Library Files
Ted Prah wrote: do you test only this script alone? What happens if you add the package declaration and then call it using the full name? e.g.: Yes, this is the only script (and corresponding library file) that I use for this test. When I use the package declaration and make the call using the full name, the reloads work fine. The reason I am using the library file is to follow your recommendation in the mod_perl guide where a script is split into two files to avoid the nested subroutine problem. Out of curiosity I tested the sample code (counter.pl and mylib.pl) and they too did not reload properly when mylib.pl was modified. Does the reloading of a modification of mylib.pl work for you? I would prefer to use the library file approach as opposed to the package approach as a lot of our code uses libraries that are not in packages, but will move to packages if that is a necessity. Well, that explains everything. When you require() a library without that doesn't declare a package for the first time from the registry script, all its global symbols (subs, vars, etc) get imported into the namespace of the caller, i.e. the registry script (APACHE::ROOT::...). When Apache::Reload require()s that library that doesn't declare a package, all the global symbols end up in the Apache::Reload namespace! So the library does get reloaded and you see the compile time errors if there are any, but the symbols don't get imported to the right namespace. So the old code is running. Moreover this leads to a pollution of the Apache::Reload namespace, which may cause to problems if you happen to overwrite some of its symbols (subs, vars, etc). I suppose if you want to use the cheap workaround, you have to s/require/do/. Remember that the guide suggests the lib.pl trick as a workaround, not a solution you go with during the normal development. Was this explanation clear enough? We need to add it to the Apache::Reload manpage to avoid this kind of questions in the future. Funny though, that it's the first time this problem has been reported. Which shows that most of the people don't use workarounds when they do real developments :) __ 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: New mod_perl website [Was Re: Modifying @INC via startup.pl]
Drew Taylor wrote: This is a little OT, but I really love the new look of the website you mention below. Major kudos to all those who helped put together the new look-n-feel content. Thanks Drew, but please hold off on any comments, since we are still tuning the design to work better in various browsers. Once we are satisfied with it, we will make an announcement and then ask you to check if you have any problems with your favorite browsers. Meanwhile if you are willing to help or want to comment on things, please join the [EMAIL PROTECTED] list. We do need your help. BTW, the final site will be at http://perl.apache.org/. The http://perl.apache.org/release/ URL is only temporary. __ 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: Reloading Library Files
Ted Prah wrote: That explains the library files not reloading - Thanks! Great! I suppose if you want to use the cheap workaround, you have to s/require/do/. Remember that the guide suggests the lib.pl trick as a workaround, not a solution you go with during the normal development. I didn't realize that using the library wrapper was a cheap workaround to the nested subroutine problem. The effects of the nested subroutine problem is my biggest concern with writing code for mod_perl. What I liked about the lib.pl trick is that it completely eliminates this problem. I won't lose sleep wondering if somehow the code went into production with a nested subroutine. I realize that there are other ways to eliminate the nested subroutine problem, but what are the preferred techniques used by mod_perl developers? Check the error_log file for problems and fix as needed? The majority are discussed here: http://perl.apache.org/release/docs/general/perl_reference.html#Remedies_for_Inner_Subroutines Declaring the package in your libs is a good idea. Because if you don't, most likely you are going to encounter this problem: http://perl.apache.org/release/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs The solutions are discussed there as well. Check the error_log file for problems and fix as needed? Ted, this is not an option, this is a must thing to do. If you don't monitor constantly the error_log file while developing you are looking for a trouble. http://perl.apache.org/release/docs/1.0/guide/debug.html#Warning_and_Errors_Explained __ 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: undef Upload object
Geoffrey Young wrote: Mike Melillo wrote: I am trying to have a user upload an image and I am getting an undef $apr-upload object. we have a working example that may be able to help you some: http://www.modperlcookbook.org/code/ch03/Cookbook/PrintUploads.pm also see the new addition contributed by Rich Bowen: http://perl.apache.org/release/docs/1.0/guide/snippets.html#File_Upload_with_Apache__Request __ 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: Memory Leaks
Per Einar Ellefsen wrote: At 23:54 20.05.2002, Allen Day wrote: I've noticed that if I restart apache while I'm in the middle of a download (MP3 stream), after the buffer in my MP3 player runs out, it skips to the next track -- presumably because the connection was closed. This might cause a problem for you if your users are downloading big files. They might have to restart from the beginning if they didn't cache the partial download somewhere. Hmm, if you are serving big files off of mod_perl, memory leaks are the least of your problems :) Well, you can serve big files without reading them into a memory at once. Why there would be memory leaks? That doesn't apply to Apache::MP3 of course, for which it's normal, but in no case should your mod_perl server be serving your big files. The reason for not serving big files with mod_perl, is that you don't want to tie heavy and snappy mod_perl servers to wait indefinitely for the client to grab their data. If you have plenty of memory or you have just a few clients (intranet?) that's just fine. This is all discussed here: http://perl.apache.org/release/docs/1.0/guide/strategy.html#Adding_a_Proxy_Server_in_http_Accelerator_Mode __ 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: Memory Leaks
Gregory Matthews wrote: Does using the Apache::GTopLimit module have the same net effect as restarting the server itself by simply killing off the actual processes which are growing beyond the set threshold, and thereby causing new processes to be born? It's not the exactly the same, since it won't pick up any changes in Perl modules on the disk. And that's one of the main reasons for doing restarts. Otherwise yes. __ 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: Monitoring the processes
Gregory Matthews wrote: Thanks to everyone for the great input on Memory Leaks. Now that I have a good starting point for tracking down the problem, when I TEST for leaks, or simply check for a continued increase in server memory usage, how do I go about monitoring the processes growth? For example, is there a command line tool to use that will allow me to see the process growth upon request reload? I know that I should run the server with httpd -X, but I don't know how to actually see the memory being used/increased/decreased when the prog is being executed. As I understand it, this is a good indication that there might be a problem. Apache::VMonitor is great! (well, I wrote it :) Gregory, before you continue asking more questions... it's all the guide: http://perl.apache.org/release/docs/1.0/guide/performance.html#Measuring_the_Memory_of_the_Process so before you ask, check the guide. Use the search if you don't know where to look. __ 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: Apache::GTopLimit
Perrin Harkins wrote: Does using the Apache::GTopLimit module have the same net effect as restarting the server itself by simply killing off the actual processes which are growing beyond the set threshold, and thereby causing new processes to be born? It does kill off processes that are getting too big, and you definitely should use either GtopLimit or SizeLimit to get the most out of your server. However, it's not quite the same thing as a restart. Over time, some of the shared memory from the parent process appears to become unshared, and new processes that are spawned start out with less shared memory because of this. Hmm, when a new process starts it shares *everything* with the parent. Why do you say that it's not? It doesn't matter if the process gets killed because of MaxRequestPerChild or FooLimit thresholds. __ 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: Reloading Library Files
Ted Prah wrote: Hi, I am new to mod_perl and am having problems seeing the changes made to library files. Must I restart the server every time I change a library file in order to see my changes? My test code and environment is below. Hmm, I haven't used StatINC for a long time, any luck with Apache::Reload? http://perl.apache.org/guide/porting.html#Using_Apache_Reload __ 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: Scripts and passwd
[EMAIL PROTECTED] wrote: Hello Thanks for the reply. Yes this server is running mod perl :) As for risky. Well the whole point of the script system is to add a pop mail box for a user. But in order to do this i have to do the following: add user to the passwd/shadow file add user to the virtusertable and genericstable recompile the sendmail config files Then and only then is the new mailbox ready for use. This is the only way I can think of to accomplish this via an automated web proccess. I dont even know if you can do it any other way with out touching the passwd/shadow files? You probably want this article: Safely Empowering Your CGI Scripts by Lincoln D. Stein http://www.samag.com/documents/s=1286/sam03020006/ __ 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: Reloading Library Files
Ted Prah wrote:
Thanks Drew, I tried that, but it did not work.
What happends if you add:
PerlWarn On
in httpd.conf
or
start the script with perl -w?
any warnings?
do you test only this script alone? What happens if you add the package
declaration and then call it using the full name? e.g.:
z.pl - test script which calls entry_point in z_lib.pl
---
#!/usr/local/bin/perl -w
use strict;
require '/home/cgi-bin/z_lib.pl';
My::Z::entry_point();
---
z_lib.pl
--
package My::Z;
use strict;
sub entry_point {
my $r = Apache-request;
$r-content_type('text/html');
$r-send_http_header;
print HERE 1;
#print HERE 2;
}
Ted
Drew Taylor wrote:
Have you tried moving the PerlInitHandler PerlSetVar up and out of the
Location directive, making it global for the server? I'm not sure that
would fix it, but it's worth a try.
Drew
At 02:37 PM 5/17/02 -0400, Ted Prah wrote:
I have tried Apache::Reload as well, but I get the same results.
Ted
Drew Taylor wrote:
Take a look at Apache::Reload or Apache::StatINC. Reload is more flexible,
but StatINC has been around a little longer. Both have worked well for me.
But be sure that you don't use these modules on a production server. :-)
httpd.conf
==
PerlInitHandler Apache::Reload
Drew
At 01:38 PM 5/17/02 -0400, Ted Prah wrote:
Hi,
I am new to mod_perl and am having problems seeing the
changes made to library files. Must I restart the server every
time I change a library file in order to see my changes? My
test code and environment is below.
==
Drew Taylor | Freelance web development using
http://www.drewtaylor.com/ | perl/mod_perl/MySQL/postgresql/DBI
mailto:[EMAIL PROTECTED] | Email jobs at drewtaylor.com
--
Speakeasy.net: A DSL provider with a clue. Sign up today.
http://www.speakeasy.net/refer/29655
==
--
Ted Prah
NetCasters, Inc.
Phone: 978.887.2100 x44
Fax: 978.887.6750
[EMAIL PROTECTED]
--
__
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: Apache::Leak
-cvrundiff('LeakTest1::test', a string);
$diff = $lexi-cvrundiff('LeakTest1::test', a string);
print $$diff;
no output is produced, since there is no difference between the second
and the third run. All the data structures are allocated during the
first execution, so we are sure that no memory is leaking here.
CApache::Status includes a CStatusLexInfo option which can show
you the internals of your code via CB::LexInfo. See Chapter
[XREF=debug.pod].
__
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: sending CGI ouput through a handler
Allen Day wrote: Okay, I realize this has probably been covered before, but I couldn't find anything in the archive... I have a configuration like this: Location / SetHandler perl-script PerlHandler My::Handler /Location My::Handler takes the requested file and adds some markup to it with the Template Toolkit if the MIMEtype of the file is text/html. I want to be able to use the same handler to also add markup to the output of executed CGI. What is the best way to do this? Should I set up a separate location for the CGI (I'm doing this, actually) ? Are there any extra directives needed? by CGI do you mean a script running under mod_cgi? If it's registry you should be able to use stacked handlers: http://perl.apache.org/release/docs/1.0/guide/config.html#Stacked_Handlers __ 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: make test problem
Jie Gao wrote: Just got one from cvs and 'make test' hangs on apr/util: please run in the verbose mode: t/TEST -v apr/util if it doesn't help to reveal the problem try to enable tracing: http://perl.apache.org/release/docs/2.0/user/config/config.html#General_directives or attach with gdb and send us the trace of where it hangs. __ 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: sending CGI ouput through a handler
Allen Day wrote: My::Handler takes the requested file and adds some markup to it with the Template Toolkit if the MIMEtype of the file is text/html. I want to be able to use the same handler to also add markup to the output of executed CGI. What is the best way to do this? You can't feed the output of mod_cgi to mod_perl, at least not in Apache 1.x. The best thing to do (at least for performance) would be to rewrite the CGI so that you call it as a module from your handler. Another approach would be to use Apache::Filter to grab the output from PerlRun or Regsistry. You could also sublass PerlRun or Registry and add your handler code to it. So what about in Apache 2.x ? Is there a way to address this? Yes, you will be able to, thanks to I/O filters. See the mod_perl 2.0 test suite under t/filter/. I'm trying to convert a site that has lots of independent CGI to one that contains the output of said CGI in a set of templates. I'd rather not have to make modifications to the existing CGI to bring them in. Run them under Apache::Registry or PerlRun. Then use Apache::Filter as Perrin has suggested. My suggestions of using stacked handlers may work too with a custom subclass of Apache::RegistryNG. __ 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: Apache::DB
Gregory Matthews wrote:
Hello All.
I am trying to install Apache::DB and am getting the following error:
+
make test
cc -c-DVERSION=\0.06\ -DXS_VERSION=\0.06\ -DPIC -fpic
-I/usr/libdata/perl/5.00503/mach/CORE DB.c
In file included from /usr/include/sys/time.h:289,
from /usr/include/sys/stat.h:50,
from /usr/include/sys/mount.h:44,
from /usr/libdata/perl/5.00503/mach/CORE/perl.h:376,
from DB.xs:2:
/usr/include/time.h:2: syntax error before `1989'
/usr/include/time.h:26: empty character constant
/usr/include/time.h:32: syntax error before `PROFITS'
/usr/include/time.h:115: syntax error before `}'
*** Error code 1
You have a corrupted /usr/include/time.h, reinstall the package that it
comes with or simply borrow this file from some other machine.
before you try to build Apache::DB try to build test.c with the contents:
#include time.h
int main(void){return 0;}
and then compile it:
% cc test.c
once it works move onto Apache::DB
__
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: modperl idle timeout....
Jim Morrison [Mailinglists] wrote: Anyhow... I was wondering... is there a simple way to set up a sort of idle timeout to get each single httpd to restart itself if two conditions are met: - 1 - It has compiled mod_perl - 2 - The mod_perl aliases have not been accessed for 'x' minutes... What do you guys recon... is crontabbing a restart easier.. is it ill advised? (Ofcourse the restart runs even when you are using mod_perl.. which doesn't really help anyone.. cos then it has to go through the restart lag.. ) Oh well... would love to hear your thoughts, You can do this only with an external process, since child processes cannot communicate with each other. Though you have the scoreboard which is probably what you want. Look at Apache::Watchdog::RunAway, you can adjust it easily to do what you want. Though you pay the price of enabling the scoreboard extended updates on the live system, which adds a slight overhead to each request's response times. But using the crontab seems much simpler 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
Re: [OT] Refs don't work, like I want
Viljo Marrandi wrote: Sorry about non mod_perl question, but as I'm subscribed to this list and I know I can get help from here, I ask my question here. Please do NOT do that in the future. This is the *modperl* list. There are hundreds of perl lists which will gladly help you out. perlmonks.org is one of these places. Folks, please refrain to reply to this kind of questions, but instead send those who ask to the other resources, *without* answering the question, no matter how simple it is. Don't encourage people to be lazier than they are already. I know I don't sound nice, but we try hard to keep a low Sound to Noise Ratio here. Please help to keep this list useful to those who seek mod_perl help and clean of noise for those who can help. p.s. I usually don't bash this kind of posts, but this one was saying: as I'm subscribed to this list and I know I can get help from here, I ask my question here. it's not very nice of you, Viljo. Please subscribe to other relevant lists and ask the questions there if they don't belong here. __ 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: [OT] Refs don't work, like I want
Stas Bekman wrote: I know I don't sound nice, but we try hard to keep a low Sound to Noise Ratio here. of course I meant a *high* Sound to Noise Ratio. the heat and humidity shows :) p.s. sorry for adding to the noise. back to work on adding more sound. __ 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: Apache::DB
[please don't forget that to CC the list!]
Gregory Matthews wrote:
Stas:
Thanks for your reply on my issue in the Mod_Perl list.
Excuse my ignorance, but how do I do the following:
before you try to build Apache::DB try to build test.c with the contents:
#include time.h
int main(void){return 0;}
and then compile it:
% cc test.c
If you could point me in the right direction, I can figure it out! I am
running FreeBSD.
Thanks.
Gregory
create a file named test.c, put inside:
include time.h
int main(void){return 0;}
now you need to compile it with:
cc test.c
if this doesn't work (i.e. you get compilation errors, you have to ask
for assistance on the FreeBSD mailing list(s) or elsewhere, since your
problem has nothing to do with mod_perl.
__
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: Apache::DB
Gregory Matthews wrote: Stas: Out of curiosity, what do YOU use to debug perl running under mod_perl? Apache::DB __ 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: Moving from CGI to mod_perl
[Please make sure to post follow-ups to the list! Thanks!] Anton Permyakov wrote: Hi, all. I have perl CGI-script, and i wanna run it as mod_perl script. Is it enought to correctly edit only httpd.conf, or i've to add something special in my CGI-script? Maybe something like use Apache::Registry; or something else Also is it needed to write some special script like startup.pl or not? Thank you all, and sorry for this easy question... In doc i could not find How to migrate from CGI to mod_perl - step by step easy example. http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/getwet.html#Porting_Existing_CGI_Scripts_to_run_under_mod_perl __ 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: Memory usage option in Apache::Status
[EMAIL PROTECTED] wrote: Hope someone can give me a hand on this, I am having some problem using the Memory Usage option in the main menu of Apache::Status. It always return me a 500 with the following error. [Tue May 14 08:48:21 2002] [error] Can't call method size on unblessed reference at /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/Size.pm line 94. Do you have B::Size installed? perl -MB::Size -e1 Can you use TerseSize from the command line? perl -MO=TerseSize -e '1' Also 5.6.0 is *very* buggy, so upgrading to 5.6.1 is a very good idea. This is the config I added to httpd.conf to enable the feature. Location /perl-status SetHandler perl-script PerlModule Apache::Status PerlModule B::TerseSize PerlHandler Apache::Status PerlSetVar StatusOptionsAll On PerlSetVar StatusTerse On PerlSetVar StatusTerseSize On PerlSetVar StatusTerseSizeMainSummary On /Location __ 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: Memory usage option in Apache::Status
[EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Hope someone can give me a hand on this, I am having some problem using
the Memory Usage option in the main menu of Apache::Status.
It always return me a 500 with the following error.
[Tue May 14 08:48:21 2002] [error] Can't call method size on unblessed
reference at /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/Size.pm line
94.
yes, I have both installed.
ok, next trace to the offending code. Put in your startup.pl:
use Carp;
$SIG{__DIE__} = \Carp::confess;
hopefully nobody redefines $SIG{__DIE__}
Also 5.6.0 is *very* buggy, so upgrading to 5.6.1 is a very good idea.
Would love to, but it's a production machine, so .. I can't upgrade it
unless something major breaks. (^_^!)
This is a *major* reason for updating :)
__
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: Memory usage option in Apache::Status
[EMAIL PROTECTED] wrote:
ok, next trace to the offending code.
[Tue May 14 10:38:19 2002] [error] Can't call method size on unblessed
reference at /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/Size.pm line
94.
B::AV::size(1, 'B::AV=SCALAR(0xa063444)') called at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/B/TerseSize.pm line 438
I cannot reproduce the problem, but it seems that the problem is in
B/Size.pm:93my @vals = $sv-ARRAY;
which returns values which aren't references (at least one). You may
want to muck around this code and print what's inside @vals.
B::TerseSize::PADLIST_size('B::CV=SCALAR(0xa0674a0)',
'B::CV=SCALAR(0xa0674a0)', 'B::CV=SCALAR(0xa0674a0)',
'B::CV=SCALAR(0xa0674a0)') called at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/B/TerseSize.pm line 190
B::TerseSize::CV_walk('slow', 'B::NULL::size', 'op_size') called
at /usr/lib/perl5/site_perl/5.6.0/i386-linux/B/TerseSize.pm line 123
B::TerseSize::package_size('B::NULL') called at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/B/TerseSize.pm line 542
B::TerseSize::apache_package_size('B::HV', 'B::Terse',
'B::SPECIAL', 'B::NULL') called at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/B/TerseSize.pm line 563
B::TerseSize::status_memory_usage('Apache=SCALAR(0x9e4ae5c)',
'CGI=HASH(0x9e4aa8c)') called at
/usr/lib/perl5/site_perl/5.6.0/i386-linux/Apache/Status.pm line 66
Apache::Status::handler('Apache=SCALAR(0x9e4ae5c)') called at
/usr/lib/perl5/5.6.0/Carp.pm line 119
require 0 called at /usr/lib/perl5/5.6.0/Carp.pm line 119
I will see if I can borrow a testing machine tomorrow to try the
upgrade.
Please check if the problem does go away with 5.6.1. if not please
provide a short script/module that reproduces the problem (via
Apache::Status of course)
__
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
we need mod_perl banners
Nobody has volunteered to lead the modperl banners effort, so if you are an artist or know someone who is and willing to help please send the banners to me. The story: -- Some people want to advertise mod_perl on their sites. We need banners for that. Your help is appreciated. Approx Banner Spec: --- Format: PNG Dimensions: 468x60 and 150x40 (pixels) Size: about 10k. BTW, we still don't have a button derived from the winner logo! should be 88x31px or something like that. Ideas for banners: -- * world domination chapter 1 (only 20% achieved, see netcraft) * world domination chapter 2 (50% target) * include the 2.0 theme Try to re-use the new logo: --- http://wypug.digital-word.com/mod_perl/winner/ You can use Apache's feather: - http://apache.org/~stas/feather.gif http://apache.org/~stas/feather_transbg.gif And ORA's camel: http://perl.oreilly.com/usage/ and probably can cut images from http://wypug.digital-word.com/mod_perl/ Thanks. __ 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: we need mod_perl banners
Mark Fowler wrote: On Tue, 14 May 2002, Stas Bekman wrote: [ creating banners, etc ] Do we have the source for those banners anywhere? Preferably vector, or at least telling us what font the original was in. I don't think anyone wants to work from bitmap. I seem to remember matts doing something with SVG a while back, but him waiting on the correct font (my memory is a bit vague on this) Only the new mod_perl logo: http://wypug.digital-word.com/mod_perl/svg_version/ (the svg version will feature on the new site as well) __ 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: mod_perl2: nmake test crashes apache
Alessandro Forghieri wrote: about combinatorial I think not only compat2 is involved here in test suites I have ran Wow. this is great detective work you have done Pascal. Actually you didn't have to do the detective work. Apache::Test comes with a detective of its own. Just run t/SMOKE and it'll find all the combinations that fail. Though I cannot help you on WinFU :( Hopefully Randy or Doug will hear you. __ 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: Problems with mod_perl installation(HELP!!!)
[Please make sure to reply back to the list! Thanks] Jose Ortiz wrote: People : I had spent more than 2 months trying to make mode_perl on my RH 72. First I tried with the RPMS but it didn't works. Then I tryied with the tar.gz and I can't neither. very unlikely that it doesn't work, try following the steps as explained in the guide: perl.apache.org/guide/install.html make sure that you get the latest apache-1.3.24 and mod_perl_1.24 when reporting bugs/problems, please follow the instructions here: http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/help.html#How_to_Report_Problems __ 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: PerlVINC and Can't locate Foo.pm in @INC ...
Aaron J Mackey wrote: Banging my head against the wall a bit, 'cause this is just so simple, but still not working: Versions: Apache 1.3.22, mod_perl 1.26, perl 5.6.1 relevant lines from httpd.conf: PerlWarn On PerlModule Apache::PerlVINC Location /dat-ajm6q SetHandler perl-script PerlHandler DAT::Client::WWW PerlINC /home/ajm6q/cvs/dat-head/lib PerlFixupHandlerApache::PerlVINC PerlVersion DAT/Client/WWW.pm /Location Error log when access is attempted (other standard directories edited out for brevity): [Fri May 10 13:39:39 2002] [error] Can't locate DAT/Client/WWW.pm in @INC (@INC contains: /home/ajm6q/cvs/dat-head/lib [... edited out ...]) at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/PerlVINC.pm line 55. The file is, of course, actually there: % ls -l /home/ajm6q/cvs/dat-head/lib/DAT/Client/WWW.pm -rwxrwxr-x1 ajm6qwebwork 394 May 10 12:40 /home/ajm6q/cvs/dat-head/lib/DAT/Client/WWW.pm What am I missing? Does it normally work? (without Apache::PerlVINC) It's possible that you have wrong permissions on one of the segments of /home/ajm6q/cvs/dat-head/lib/DAT/Client/WWW.pm so it cannot read the final path. First test simply with: die $! unless -r /home/ajm6q/cvs/dat-head/lib/DAT/Client/WWW.pm __ 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: how to see /server-status when at MaxClients?
John E. Leon Guerrero wrote: if a job hangs (due to database locking for instance), then a mod_perl child will hang as well (absent some additional watchdog-type program.) if enough jobs hang to the point that we hit MaxClients, then it is too late to use /server-status to see what jobs hung. does anyone have a quick way to indentify the jobs that are currently running? i thought of getting a core and using gdb but i was hoping to find a faster way. it would be nice if we could reserve a couple of children for administrative emergencies such as this. You probably want: Apache::Watchdog::RunAway __ 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: [BUG?] PerlSetVar in .htaccess segfaults w/ register_cleanup()
D.Kreft wrote: ... I am greeted with Netcape's Document contains no data error dialog box, and a segfault notice in the error log: [Thu May 9 09:19:52 2002] [notice] child pid 25420 exit \ signal Segmentation fault (11) ... Does anyone have any ideas about what's going wrong here? Any help would be greatly appreciated! Probably not, without a back trace (from the Segfault) unless someone has had a similar problem and solved it before. See http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/help.html#How_to_Report_Problems on how to retrieve the backtrace. __ 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
mod_perl cookbook review at apacheweek.com
For those who still hesitate whether to purchase this great mod_perl recipes tome, here is Min Min Tsan's review of the mod_perl cookbook: http://www.apacheweek.com/features/book-mod_perlcookbook And lucky Robin Berjon and two other folks just won free copies of this book from apacheweek giveaway :) p.s. April 2002 Netcraft's mod_perl stats: 3.6M hosts 0.4M IPs. __ 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: mod_perl install from tarball
Boex,Matthew W. wrote: i am trying to install mod_perl and apache from tarball. after untarring, i created the makepl_args.mod_perl file in my home dir with my options. by the way, i am building this on a rh7.1 machine with mod_perl already installed. i am building this to learn. you are trying to install mod_perl 2.0-tobe, which works only with Apache 2.0, and most likely you want to download mod_perl 1.26 instead. my goal is to install from scratch so i can learn more and to install with the same directory structure, /usr/local/apache-mod_perl/ on my production and dev machines. i want to be able to run a mod_perl or non-mod_perl enabled web server. The detailed steps of how to do that are here: http://perl.apache.org/guide/install.html __ 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: [RFC] New Subject Tag for mod_perl 2.x postings
Thomas Klausner wrote: Hi! As there are more and more mod_perl 2.x related questions on the mailing list, it would be a good idea to introduce a new subject tag (as in http://perl.apache.org/email-etiquette.html#Tags ): Something like: [mod_perl 2.x] [mp2] [2x] [2.x] ?? What do you think? That's a good idea. Any tag that will make it clear that the question is regarding 2.x is fine. Eventually when 2.0 is released and after a while most people will run 2.x, only those ancient [:)] 1x will need to be tagged in the subject line. It would definitly keep my mailbox tidier... Stas, If we decide on something I could patch the new documentation to include this new tag, but I don't know abot the old (i.e. current) one go ahead, add any tags that you prefer. [2.x] or sounds the shortest and the clearest. __ 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: Scope of Perl Special Variables
Bill Catlan wrote:
Stas Bekman wrote:
This explains why by default %ENV is set for each request afresh.
http://perl.apache.org/guide/performance.html#PerlSetupEnv_Off
Great. Thank you Stas. Now I know /how/ that happens, but I don't know /why/
the existing inctances' ENV is not clobbered.
My guess is that a localized copy of the %ENV variable is created by the above
referenced process, thus no clobbering of existing instances' %ENV occurs.
Would that be correct?
Can you send a reproducable example of a problem? For example this code
does the right thing:
$r-send_http_header('text/plain');
print exists $ENV{FOO} ? $ENV{FOO}\n : NONE\n;
local $ENV{FOO} = BAR;
print exists $ENV{FOO} ? $ENV{FOO}\n : NONE\n;
it'll always print:
NONE
BAR
Make sure that you test under httpd -X mode so you won't get mislead.
__
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
localizing $dbh attributes with Apache::DBI to minimize the numberof connections made
Recently 5.8.0-tobe has fixed the leak with localization of tied hash
values, so I'm fixing the following guide's section as follows. This is
an important update, since the guide didn't say anything about $dbh attr
changes affecting other handlers in the same process. Please review that
everything is correct and I'll replace the old section with this one.
=head3 Opening Connections with Different Parameters
When CApache::DBI receives a connection request, before it decides
to use an existing cached connection it insists that the new
connection be opened in exactly the same way as the cached
connection. If you have one script that sets CAutoCommit and one
that does not, CApache::DBI will make two different connections. So
if for example you have limited Apache to 40 servers at most, instead
of having a maximum of 40 open connections you may end up with 80.
So these two connect() calls will create two different connections:
my $dbh = DBI-connect
(DBI:mysql:test:localhost, '', '',
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 1, # don't commit executes immediately
}
) or die Cannot connect to database: $DBI::errstr;
my $dbh = DBI-connect
(DBI:mysql:test:localhost, '', '',
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 0, # don't commit executes immediately
}
) or die Cannot connect to database: $DBI::errstr;
Notice that the only difference is in the value of CAutoCommit.
However, you are free to modify the handle immediately after you get
it from the cache. So always initiate connections using the same
parameters and set CAutoCommit (or whatever) afterwards. Let's
rewrite the second connect call to do the right thing (not to create
a new connection):
my $dbh = DBI-connect
(DBI:mysql:test:localhost, '', '',
{
PrintError = 1, # warn() on errors
RaiseError = 0, # don't die on error
AutoCommit = 1, # commit executes immediately
}
) or die Cannot connect to database: $DBI::errstr;
$dbh-{AutoCommit} = 0; # don't commit if not asked to
When you aren't sure whether you're doing the right thing, turn debug
mode on.
However, when the C$dbh attribute is altered after connect() it
affects all other handlers retrieving this database handle. Therefore
it's the best to restore the modified attributes to their original
value at the end of database handle usage. As of CApache::DBI
version 0.88 the caller has to do it manually. The simplest way to
handle this is to localize the attributes when modifying them:
my $dbh = DBI-connect(...) ...
{
local $dbh-{LongReadLen} = 40;
}
Here the CLongReadLen attribute overrides the value set in the
connect() call or its default value only within the enclosing block.
The problem with this approach is that prior to Perl version 5.8.0
this causes memory leaks. So the only clean alternative for older Perl
versions is to manually restore the Cdbh's values:
my @attrs = qw(LongReadLen PrintError);
my %orig = ();
my $dbh = DBI-connect(...) ...
# store the values away
$orig{$_} = $dbh-{$_} for @attrs;
# do local modifications
$dbh-{LongReadLen} = 40;
$dbh-{PrintError} = 1;
# do something with the filehandle
# ...
# now restore the values
$dbh-{$_} = $orig{$_} for @attrs;
Another thing to remember is that with some database servers it's
possible to access more than one database using the same database
connection. MySQL is one of those servers. It allows you to use a
fully qualified table specification notation. So if there is a
database Ifoo with a table Itest and database Ibar with its own
table Itest, you can always use:
SELECT from foo.test ...
or:
SELECT from bar.test ...
So no matter what database you have used in the database name string
in the connect() call (e.g.: CDBI:mysql:foo:localhost) you can still
access both tables by using a fully qualified syntax.
Alternatively you can switch databases with CUSE foo and CUSE bar,
but this approach seems less convenient, and therefore error-prone.
__
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: Scope of Perl Special Variables
Bill Catlan wrote:
Hello,
The online mod_perl guide
(http://thingy.kcilink.com/modperlguide/perl/The_Scope_of_the_Special_Perl_Va.ht
ml) states:
Special Perl variables like $| (buffering), $^T (script's start time), $^W
(warnings mode), $/ (input record separator), $\ (output record separator) and
many more are all true global variables; they do not belong to any particular
package (not even main::) and are universally available. This means that if you
change them, you change them anywhere across the entire program; furthermore you
cannot scope them with my().
My question pertains the CGI %ENV hash. First, I'm assumong that this is a
global variable in the sense of a Perl Special Variable, and not just a main::
or other package global. My question is how is it the case that the %ENV
variable script instance might be working with doesn't get clobbered or reset
by the next incoming request. Are some variables, like %ENV treated differently
by mod_perl?
Also, how can special variables be reliably initialized? For example, if one
request provides a certain attribute, such as HTTP_IDENT, but a subsequent
request does not, how do I know that the value of $ENV{HTTP_IDENT} on the second
request will indeed be undefined?
This explains why by default %ENV is set for each request afresh.
http://perl.apache.org/guide/performance.html#PerlSetupEnv_Off
__
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: Cheap and unique
David Jacobs wrote:
Good morning.
Ken is correct - I am not looking for random, I am looking for unique.
Unique and sequenced would be ideal, but it's tricky because if I use
$i++.$IP_address.$parameter.$PID
{$i is global, $IP_address is the server address, $parameter is a
parameter that was just passed in, $PID is the apache process ID.}
That's a decent solution, but it's not quite sequential because one
Apache process could handle far more many requests than another, and so
a later request could have a lower $i.
Are there any code examples out there that use mod_unique_id.c ? I am
new to mod_perl and couldn't quite get that. Looking at the code, it
looks like mod_unique_id does basically the same thing but with a shared
counter between the different servers.
Also what is the cheapest way to get a datestamp? (I'm assuming it's not
`date %Y%M%D%H%S`)
--
I'm sorry to be such a noob, but when I've got a little more mod_perl
under my belt I'll be answering questions up a storm!
It looks like you didn't see my replies to your post. Please read them
first.
http://marc.theaimsgroup.com/?l=apache-modperlm=102022922719057w=2
http://marc.theaimsgroup.com/?l=apache-modperlm=102023259920560w=2
__
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: Memory explodes loading CSV into hash
Ernest Lergon wrote: having a look at Apache::Status and playing around with your tips on http://www.apacheweek.com/features/mod_perl11 I found some interesting results and a compromising solution: Glad to hear that Apache::Status was of help to you. Ideally when such a situation happens, and you must load all the data into the memory, which is at short, your best bet is to rewrite the datastorage layer in XS/C, and use a tie interface to make it transparent to your perl code. So you will still use the hash but the refs to arrays will be actually C arrays. Another thing I found is, that Apache::Status seems not always report complete values. Therefore I recorded the sizes from top, too. Were you running a single process? If you aren't Apache::Status could have shown you a different process. Also you can use GTop, if you have libgtop on your system, which gives you a perl interface to the proc's memory usage. See the guide for many examples. Success: A reduction from 26 MB to 7 MB - what I estimated in my first mail. :) __ 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: PerlRun problem: can't find method uri?
Ricky wrote: Hi All, I am trying to porting mod_cgi script to mod_perl script because the mod_cgi script don't run correctly under mod_perl. When running under apache::registry, the script show wrong result. what do you mean, wrong results. Have you read http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/porting.html When running under apache::perlrun, the script sometimes crash. In error_log show : can't locate object method uri via package Apache::perlrun In mod_perl manual said that the script usually run in apache::perlrun widthout change but not in my script. And I can't add use strict because it will crash the script immediatelly. In error_log show : Variable %in is not imported at /home/httpd/html/scdf/scdf.plx line 174. Global symbol $sth requires explicit package name at /home/httpd/html/scdf/scdf.plx line 171. You better fix these errors, and keep 'use strict' in place. Then PerlRun should work without any problems in most cases. If after fixing those problems you still have problems, come back with your relevant questions again. It's a good idea to have your code running under 'use strict' no matter if you use mod_perl or not. This will save you a lot of grief in a long run. Our company planning to move from Perl/CGI to better/faster technology. Currently research about mod_perl. Is it a good decision try to move to mod_perl because the implementation time is slow. Is there any other tech that easier/more faster than mod_perl? How about PHP or JSP? It depends on your definition of easier. Easier==sloppier: better stay away from mod_perl. Easier==more flexible: go with mod_perl. As for the speed, I doubt you will find something *significantly* faster than mod_perl. Assuming that you learn how to get the most our of mod_perl. [p.s. please make sure you reply back to the list!] __ 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: Apache::DBI fails to compile?
F.Xavier Noria wrote: I installed Apache::DBI and make test run no test, but the make test of Apache::AuthCookieDBI tries to use Apache::DBI and fails because Apache/DBI.pm in line 202 invokes Apache-module(), which it seems it is not in the interface of the Apache class I have installed: $ perl -MApache::DBI -e1 Can't locate object method module via package Apache (perhaps you forgot to load Apache?) at /usr/local/share/perl/5.6.1/Apache/DBI.pm line 202. Compilation failed in require. BEGIN failed--compilation aborted. This is the version of Apache.pm I have installed: $ perl -MApache -le 'print $Apache::VERSION' 1.27 and mod_perl is 1.26, do you know what could wrong? That's normal. You cannot test modules that use mod_perl API without running them inside mod_perl server. I've the same problem as you've reported. This test suite is simple broken. If you talk to the Jacob Davies, please tell him that it's a good idea to set the prerequisites in Makefile.PL, so his module will be installable from CPAN, without doing any manual work. All Apache:: module authors should be moving to use the new Apache::Test framework soon, since it lets you test the code under running mod_perl server and works with both versions of httpd/mod_perl. __ 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: Apache 2.0 worker MPM
Patrick Mackinlay wrote: Hello, I am looking into using mod_perl with Apache 2 and the worker MPM, I was wondering what the status is of mod_perl for this setup. I noticed that in the docs it says it is in the alpha stage, is this due to perls ithreads not being quite ready? No, it's due to the fact that Apache 2.0 wasn't released yet (meaning that there are still API changes) and not everything has been implemented in mod_perl 2.0. If you want to see what works look at the test suite under t/ in the source distro. __ 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: [Fwd: Re: Cheap and unique]
Michael Robinton wrote: I'm just curious - what's wrong with the function you're already using? Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_) TIMESTAMP . $$ . $GLOBAL++ Do not use concat, but sprintf 0 padding. Here is an example that can happen easily which produces two identical ids in two different procs: P TIMESTAMP $$ $GLOB CONCAT SPRINTF A 1020227781 753 3 10202277817533 1020227781007533 B 1020227781 7533 10202277817533 10202277810007533 As you can see if you don't pad $$ with 0 to the max proc's len (on some machines 63999) you can get two identical UUIDs in CONCAT column above. The same can happen with the edge of timestamp when its first digit switches from 9 - 10, but then this number is so big, this is most likely won't be a problem. So a much safer solution would be : $uuid = time . sprintf(%05, $$) . $GLOBAL++; s/05/06/ or other if your system's process ID can be bigger than 5 digits. if you don't modify $^T and you don't reuse the timestamp set for you in $r, this will save you a few more millisecs: $uuid = $^T . sprintf(%05, $$) . $GLOBAL++; Since $^T . sprintf(%05, $$) is unique across processes. It's not possible to create two processes with the same $$, at the same time. $^T is the time the Perl interpreter has been started, unless it was modified later. You can also move all this work in the ChildCleanup Handler, so during the request time, you use a value that has been already precalculated for the current request at the end of the previous one. (just make sure to initialize it during the ChildInit Handler for the first request). p.s. this concept works on Unix for sure, it's possible that on some OSs it won't work. p.p.s. in mod_perl 2.0 we have APR::UUID that does this work for you. __ 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: [Fwd: Re: Cheap and unique]
In my post I've missed the 'd' token in %05d
Here are a few possible solutions that will do all the work for you
Apache/UUID.pm
--
package Apache::UUID;
use strict;
my($base, $seq);
die Cannot push handlers unless Apache-can('push_handlers');
init();
sub init {
Apache-push_handlers(
PerlChildInitHandler = sub {
$seq = 0;
$base = $^T . sprintf(%05d, $$);
1;
});
}
sub id { $base . $seq++; }
#sub format { ... }
1;
__END__
startup.pl
--
use Apache::UUID; # must be loaded at the startup!
test.pl
use Apache::UUID;
print Content-type: text/plain\n\n;
print Apache::UUID::id();
Since I've used $^T token, the module must be loaded at the startup, or
someone may modify $^T. If you use time(), you don't need the child init
handler (but you pay the overhead). and can simply have:
package Apache::UUID;
use strict;
my($base, $seq);
sub id {
$base ||= time . sprintf(%05d, $$);
$base . $seq++;
}
1;
the nice thing about the childinit handler is that at run time you just
need to $base . $seq++;. but probably this second version is just fine.
also you probably want to add a format() function so you get the ids of
the same width.
another improvement is to use pack(), which will handle sprintf for you
and will create a number which is more compact and always of the same width:
package Apache::UUID;
use strict;
my $seq;
sub id { unpack H*, pack Nnn, time, $$, $seq++;}
1;
Another problem that you may need to tackle is predictability... but
that's a different story.
__
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
