Re: speeding up CGI.pm
I like the idea of that, although the handsprings needed to do ordinary CGI, mp1 and mp2 might lead to a cloud of confusion. Best to keep them in separate modules and load them into CGI as needed. Is Apache::Request in mp2 ready for prime time? We haven't been able to get it running here (some sort of install problem, my people tell me). Lincoln On Tuesday 25 March 2003 03:25 am, Issac Goldstand wrote: That would be really amazing if it could still be implemented in mp1, too, as it would allow for interoperability between libapreq-based applications (like Apache::UploadMeter) and response handlers like CGI scripts which use CGI.pm I suppose that this isn't such a big problem in mp2 whose filters will probably make using one API for request handling unnecessary... Issac - Original Message - From: Stas Bekman [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 1:41 AM Subject: speeding up CGI.pm While we are at the CGI.pm issue, I was thinking that those who stick with CGI.pm because of its extended all-in-one functionality (request parsing/ HTML generation), but unhappy about request parsing speed, could benefit by integrating Apache::Request in CGI.pm to do the request parsing. So if Apache::Request is available CGI.pm could re-alias its args(), params(), etc. functions to call Apache::Request functions instead. What do you think? __ 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 -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: the deprecation of Apache-request in mp2
I suppose there might be name clashes, but I'll look into doing that. Lincoln On Monday 24 March 2003 07:08 pm, Stas Bekman wrote: Lincoln Stein wrote: How about making CGI.pm a subclass of $r? (optionally of course, by dynamically changing @ISA), so instead of returning $q it'll return $r, after re-blessing it. Sounds interesting. What would be the advantage of that? The advantage is that - you don't have to keep around two instances: $r and $q. - assuming that CGI.pm-specific code is not used one can transparently switch between Apache::Request and CGI.pm, by just changing: $r = Apache::Request-new($r); $r = CGI-new($r); And of course Apache::Request is a subclass of Apache ($r) and it works pretty well. In the future I can see someone extending Apache::Request to handle CGI.pm's HTML generation in C, so the two could be replace each other. __ 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 -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: CGI.pm and friends port to mp2
At least with some versions of perl, the require gets evaluated at compile
time and raises an exception even if it is enclosed by the eval {} braces.
The only way to get around this is to eval the string.
I'm not sure whether this is a current issue or was a problem with 5.00503,
but I've kept it in.
Lincoln
- why eval string:
eval require mod_perl;
shouldn't it be:
eval { require 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
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
Re: the deprecation of Apache-request in mp2
I can do this (changing the new() call to accept $r). My understanding is that client code will need to be changed to take advantage of this, right? The other issue is that it will only work with the OO form of CGI, which many people (including myself) don't use. I would prefer a more transparent way to obtain the current request. Is there no low-overhead way of getting at this? Lincoln On Thursday 13 March 2003 07:00 pm, Stas Bekman wrote: One more issue with CGI.pm and mp2, and other modules as well. CGI.pm is using Apache-request. The setting/retrieval of the global request record under threads is expensive, so the use of Apache-request is deprecated in mp2. If CGI.pm can be changed to optionally accept $r (as an argument to new(), plus a special accessor to set later) and use it instead, this will improve the performance if Apache-request is not set. Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by default with 'SetHandler perl-script') that is half of the performance hit (store), and the actual use of Apache-request (get) is the second half. See: http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_reque st_ http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ __ 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 -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: CGI.pm and friends port to mp2
Did I send out something weird? My version looks like this:
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{MOD_PERL}) {
eval require mod_perl;
if (defined $mod_perl::VERSION) {
if ($mod_perl::VERSION = 1.99) {
$MOD_PERL = 2;
require Apache::RequestRec;
require Apache::RequestUtil;
require APR::Pool;
} else {
$MOD_PERL = 1;
require Apache;
}
}
}
Lincoln
On Thursday 13 March 2003 06:21 pm, Stas Bekman wrote:
Lincoln Stein wrote:
Please find enclosed a beta version of CGI.pm 2.92. I would appreciate
it if people could test it on both mod_perl 1 and mod_perl 2, as well as
under normal CGI scripts too ;-)
Thanks Lincoln. 'make test' passes with mp1 and mp2, however the test
suites aren't exhaustively cover CGI.pm's functionality. So we really need
your help guys to give it a good test in the real apps.
In case anyone wonders why I fiddled with the check for the presence of
modperl, this is because some people write scripts that shell out to
command-line scripts that invoke CGI.pm in order to generate HTML (don't
ask me why). Without the additional checking, CGI.pm sees the MODPERL
environment variable, tries to load mod_perl outside the Apache
environment, and summarily crashes.
Ahm, I'm not quite sure that this does what you say it should:
if (exists $ENV{MOD_PERL}) {
require mod_perl;
if (defined $mod_perl::VERSION ($mod_perl::VERSION = 1.99)) {
# mp2
} else {
# mp1
}
}
because if it's not defined, it'll fall through to the else block, assuming
that the external script is running under mp1. Shouldn't it be:
if (exists $ENV{MOD_PERL}) {
require mod_perl;
# mod_perl handlers may run system() on scripts using CGI.pm
# - make sure so we don't get fooled by inherited $ENV{MOD_PERL}
if (defined $mod_perl::VERSION){ # for shell scripts
if ($mod_perl::VERSION = 1.99)) {
# mp2
} else {
# mp1
}
}
}
also it's probably a good idea to add a note, why this check is done, so
not to forget in the future and optimize it away ;)
I still haven't heard any response as to why I should move to MP2! I
wasn't just being cranky, I'm curious.
You want to move to MP2, if one of the following reasons apply:
- you are stuck with Apache2
- you want to use i/o filters
- you want to write your own protocol handlers
- you want to use a threaded mod_perl
- you are stuck with win32 (mp1 is unusable on win32, serialization)
and there is a whole bunch of new functionality available, which will be
too long to list here and partially described on the website.
__
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
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
Re: shim silence in Apache::MP3
Hi Sean, It sounds like a great idea, but it's not going to happen soon. My first priority is to get Apache::MP3 working with mod_perl 2.0 while maintaining compatibility with mod_perl 1.0.So much has changed between the two versions that I've basically given up on maintaining all my mod_perl scripts until I have a big chunk of free time (unlikely to happen soon, if ever). Lincoln On Monday 24 March 2003 08:05 am, Sean M. Burke wrote: Me and Chris Nandor and Joe Johnston were just nattering on about frilly little nicities would like (or have liked) in Apache::MP3. And I just thought of one, hooboy! Namely: maybe an option for inserting 2s of silence between tracks, or maybe just between tracks in different directories. What do you think? Somewhere around here I have some mp3s and oggs of absolute silence, of various runtimes, and even one with a runtime of 4 minutes 33 seconds, of course. -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: CGI.pm and friends port to mp2
Hi Stas, Thanks. I'll fold these changes and release on CPAN. I'll also remove the $|=1 setting, since that was globally needed for FastCGI compatibility, and I don't think that anyone uses it anymore. Lincoln On Monday 10 March 2003 08:43 pm, Stas Bekman wrote: Hi Lincoln, I'm not interested in modifying CGI.pm to use MP2 until I start using MP2 myself. This isn't likely in the near future, since I'm very happy indeed with MP1/Apache1. I've done the porting of CGI.pm, CGI::Carp and CGI::Pretty (no more Apache/compat.pm). I did some basic testing, however it'd be nice if people were to test this patch and confirm that I didn't break anything that did work before. So that Lincoln doesn't have to figure out how to test it. I've attached the diff against 2.91 distro. One more thing, Lincoln, why CGI.pm does: $| = 1; without localizing the change, when running under mod_perl? This has a potentially bad effect on the rest of the modules running under the same server, since now every print() will flush the data. Can this setting be localized (this will probably require to move the unbuffering where it's relevant, rather than globally)? 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 -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: [mp2] automatic Apache::compat preloading in CPAN modules is a no-no
Hi Stas,
I'm not interested in modifying CGI.pm to use MP2 until I start using MP2
myself. This isn't likely in the near future, since I'm very happy indeed
with MP1/Apache1.
Lincoln
On Friday 07 March 2003 03:58 am, Stas Bekman wrote:
Stas Bekman wrote:
Apache::compat is useful during the mp1 code porting. Though remember
that it's implemented in pure Perl. In certain cases it overrides mp2
methods, because their API is very different and doesn't map 1:1 to mp1.
So if anything, not under my control, loads Apache::compat my code is
forced to use the potentially slower method. Which is quite bad.
Some users may choose to keep using Apache::compat in production and it
may perform just fine. Other users will choose not to use that module.
It should be users' choice.
Therefore CPAN modules should *not* preload Apache::compat, but use the
mp2 API or copy the relevant parts from Apache::compat.
Of course one can add an ugly workaround in startup.pl:
$INC{'Apache/compat.pm'} = __FILE__;
but I'd rather not have to remember doing that. I'll update the manpage
to have this warning.
I haven't scanned the CPAN modules yet, but I've noticed that CGI.pm's
latest version does:
require mod_perl;
if ($mod_perl::VERSION = 1.99) {
eval require Apache::compat;
} else {
eval require Apache;
}
Lincoln, any chance we can kill that preloading? If you need help with
porting the API please let us know.
Here is a hopefully useful discussion and examples on how to get rid of
Apache::compat:
http://perl.apache.org/docs/2.0/devel/porting/porting.html#Handling_Missing
_and_Modified_mod_perl_1_0_APIs
__
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
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
Re: Does Apache::NavBar exist ?
That's right. CPAN is telling you to contact Doug and Me. Lincoln Does it exist ? Weird, it doesn't show up on search.cpan.org, but it seems to be on CPAN still: http://www.cpan.org/authors/id/B/BA/BARRACODE/ Otherwise you can find a copy here: http://modperl.com:9000/book/source/apachemod-code-1.02/lib/Apache/ Really strange. CPAN.pm finds it: cpan m Apache::NavBar Module id = Apache::NavBar DESCRIPTION Navigation bar generator CPAN_USERID MPB (mod_perl book (Doug and Lincoln) [EMAIL PROTECTED]) CPAN_VERSION undef CPAN_FILEContact Author mod_perl book (Doug and Lincoln) [EMAIL PROTECTED] DSLI_STATUS bdpO (beta,developer,perl,object-oriented) INST_FILE(not installed) But it doesn't know there is a copy on CPAN. I guess BarracodE (Charles Day) is not registered as owner. I've Cc'ed the people involved. Lincoln, Doug, is this cleared with you? Andreas, if/when it is, can you transfer the module? HTH, Lupe Christoph
Re: possible buget in CGI.pm
I'm aware of the problem, but I haven't been able to track it down. Any help is welcome. Lincoln On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote: Hi All, We are implementing mod_perl here for internal intranet use. We have discovered a possible buglet in CGI.pm. We do not want CGI.pm to return XHTML as it upsets Verity indexing (long story). So in Apache::Registry executed scripts we use: use CGI qw( -no_xhtml ); But on the first invocation it returns normal HTML. On second invocation it ignores this directive and returns XHTML. We started a dev server with -X to confirm this. It would appear CGI resets its globals somewhere. Can someone confirm this? Also is this the right forum for this ? Which bit of the plot have I missed? Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 Thanks, Greg Cope This message and any attachment has been virus checked by Pfizer Corporate Information Technology, Sandwich.
Re: inconsistency between CGI.pm and Apache::Request
I'm amazed that CGI.pm does this, but you're right. What's bad is
that this style doesn't work as expected:
p $r-param(foo=[qw(a b c)])
Lincoln
Tatsuhiko Miyagawa writes:
On Thu, 1 Nov 2001 09:58:39 -
Matt Sergeant [EMAIL PROTECTED] wrote:
I guess so. Your above is equivalent to:
$r-param(foo = 'a', b = 'c');
(foo = qw(a b c)) doesn't do what it looks like it does, and that's a bad
thing.
I know! but CGI.pm does it, so what I want is interface
consistency. CGI.pm also has a named parameter style which
Apache::Request doesn't support, like
$q-param(-name = 'foo', -value = [ qw(a b c) ]);
print join '/', $q-param('foo'); # a/b/c
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS.
PLEASE WRITE FOR DETAILS.
RE: inconsistency between CGI.pm and Apache::Request
No, it certainly isn't clean. Neither is Perl's API!
Lincoln
Matt Sergeant writes:
-Original Message-
From: Tatsuhiko Miyagawa [mailto:[EMAIL PROTECTED]]
On Thu, 1 Nov 2001 09:58:39 -
Matt Sergeant [EMAIL PROTECTED] wrote:
I guess so. Your above is equivalent to:
$r-param(foo = 'a', b = 'c');
(foo = qw(a b c)) doesn't do what it looks like it does,
and that's a bad
thing.
I know! but CGI.pm does it, so what I want is interface
consistency. CGI.pm also has a named parameter style which
Apache::Request doesn't support, like
$q-param(-name = 'foo', -value = [ qw(a b c) ]);
print join '/', $q-param('foo'); # a/b/c
Well, as a libapreq developer, I'd say -1 to the above. I'm not that worried
about consistency - it's not like they advertise as being the same (the
wording in the README is lighter and faster alternative). For me the
CGI.pm API isn't clean (sorry Lincoln :-)
Matt.
_
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS.
PLEASE WRITE FOR DETAILS.
Re: readdir()
Thanks everyone. I'll try backgrading to glibc 2.1. Does anyone know if the problem is still present in Perl 5.6.1? Lincoln Andrew Ho writes: Hello, LSPerl 5.6.0 breaks the readdir() function when running under mod_perl. LSThis is with the most recent versions of Apache and mod_perl, as well LSas with older versions. I see the same problem reported in the LSmailing list going back to December 2000, but no hint of a LSresolution. Is there any fix? Are there references to the problem reports? readdir() works fine for me with Apache 1.3.19, mod_perl 1.25, and Perl 5.6.0 on Solaris 2.7 (x86). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 -- -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS.
readdir()
Hi Doug, Perl 5.6.0 breaks the readdir() function when running under mod_perl. This is with the most recent versions of Apache and mod_perl, as well as with older versions. I see the same problem reported in the mailing list going back to December 2000, but no hint of a resolution. Is there any fix? Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS.
Anticipated www.modperl.com outage
Just thought you folks might want to know that www.modperl.com will probably be unreachable for a day or two. NorthPoint communications has gone bankrupt, bringing my DSL connection down with it. I'm moving the server to another location for the interim, but it might take a day or two for the DNS changes to take effect. Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS.
modperl back up
Hi All, As of last Friday, www.modperl.com is back up. The Apache::MP3 demo no longer works, unfortunately, because the thieves stole the hard disk that all the MP3s were on. I'm hoping to get it working again this week. Thank you for the several offers of help that I received. Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS.
www.modperl.com
I regret to say that www.modperl.com is down again. This time it is because someone broke into my house and stole some computer equipment, including the DSL router. Fortunately the modperl web server itself was untouched because it was hidden in the eves. I will make an announcement when the system is back up. Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Updates to www.modperl.com site
Hi, I am very gradually making changes to the modperl book site. My plan over the next few weeks is to bring more of the examples online. Suggestions for priorities are very much appreciated. As of this morning, I have added an online demo of my Apache::MP3 module, which does nice directory listings of MP3 files and allows you to select and stream them. I also cleaned up the look of the page a bit, but it is still a bit primitive. Lincoln
www.modperl.com
Hi, This site, which contains the examples for the "Programming Apache Modules in Perl and C" book, will be going down for a couple of days while I move it to a new ISP. When it comes back up I would like to add a few more online examples to the site and spruce it up a bit in general. Any votes on which examples you'd like to see put online? Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
