Re: MP1 - libapreq1.2 broke apache / mod_perl installation
The latest version of ExtUtils::MakeMaker tickles a bug in libapreq's c/Makefile.PL. There has been quite a bit of discussion of this issue in the last week on apreq-dev, p5p, and on this list as well. aha! I'd noticed some threads about compiling libapreq - should have read them in detail. I always assume when i encounter a problem that it is my mistake/bug rather than the module's. Now and then it turns out it is the module. I should also get out of the habit of upgrading modules without discrimination... if i'd known of the conflict I'd have left MakeMaker unchanged as libapreq is of more use to me Michael Schwern [hope I spelled it right :] posted two patches to the apreq-dev list designed to fix these problems. As soon as enough folks decide which of his patches is best, we'll roll a 1.3 release that fixes the problem. I guess I'll just sit tight and wait, then. My mod_perl knowledge is not good enough to help here - and besides I am in a fight of my own with Apache::Session::Postgresql :( -- Iphigenie, [EMAIL PROTECTED] on 04/08/2003
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern wrote:
The problem is likely the MY::dynamic hack in c/Makefile.PL. 6.05 and
previous had this:
dynamic :: Makefile $(INST_DYNAMIC) $(INST_BOOT)
6.06_01 and up have this
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
for some reason, MY::dynamic is trying to lop off everything after Makefile
and moving $(INST_DYNAMIC) to a different target in MY::top_targets.
(Where INST_BOOT is run from, I dunno). But dynamic no longer matches
/Makefile/ so the hack fails and you wind up with INST_DYNAMIC built from
two places.
Coupled with the fact that its set LINKTYPE 'static' with a comment
problems with things finding libareq.so, sort out later leads me to
believe this was a work around a MakeMaker bug.
Chaning s/(Makefile\s+).*/$1/g to
s{ \$\(INST_DYNAMIC\) }{}g;
s{ \$\(INST_BOOT\) }{}g;
should fix the symptoms by restoring the hack for a quick fix.
I tried changing the s/// to:
$string =~ s{ \$\(INST_DYNAMIC\)}{}g;
$string =~ s{ \$\(INST_BOOT\)}{}g;
(I've dropped the trailing spaces in the patterns), which produced:
dynamic :: $(FIRST_MAKEFILE)
$(NOECHO) $(NOOP)
in the Makefile as desired, but now the build process fails with this error:
fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
For a longer term solution, try removing the MY::dynamic and
MY::top_targets overrides entirely, plus changing LINKTYPE to 'dynamic' and
see what happens.
I tried removing MY::dynamic and MY::top_targets, plus *adding* LINKTYPE
'dynamic' to the Win32-specific section. That seems to get me back to
square one - the Makefile contains:
dynamic :: $(FIRST_MAKEFILE) $(INST_DYNAMIC) $(INST_BOOT)
$(NOECHO) $(NOOP)
and the build fails as it originally did with:
libapreq.def : error LNK2001: unresolved external symbol boot_libapreq
Only the fix previously posted by Stas (adding 'SKIP' = [qw(dynamic
dynamic_lib dynamic_bs)], to both WriteMakefile() calls) works for me so
far, but Joe had a problem that...
Steve
handlers versus scripts, SSI difference
I began some weeks ago to think about translating my .pl scripts (that run with mod_perl 2 ::registry) to perl handlers. My first problem was to find how to include a perl handler as i included my cgi scripts (include virtual). I found that #perl directive allows you to include with Apache::include the same registry scripts, but making it faster. I also note that in fact you could include any perl handler with that #perl directive. But it seems to be that with modperl as DSO this directive does not work, and that Apache::include is only a modperl1.x funcionality, so discarted in mod perl 2. I have had problems building modperl as a static module. Finally i could build as static module and as DSO module (mod_perl.a and mod_perl.so) but i didn't have modperl enabled without loadmodule mod_perl.so, so static version is not running. Windows binaries are all DSO, and i don't have VB to compile. And i've read that compiling mod_perl statically doesn't allow you to compile other DSO modules after. Then i think, if DSO is the comfortable way to do things (not in practical but in concept), how can i include a perl handler in my HTML page? I know there are modules like MASON or similar, and now i will enter to input and output filters, but comparing with the easiest way of Include virtual registry scripts i begin to think that perl handlers in mod perl lose here against cgi simple scripts. So this is my question. Are perlhandlers better than CGI registry scripts in speed but not in funcionality??? as i think CGI people uses to include their scripts a lot!! - Un nuevo buscador más rápido, eficaz y sencillo http://www.plaf.com Ya.com ADSL Home 24h, Módem + Alta + 1 mes Gratis http://acceso.ya.com/adslhome24h/
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 08:46:27AM +0100, Steve Hay wrote:
I tried changing the s/// to:
$string =~ s{ \$\(INST_DYNAMIC\)}{}g;
$string =~ s{ \$\(INST_BOOT\)}{}g;
(I've dropped the trailing spaces in the patterns), which produced:
dynamic :: $(FIRST_MAKEFILE)
$(NOECHO) $(NOOP)
in the Makefile as desired, but now the build process fails with this error:
fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
That's odd. Does that file exist? If not, where is your typemap file?
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
I'm exploring my nipples.
Re: Current directory
One way is to configure the CPAN module: C:\ perl -MCPAN -e shell which, the first time you invoke it, will lead you through a dialogue. You can accept most of the defaults, except for the list of CPAN mirrors to use. Then, at the CPAN.pm shell prompt, you can say cpan install CGI Thanks for answering Randy, but I got a working PPM module of CGI for HP-UX and modified the module's description files to make PPM think it's for Win32. Since it's just Perl code, and not XS, should work. If anyone wants this PPM, I can make it available. Though it would be more useful on a known repository. But I still get the same message... [Mon Aug 04 09:31:57 2003] [error] Global $r object is not available. Set: PerlOptions +GlobalRequest in httpd.conf at D:/Perl/lib/CGI.pm line 307. Compilation failed in require at D:/htdocs/_startup.pl line 33. Is there anything else I can check other than the CGI.pm version?
Re: Current directory
BTW, perl -MCGI -e print $CGI::VERSION; 2.98 J-S - Original Message - From: Jean-Sebastien Guay [EMAIL PROTECTED] To: Randy Kobes [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, August 04, 2003 9:32 AM Subject: Re: Current directory One way is to configure the CPAN module: C:\ perl -MCPAN -e shell which, the first time you invoke it, will lead you through a dialogue. You can accept most of the defaults, except for the list of CPAN mirrors to use. Then, at the CPAN.pm shell prompt, you can say cpan install CGI Thanks for answering Randy, but I got a working PPM module of CGI for HP-UX and modified the module's description files to make PPM think it's for Win32. Since it's just Perl code, and not XS, should work. If anyone wants this PPM, I can make it available. Though it would be more useful on a known repository. But I still get the same message... [Mon Aug 04 09:31:57 2003] [error] Global $r object is not available. Set: PerlOptions +GlobalRequest in httpd.conf at D:/Perl/lib/CGI.pm line 307. Compilation failed in require at D:/htdocs/_startup.pl line 33. Is there anything else I can check other than the CGI.pm version?
Re: handlers versus scripts, SSI difference
But it seems to be that with modperl as DSO this directive does not work, and that Apache::include is only a modperl1.x funcionality, so discarted in mod perl 2. I've started this port, but it's a long way from being completed - it doesn't work right and dumps core, but I haven't looked at it in quite a while. oh, and it's really ugly too. in other words, very much a work in progress. here it is if you want to help - I'll probably get back to it in a few weeks. http://www.modperlcookbook.org/~geoff/modules/experimental/Apache-SSI-2.0.tar.gz --Geoff
Re: handlers versus scripts, SSI difference
On Mon, 2003-08-04 at 04:05, gerard uolaquetalestem wrote: But it seems to be that with modperl as DSO this directive does not work, and that Apache::include is only a modperl1.x funcionality, so discarted in mod perl 2. I don't think this has anything to do with DSO vs. static. Apache::Include and Apache::SSI are the two ways of doing includes of mod_perl scripts in mod_perl 1.x and they have not been ported to mod_perl 2 yet. If you are using apache 2, you should look at using the apache 2 version of mod_include, which can be used as a filter. Take a look at the documentation here: http://httpd.apache.org/docs-2.0/mod/mod_include.html So this is my question. Are perlhandlers better than CGI registry scripts in speed but not in funcionality??? Perl handlers have better speed and functionality than CGI scripts running under Registry, but that has nothing to do with SSI. - Perrin
Re: Skipped Tests (was: handler help)
On Fri, 2003-08-01 at 22:53, Tofu Optimist wrote: Then as root I used CPAN to install Bundle::WWW, LWP, and HTML::Parser. Had some troubles, used the force option, and plowed ahead. (Maybe I should have stopped here at the first FYI, this was probably also because of the locale issue. Best to make it a global change so you won't have to set it every time you want to run (or install) perl stuff. - Perrin
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern wrote:
On Mon, Aug 04, 2003 at 08:46:27AM +0100, Steve Hay wrote:
I tried changing the s/// to:
$string =~ s{ \$\(INST_DYNAMIC\)}{}g;
$string =~ s{ \$\(INST_BOOT\)}{}g;
(I've dropped the trailing spaces in the patterns), which produced:
dynamic :: $(FIRST_MAKEFILE)
$(NOECHO) $(NOOP)
in the Makefile as desired, but now the build process fails with this error:
fatal error U1073: don't know how to make 'C:\perl5\lib\ExtUtils\typemap'
That's odd. Does that file exist? If not, where is your typemap file?
Somehow, it has contrived to disappear! It always used to exist there,
which is why it didn't occur to me to check :-( I must have lost it
somewhere along the line when shoe-horning earlier MakeMaker's into place.
Having now restored that file, the patch above does indeed fix it for me.
Steve
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 09:35:55AM +0100, Steve Hay wrote: Somehow, it has contrived to disappear! It always used to exist there, which is why it didn't occur to me to check :-( I must have lost it somewhere along the line when shoe-horning earlier MakeMaker's into place. Possibly you deleted the ExtUtils/ directory? Having now restored that file, the patch above does indeed fix it for me. Yay! -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ I need a SHOWER a BURGER and some ROBOTS, STAT! -- http://www.angryflower.com/allrigh.gif
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern wrote: On Mon, Aug 04, 2003 at 09:35:55AM +0100, Steve Hay wrote: Somehow, it has contrived to disappear! It always used to exist there, which is why it didn't occur to me to check :-( I must have lost it somewhere along the line when shoe-horning earlier MakeMaker's into place. Possibly you deleted the ExtUtils/ directory? Yes, I think I did delete it when installing MM 6.06_01 because its own Makefile was broken so I couldn't run nmake install. I see that Perl's lib/ExtUtils directory contains a typemap and ExtUtils-MakeMaker's lib/ExtUtils directory doesn't. So that would explain it. Why isn't the typemap file distributed as part of ExtUtils-MakeMaker?
Re: need your help to test mod_perl with perl-5.8.1-RC3
On Mon, Aug 04, 2003 at 11:19:42AM +0100, Steve Hay wrote: Why isn't the typemap file distributed as part of ExtUtils-MakeMaker? typemap is very specific to the version of Perl, or so it is said. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ You're more radiant than a memory of breathtaking ecstasy.
Re: Current directory
On Mon, 2003-08-04 at 09:32, Jean-Sebastien Guay wrote: But I still get the same message... [Mon Aug 04 09:31:57 2003] [error] Global $r object is not available. Set: PerlOptions +GlobalRequest in httpd.conf at D:/Perl/lib/CGI.pm line 307. Compilation failed in require at D:/htdocs/_startup.pl line 33. Is there anything else I can check other than the CGI.pm version? First, check your conf file to be sure you have this turned on. There are docs related to it here: http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ You can test it by writing a little handler (or Registry script) that calls Apache-request(). That should return an Apache::RequestRec object if all is well. If it doesn't, you may have an old mod_perl 2 build or you may have found a bug. If you can't get that to work, there is also the direct approach which is to pass a RequestRec object to CGI.pm when you call the new() method. Registry scripts get a RequestRec object passed to them as their first param, so you can just shift it into a variable (usually called $r) and pass it as CGI-new($r). - Perrin
Re: Current directory
Perrin, First, check your conf file to be sure you have this turned on. There are docs related to it here: http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ The docs also state that unless it's explicitly turned _off_, it's on by default. But I turned it on anyways before I sent my last message. Here's the relevant section of my httpd.conf: begin LoadModule perl_module modules/mod_perl.soLoadFile "D:/Perl/bin/perl58.dll" PerlModule Apache2PerlSetEnv SCRIPT_ROOT "D:/htdocs"PerlRequire "D:/htdocs/_startup.pl" Files ~ "\.cgi$" SetHandler perl-script PerlResponseHandler ModPerl::Registry Options +ExecCGI PerlOptions +ParseHeaders +GlobalRequest /Files end And here's my _startup.pl script: begin #---# Default module inclusions as per the Apache# mod_perl installation instructionsuse Apache2 ();use ModPerl::Util ();use Apache::RequestRec ();use Apache::RequestIO ();use Apache::RequestUtil ();use Apache::Server ();use Apache::ServerUtil ();use Apache::Connection ();use Apache::Log ();use Apache::Const -compile = ':common';use APR::Const -compile = ':common';use APR::Table ();use Apache::compat ();use ModPerl::Registry ();use CGI (); #---# General modulesuse Time::localtime;use Data::Dumper;use Date::Calc qw(:all); #---# Hybride modules # Add the top-level directory for the modules into the module search path.use lib qw(D:/htdocs); # ... ... The modules I want to pre-load are currently all commented out, until # ... ... I get a running server to test them one at a time... end You can test it by writing a little handler (or Registry script) that calls Apache-request(). That should return an Apache::RequestRec object if all is well. If it doesn't, you may have an old mod_perl 2 build or you may have found a bug. If you can't get that to work, there is also the direct approach which is to pass a RequestRec object to CGI.pm when you call the new() method. Registry scripts get a RequestRec object passed to them as their first param, so you can just shift it into a variable (usually called $r) and pass it as CGI-new($r). Doesn't all this require that I actually get a running Apache server first? The error message shows up when I try to start up the Apache service! As I understand it, the _startup.pl script tries to require() CGI.pm, which gives the error message. So I never get a running Apache instance to run any scripts in. If there's anything else I can try, or if you see anything in the above config files, please let me know. Thanks for your patience on this... J-S ___Jean-Sébastien Guay [EMAIL PROTECTED]Software Developer, Hybride http://www.hybride.comPiedmont, Québec, Canada
Re: Current directory
On Mon, 2003-08-04 at 12:08, Jean-Sebastien Guay wrote: Doesn't all this require that I actually get a running Apache server first? The error message shows up when I try to start up the Apache service! What? That shouldn't happen unless something is calling CGI-new in your startup, which is a bad thing to do. Maybe some script you're loading is doing that. Try to figure out what's doing it. As I understand it, the _startup.pl script tries to require() CGI.pm, which gives the error message. What happens if you comment out CGI.pm from your startup.pl? - Perrin
Re: Current directory
On Mon, 2003-08-04 at 12:08, Jean-Sebastien Guay wrote: Doesn't all this require that I actually get a running Apache server first? The error message shows up when I try to start up the Apache service! What? That shouldn't happen unless something is calling CGI-new in your startup, which is a bad thing to do. Maybe some script you're loading is doing that. Try to figure out what's doing it. You're absolutely right... Shame on me. The first homegrown module I was importing did exactly that. It would try to get the user cookie right on use(), which of course isn't very good practice. So I've modified it to get it on first call of a certain method, and to return that same value on subsequent calls. Geez... Now I have to transition all my scripts and other modules to mod_perl. Where could I find examples of real-life conversion between normal CGI and mod_perl? (Other than the perl.apache.org docs, which even though they're great, lack real examples of what needs to be done for the really ugly types of code...) Thanks for bearing with me through this... J-S ___ Jean-Sébastien Guay [EMAIL PROTECTED] Software Developer, Hybride http://www.hybride.com Piedmont, Québec, Canada
Re: rflush() not working as documented?
Just checking that this did not get lost on the way. Anyone care to
give me a hint?
On Thu, Jul 31, 2003 at 10:17:06PM +0200, Martin Wickman wrote:
Hello
According to docs[1], $r-rflush() should create a new brigade with
data. It does not.
It seems the docs and/or my understanding of this is in error.
This is with:
Apache/2.0.47 (Debian GNU/Linux) mod_perl/1.99_07-dev Perl/v5.8.0
And I am using the streaming filter api.
[1]
http://perl.apache.org/docs/2.0/user/handlers/filters.html#Multiple_Invocations_of_Filter_Handlers
Long version below:
--
I have tried to make my outputfilter clever enough so it can handle
being called several times, with tags potentially split between
several brigades.
Now I would like to test this somehow (ie, force mod_perl to call my
filter several times). I tried using $r-rflush(), but cannot get it
to work as I and the docs would expect.
I tried creating a ResponseHandler which explicitly breaks some silly
html data into brigades:
sub handler {
my $r = shift;
$r-content_type('text/html');
$r-log_error (Cutting);
$r-print (htmlhead title /head); $r-rflush();
$r-print (bo);$r-rflush();
$r-print (dy body ); $r-rflush();
$r-print (/html);
$r-log_error (Cutting: end);
return Apache::OK;
}
And then a simple 'DebugFilter' output filter which just prints each chunk:
sub handler : FilterRequestHandler {
my $f = shift;
$f-r-log_error (DebugFilter called);
$f-print (DebugFilter called\n);
while ($f-read(my $buffer, 1024)) {
$f-print(CHUNK:$buffer:CHUNK\n);
}
return Apache::OK;
}
And httpd.conf
Location /test/
PerlResponseHandler MyApache::Cutter
PerlOutputFilterHandler MyApache::DebugFilter
/Location
When I run this, I see that DebugFilter gets called 4 times (3
rflush's + 1 eos or something). But the strange thing is that only the
_last_ call contains data. That data is _everything_ nicely
concatenated and not splitted as I would guess.
Here is actual output:
$ wget --quiet -O - http://localhost/test/
DebugFilter called
DebugFilter called
DebugFilter called
DebugFilter called
CHUNK:htmlhead title /headbody body /html:CHUNK
And the error_log:
[Thu Jul 31 21:52:42 2003] [error] Cutting: start
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
[Thu Jul 31 21:52:42 2003] [error] Cutting: end
[Thu Jul 31 21:52:42 2003] [error] DebugFilter called
Apache-AuthPerLDAP beta port uploaded
Hi! I just wanted to see of Henrik Strom was on this list (I have ported your Apache-AuthPerLDAP, and wonder how you want to integrate the changes into your existing module.) Also, I have ported Apache-AuthPerLDAP to work with both versions of mod_perl, but am running out of time to set up the test environment. If some of you could test the new module, and send documentation of any problems with either mod_perl 1 or 2 to me, that would be greatly appreciated :) I have uploaded the ported module to CPAN, and you should be able to find it at: http://search.cpan.org/author/SPEEVES/ later today. Thanks for your help!!! speeves cws The uploaded file Apache-AuthPerLDAP-2.01.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SP/SPEEVES/Apache-AuthPerLDAP-2.01.tar.gz size: 4442 bytes md5: 1be5678c357fc98723e60374b47932c1
mod perl issues/ cpan won't make properly
Title: mod perl issues/ cpan won't make properly I'm having a lot of problems with installing mod_perl/apache/ properly. Also installing through CPAN is an issue with certian modules as well. Suse 8.0/ linux 2.4/perl5.8.0/mod_perl1.28Apache1.3.28/ Here's how I installed mod_perl/apache: cd apache_1.3.28 ./configure --enable-module=so cd mod_perl_1.28 perl Makefile.PL APACHE_SRC= /dloads/apache_mod_perl/apache_1.3.28/src DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 APACHE_PREFIX=/usr/local/httpd_perl make make test make install After mod_perl is installed with Apache, I went to start the apachetl. It won't start saying that it is missing some modules. Why won't it start after the installation? I tried to install the apache bundle to see if that would help. So using Cpan I tried to install the Bundle::Apache...which bombs out saying : Why won't CPAN install this bundle ...tail Running make test make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/c' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/c' make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/Request' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/Request' make[1]: Entering directory `/root/.cpan/build/libapreq-1.2/Cookie' make[1]: Leaving directory `/root/.cpan/build/libapreq-1.2/Cookie' PERL_DL_NONLAZY=1 /usr/local/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/*t/*.t does not exist FAILED--1 test script could be run, alas--no output ever seen make: *** [test_dynamic] Error 2 /usr/bin/make test -- NOT OK Running make install make test had returned bad status, won't install without force ALSO here is perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.18-64gb-smp, archname=i686-linux uname='linux lamp 2.4.18-64gb-smp #1 smp wed mar 27 13:58:12 utc 2002 i686 unknown ' config_args='-Accflags=-DPERL_Y2KWARN -DPERL_POLLUTE_MALLOC -Dmksymlinks' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-DPERL_Y2KWARN -DPERL_POLLUTE_MALLOC -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O3', cppflags='-DPERL_Y2KWARN -DPERL_POLLUTE_MALLOC -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='2.95.3 20010315 (SuSE)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil libc=, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Aug 2 2003 13:09:23 @INC: /usr/local/lib/perl5/5.8.0/i686-linux /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .
Re: rflush() not working as documented?
Martin Wickman wrote: Just checking that this did not get lost on the way. Anyone care to give me a hint? On Thu, Jul 31, 2003 at 10:17:06PM +0200, Martin Wickman wrote: Hello According to docs[1], $r-rflush() should create a new brigade with data. It does not. I've seen this also, but was never able to isolate a cause. It seems the docs and/or my understanding of this is in error. This is with: Apache/2.0.47 (Debian GNU/Linux) mod_perl/1.99_07-dev Perl/v5.8.0 And I am using the streaming filter api. [1] http://perl.apache.org/docs/2.0/user/handlers/filters.html#Multiple_Invocations_of_Filter_Handlers Long version below: -- I have tried to make my outputfilter clever enough so it can handle being called several times, with tags potentially split between several brigades. see the code and tests from http://www.modperlcookbook.org/~geoff/perl.com/Apache-Clean-2.0.tar.gz which should give you more ideas about how to code this (and how I tested long input values) the corresponding articles might help: http://www.perl.com/pub/a/2003/04/17/filters.html http://www.perl.com/pub/a/2003/05/22/testing.html I've been meaning to chat with stas about the rflush for a while now. perhaps we can prioritize it :) --Geoff
Re: need your help to test mod_perl with perl-5.8.1-RC3
Michael G Schwern [EMAIL PROTECTED] writes: On Mon, Aug 04, 2003 at 11:19:42AM +0100, Steve Hay wrote: Why isn't the typemap file distributed as part of ExtUtils-MakeMaker? typemap is very specific to the version of Perl, or so it is said. Not really. There are some changes for PerlIO * vs FILE * but other than that I am unaware of anything significant in years. (But then so long as it works I don't look)... Okay here are changes that have touched typemap in the mainline: Change 17989 on 2002/10/10 by [EMAIL PROTECTED] 'Subject: PATCH: lib/ExtUtils/ty' Change 15534 on 2002/03/26 by [EMAIL PROTECTED] 'Subject: Re: [PATCH] STRLEN typ' Change 11621 on 2001/08/09 by [EMAIL PROTECTED] 'Subject: [PATCH] remove PL_na f' Change 9737 on 2001/04/18 by [EMAIL PROTECTED] 'Subject: [PATCH] XS::Typemap - ' Change 9553 on 2001/04/05 by [EMAIL PROTECTED] 'Integrate changes #9544,9547,95' Change 9437 on 2001/03/29 by [EMAIL PROTECTED] 'Subject: [PATCH [EMAIL PROTECTED] type' Change 9380 on 2001/03/27 by [EMAIL PROTECTED] 'Subject: [PATCH] Typemap testin' Change 8934 on 2001/02/25 by [EMAIL PROTECTED] 'Integrate perlio: [ 8927] Cha' Change 8359 on 2001/01/08 by [EMAIL PROTECTED] 'Integrate perlio: [ 8356] FIL' Change 8308 on 2001/01/04 by [EMAIL PROTECTED] 'Subject: [patch] typemap =~ s/c' Change 6918 on 2000/08/30 by [EMAIL PROTECTED] 'NVs not necessarily doubles, as' Change 6915 on 2000/08/30 by [EMAIL PROTECTED] 'Subject: [PATCH] fix misc cast ' Change 6122 on 2000/05/28 by [EMAIL PROTECTED] 'downgrade fatal error on Cfoo' Change 4255 on 1999/09/30 by [EMAIL PROTECTED] 'remove prehistoric XFree() gunk' Change 4142 on 1999/09/13 by [EMAIL PROTECTED] 'integrate cfgperl contents into' Change 4106 on 1999/09/08 by [EMAIL PROTECTED] 'integrate cfgperl contents into' Change 3622 on 1999/07/06 by [EMAIL PROTECTED] 'applied patch after demunging h' Change 3524 on 1999/06/09 by [EMAIL PROTECTED] 'more complete support for impli' Change 2326 on 1998/11/27 by [EMAIL PROTECTED] 'integrate changes#2304,2305,230' Change 1578 on 1998/07/20 by [EMAIL PROTECTED] 'complete s/foo/PL_foo/ changes ' Change 1575 on 1998/07/20 by [EMAIL PROTECTED] 'integrate ansi branch to get s/' Change 822 on 1998/03/16 by [EMAIL PROTECTED] 'Bump patchlevel.h to 63. ' Change 496 on 1998/02/11 by [EMAIL PROTECTED] 'Integrate win32 into mainline. ' Change 457 on 1998/02/03 by [EMAIL PROTECTED] 'Integrate win32 into mainline. ' Change 439 on 1998/01/27 by [EMAIL PROTECTED] 'Integrate ansi branch into main' Change 296 on 1997/11/25 by [EMAIL PROTECTED] 'Integrate from ansi branch to m' Change 77 on 1997/09/29 by [EMAIL PROTECTED] 'Start merge with maint-5.004 br' Change 18 on 1997/05/25 by [EMAIL PROTECTED] 'First stab at 5.003 - 5.004 in' Change 1 on 1997/03/28 by [EMAIL PROTECTED] 'Perl 5.003 check-in '
