While it was relatively fresh in my mind (I'm going
to a workshop next week), I converted a set of the
apr tests to use a common base under t/lib/TestAPRlib/
for both the t/apr/ and t/apr-ext/ tests. This is
at http://www.apache.org/~randyk/t_apr.tar.gz,
which unpacks into a series of individual di
Thanks Joe, now committed with a few tweaks. Now passes tests with both
5.6 and 5.8 (skipping values sub-tests for 5.6).
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide -
Randy Kobes wrote:
[...]
That's a good point - what about the following, which
should also include Marcus' case of using MP_APXS instead
+1, but the style is not right.
+if (Apache::TestConfig::WIN32) {
+my $ap_bindir = $build->apr_bindir();
+if (! $ap_bindir) {
+$ap
On Wed, 14 Jul 2004, Stas Bekman wrote:
> doh! I forgot to send it :)
:)
> Randy Kobes wrote:
> > On Wed, 14 Jul 2004, Stas Bekman wrote:
> >
> >
> >>Markus Wichitill wrote:
> >>
> Adding MP_AP_PREFIX/bin
> to your PATH is the simplest approach to this (I'll have
> to see about doing
So I suppose we should go with:
our $VERSION = do { require Apache2; require mod_perl;
$mod_perl::VERSION };
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://p
doh! I forgot to send it :)
Randy Kobes wrote:
On Wed, 14 Jul 2004, Stas Bekman wrote:
Markus Wichitill wrote:
Adding MP_AP_PREFIX/bin
to your PATH is the simplest approach to this (I'll have
to see about doing this automatically for the tests).
How about this?
I'm not sure what is it for, too muc
Randy Kobes wrote:
No, I wasn't thinking of that possibility; I just thought
MP_AP_PREFIX would be simpler, but I forgot about using
MP_APXS instead. What about the following - it tries
both, and if neither are defined, it give up.
===
Ind
Markus Wichitill wrote:
It comes about because, when running the tests, Apache
may need certain external dlls in the Apache bin/ directory.
The PATH is used to search for these dlls.
What about the following?
+my $ap_bindir = File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin');
That doesn't wor
On Thu, 15 Jul 2004, Markus Wichitill wrote:
> > It comes about because, when running the tests, Apache
> > may need certain external dlls in the Apache bin/ directory.
> > The PATH is used to search for these dlls.
>
> > What about the following?
> > +my $ap_bindir = File::Spec->catdir($build
It comes about because, when running the tests, Apache
may need certain external dlls in the Apache bin/ directory.
The PATH is used to search for these dlls.
What about the following?
+my $ap_bindir = File::Spec->catdir($build->{MP_AP_PREFIX}, 'bin');
That doesn't work with "perl Makefile.PL
[EMAIL PROTECTED] wrote:
randyk 2004/07/14 18:32:26
Modified:t/apr-ext table.t
t/response/TestAPR table.pm
Added: t/lib/TestAPRlib table.pm
Log:
put common tests for APR::Table under t/lib/TestAPRlib/table.pm,
to be run from both t/apr-ext/table.t and t/apr/t
On Wed, 14 Jul 2004, Stas Bekman wrote:
> Markus Wichitill wrote:
> >>Adding MP_AP_PREFIX/bin
> >>to your PATH is the simplest approach to this (I'll have
> >>to see about doing this automatically for the tests).
> >
> > How about this?
>
> I'm not sure what is it for, too much context removed, bu
Joe Schaefer wrote:
? Perhaps
? config.nice
Index: docs/api/APR/Table.pod
Thanks Joe.
--
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EM
Randy Kobes wrote:
[ patch snipped ]
Works great for me on i686-linux (perl-5.8.4) with
Apache/2.0.50 prefork.
I was just about to commit a patch so as a common block of
code could run tests under t/apr/ and t/apr-ext/. Should I
hold off on that (as it involves changing t/apr-ext/apr.t,
and so woul
[ patch snipped ]
Works great for me on i686-linux (perl-5.8.4) with
Apache/2.0.50 prefork.
I was just about to commit a patch so as a common block of
code could run tests under t/apr/ and t/apr-ext/. Should I
hold off on that (as it involves changing t/apr-ext/apr.t,
and so would break Joe's pat
? Perhaps
? config.nice
Index: docs/api/APR/Table.pod
===
RCS file: /home/cvspublic/modperl-docs/src/docs/2.0/api/APR/Table.pod,v
retrieving revision 1.9
diff -u -r1.9 Table.pod
--- docs/api/APR/Table.pod 22 May 2004 02:03:26 - 1.9
On Wed, 14 Jul 2004, Stas Bekman wrote:
> Stas Bekman wrote:
> > Randy Kobes wrote:
> >
> >> On Wed, 14 Jul 2004, Randy Kobes wrote:
> >>
> >>> For making the tests for apr/apr-ext share a common
> >>> base under modperl-2.0/t/lib/TestAPRlib/, one must
> >>> at present 'use lib q(.)' in the ap
Stas Bekman wrote:
Randy Kobes wrote:
On Wed, 14 Jul 2004, Randy Kobes wrote:
For making the tests for apr/apr-ext share a common
base under modperl-2.0/t/lib/TestAPRlib/, one must
at present 'use lib q(.)' in the appropriate
places for both the t/apr/ and t/apr-ext/ tests.
Would the following
Joe Schaefer wrote:
[...]
In which case we first need to find out how to clearly indicate to a
user that values() are broken.
values() has *never, ever* worked for multivalued keys.
This is a bugfix for values(), and it requires 5.8.0 or better.
The remainder of the patch fixes each() (which agai
Randy Kobes wrote:
On Wed, 14 Jul 2004, Randy Kobes wrote:
For making the tests for apr/apr-ext share a common
base under modperl-2.0/t/lib/TestAPRlib/, one must
at present 'use lib q(.)' in the appropriate
places for both the t/apr/ and t/apr-ext/ tests.
Would the following patch be OK to add
Markus Wichitill wrote:
Adding MP_AP_PREFIX/bin
to your PATH is the simplest approach to this (I'll have
to see about doing this automatically for the tests).
How about this?
I'm not sure what is it for, too much context removed, but I guess Randy
knows what is it about. I have only one comment r
On Wed, 14 Jul 2004, Randy Kobes wrote:
> For making the tests for apr/apr-ext share a common
> base under modperl-2.0/t/lib/TestAPRlib/, one must
> at present 'use lib q(.)' in the appropriate
> places for both the t/apr/ and t/apr-ext/ tests.
> Would the following patch be OK to add this to
Randy Kobes wrote:
For making the tests for apr/apr-ext share a common
base under modperl-2.0/t/lib/TestAPRlib/, one must
at present 'use lib q(.)' in the appropriate
places for both the t/apr/ and t/apr-ext/ tests.
Would the following patch be OK to add this to
httpd.conf, so one doesn't have
> Adding MP_AP_PREFIX/bin
> to your PATH is the simplest approach to this (I'll have
> to see about doing this automatically for the tests).
How about this?
Index: Makefile.PL
===
RCS file: /home/cvspublic/modperl-2.0/Makefile.PL,v
r
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
[...]
> > I didn't notice the 5.6.x issue until after I submitted the patch,
> > however the fix for that is very simple, so I'd prefer to wait until
> > the patch is added before adding the 2-3 neded #ifdef 's to
> > modperl_common_u
For making the tests for apr/apr-ext share a common
base under modperl-2.0/t/lib/TestAPRlib/, one must
at present 'use lib q(.)' in the appropriate
places for both the t/apr/ and t/apr-ext/ tests.
Would the following patch be OK to add this to
httpd.conf, so one doesn't have to repeat it?
=
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
What about the 5.8.1 requirement? mp2 requires 5.6.1, will it work
there?
No, the mg_copy slot in MGVTBL wasn't added until 5.8.0, so it
will not work (probably won't compile?) for 5.6.x. Unfortunately
I didn't notice the 5.6.x issue u
Stas Bekman <[EMAIL PROTECTED]> writes:
> What about the 5.8.1 requirement? mp2 requires 5.6.1, will it work
> there?
No, the mg_copy slot in MGVTBL wasn't added until 5.8.0, so it
will not work (probably won't compile?) for 5.6.x. Unfortunately
I didn't notice the 5.6.x issue until after I sub
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
So, is it good at all if we add this overhead? I understand that the
patch that you've sent following this email includes that copying, right?
No- the patch avoids this copying overhead by simply invoking SvGETMAGIC
as soon as th
Stas Bekman wrote:
Randy Kobes wrote:
I'm not sure if this isn't a problem on my end (I've cleaned
things out and made sure cvs is current), but with mp2 cvs,
on my linux system (Apache/2.0.50 prefork,
non-multi-threaded perl-5.8.4), I get a problem building:
mod_perl.c: In function `modperl_shutd
Randy Kobes wrote:
I'm not sure if this isn't a problem on my end (I've cleaned
things out and made sure cvs is current), but with mp2 cvs,
on my linux system (Apache/2.0.50 prefork,
non-multi-threaded perl-5.8.4), I get a problem building:
cd "src/modules/perl" && make -f Makefile.modperl
make[1]:
I'm not sure if this isn't a problem on my end (I've cleaned
things out and made sure cvs is current), but with mp2 cvs,
on my linux system (Apache/2.0.50 prefork,
non-multi-threaded perl-5.8.4), I get a problem building:
cd "src/modules/perl" && make -f Makefile.modperl
make[1]: Entering director
Stas Bekman <[EMAIL PROTECTED]> writes:
[...]
> So, is it good at all if we add this overhead? I understand that the
> patch that you've sent following this email includes that copying, right?
No- the patch avoids this copying overhead by simply invoking SvGETMAGIC
as soon as the value is crea
On Tue, 13 Jul 2004, Stas Bekman wrote:
> Randy Kobes wrote:
> > Here's a diff for making the code for the APR::Table
> > test run from both t/apr/ and t/apr-ext/.
>
> +1, perfect.
>
> > +require TestAPRlib::table;
>
> why not 'use'?
OK, I'll change that.
> Further, I'd suggest to have a paralle
Philippe M. Chiasson wrote:
[...]
Philippe, where are you with this $bb->cleanup issue?
Well, things are indeed strange. I've just updated httpd an hour ago and I
can still reproduce the problem here, on my work machine. At home, on my
other almost identical linux box (both Fedora Core 2), I can't
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
[...]
:-) Not for this in mp2. Technically the problem lies with
Perl_sv_setsv_flags, which does not copy magic (except for vstrings in
5.8.1+, which explains the current apreq2 code). Once I better
understand the
36 matches
Mail list logo
