On mandag 20 juni 2005, 20:26, Perrin Harkins wrote:
> > Uh, actually, that's what I did in my first version, as it is the
> > intuitive thing to do, and couldn't get it to do what it should...
> > To me, it looked as if just the hash was passed, not the tied
> > object... Of course, it could be th
On Tue, 2005-06-21 at 16:53 -0500, Boysenberry Payne wrote:
> I think this is my scenario.
In that case, fix your @INC and everything will be fine. The problem
described here is not related to mod_perl.
> If one was set up as DSO and the other mod_perl wasn't would that
> make a huge difference
I can duplicate it with the following simple example:
-- mod_perl.conf
PerlRequire conf/startup.pl
SetHandler perl-script
PerlResponseHandler MyHandler
-- startup.pl
use SomeDir::MyPackage;
-- /path/to/SomeDir/MyPackage.pm
package SomePackage;
sub foo { return 1; }
1;
-- /path/
> Yes, the test passes when I change
> $received =~ s{\r}{}g if Apache::TestConfig::WIN32;
> to
> $received =~ s{\r}{}g;# if Apache::TestConfig::WIN32;
>
> but I have no idea why \r appears on linux
I'll bet it's something triggered in APR based on some 64 bit compile flag.
probably a mistake,
>> # expected: content
>> # default-handler subrequest
>> # more content
>> # filter
>
>> # received: content
>> # default-handler subrequest
>> # more content
>> # filter
>
>> not ok 1
>
>hrm, those look the same to me. I guess it's a case of a missing or added
>newline?
>
>> Arch
The URL
ftp://ftp.dev.ecos.de/pub/perl/embperl/Embperl-2.0rc4.tar.gz
has entered CPAN as
file: $CPAN/authors/id/G/GR/GRICHTER/Embperl-2.0rc4.tar.gz
size: 653673 bytes
md5: 631fcaf865348ed4b9e9bf69d4d7ac47
The main change in this version is the adaption to the mod_perl 2 namespace
cha
Kevin A. McGrail wrote:
Philip:
From a thorough glance, it looks good as-is.
My changes are largely contained in AuthDBI.pm and your changes there
are fairly minimal. I performed a patch -p0 against your 0.96 and it
was successful except for the revision number in AuthDBI.pm which you
s
Philip:
From a thorough glance, it looks good as-is.
My changes are largely contained in AuthDBI.pm and your changes there are
fairly minimal. I performed a patch -p0 against your 0.96 and it was
successful except for the revision number in AuthDBI.pm which you should
update to 0.96 (or .9
> # expected: content
> # default-handler subrequest
> # more content
> # filter
> # received: content
> # default-handler subrequest
> # more content
> # filter
> not ok 1
hrm, those look the same to me. I guess it's a case of a missing or added
newline?
> Architecture: 64-bit
hmm... I k
Kevin A. McGrail wrote:
I have finished patches against Apache AuthDBI version 0.94 that
definitely work with mod_perl1 to implement sha1 & md5 encryption in
addition to crypt.
I have placed a patch, the original 0.94 and the patched 0.94KAM up
for download at http://www.thoughtworthy.com/d
-8<-- Start Bug Report 8<--
1. Problem Description:
t/filter/out_str_subreq_default1..1
# Running under perl version 5.008007 for linux
# Current time local: Tue Jun 21 12:11:14 2005
# Current time GMT: Tue Jun 21 16:11:14 2005
# Using Test.pm versio
I finally have what I believe are working versions of Apache::Scoreboard and
Apache::VMonitor that account for the post RC5 name changes (and a couple of
other minor bugs). There's also an update for GTop to allow it to compile
with the latest versions of libgtop.
If someone is willing to test
Joe Schaefer writes:
"D. Hageman" writes:
ggRIASUVORK5CYII=\r\n--AaB03x--
^^
Missing an \r\n there I think.
--
Joe Schaefer
Joe,
That cleared up the issue for me! Thank you for your assistance.
//\\
|| D. Hageman
I have finished patches against Apache
AuthDBI version 0.94 that definitely work with mod_perl1 to implement sha1 &
md5 encryption in addition to crypt.
I have placed a patch, the original 0.94 and the
patched 0.94KAM up for download at http://www.thoughtworthy.com/downloads/.
It uses a
> If the parent post is considered on-topic, why would you want to
> discourage discussion, even if it becomes a wee bit tangential?
job listings for specific positions that involve mod_perl have traditionally
been very welcome here - provided the message is for a real position by
someone willing
ugh, another message lost to the email-eating tree...
reposting.
> What am I missing?
that there was a bug? :)
ok, here's what I think is going on. we only register the %ENV cleanup
function when a Perl*Handler runs for a given request but in your case that
doesn't happen by design, so %ENV
16 matches
Mail list logo
