> Too late to run INIT block at C:/Perl/site/lib/Devel/Cover.pm line 153.
> Too late to run CHECK block at C:/Perl/site/lib/Devel/Cover.pm line 155.
don't worry about those.
> The only interesting line in t/logs/error_log is:
> [Mon Jul 18 14:32:40 2005] [error] [client 127.0.0.1] failed to
>
Geoffrey Young wrote:
Stas Bekman wrote:
Geoffrey Young wrote:
Now, this looks like a bug. The T::B->reset method expects an object,
Apache::Test calls it as a class method. I allow for the possibility that
I've completely misunderstood everything--or even just some things.
well, it's n
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>>Now, this looks like a bug. The T::B->reset method expects an object,
>>>Apache::Test calls it as a class method. I allow for the possibility that
>>>I've completely misunderstood everything--or even just some things.
>>
>>
>>well, it's not exactly
Geoffrey Young wrote:
>>Now, this looks like a bug. The T::B->reset method expects an object,
>>Apache::Test calls it as a class method. I allow for the possibility that
>>I've completely misunderstood everything--or even just some things.
>
>
> well, it's not exactly a bug - it looks like Test
> Now, this looks like a bug. The T::B->reset method expects an object,
> Apache::Test calls it as a class method. I allow for the possibility that
> I've completely misunderstood everything--or even just some things.
well, it's not exactly a bug - it looks like Test::Builder changed
reset() fr
Geoffrey Young wrote:
It doesn't work for me.
% rm -rf Apache-Test/
% svn up Apache-Test
At revision 153479.
it doesn't fetch the new Apache-Test.
It seems that only a completely new checkout of the whole modperl-2.0
brings it in.
hmm, it worked for me. justin said something about needing to svn
> It doesn't work for me.
>
> % rm -rf Apache-Test/
> % svn up Apache-Test
> At revision 153479.
>
> it doesn't fetch the new Apache-Test.
>
> It seems that only a completely new checkout of the whole modperl-2.0
> brings it in.
hmm, it worked for me. justin said something about needing to sv
Geoffrey Young wrote:
hi all...
we (uh, I) kinda messed up during the first migration go-round and
Apache-Test has moved once again, this time to a more svn-compliant
directory structure. hopefully this will be the final resting place, at
least for a while :)
the Apache-Test/ subdirectory of the p
Geoffrey Young wrote:
hi all...
we (uh, I) kinda messed up during the first migration go-round and
Apache-Test has moved once again, this time to a more svn-compliant
directory structure. hopefully this will be the final resting place, at
least for a while :)
the Apache-Test/ subdirectory of the p
Geoffrey Young wrote:
[...]
cool. I'm going to spend some time over the next few days trying to get
this situated, then.
should there be Apache-Test/dist too? or should the CPAN distribution be
sufficient?
we can do that, although http://search.cpan.org/dist/Apache-Test/ is just as
good. but if
> yay, php docs at perl.apache.org :)
they may be more popular, but I think we still win when it comes to
open-source altruism :)
>> sure. but what I'm hoping to accomplish is a more coherent set of
>> documentation for Apache-Test that transcends what we've done (and
>> documented well) over i
Geoffrey Young wrote:
additionally I think we should have subdirectories for each of the supported
languages
/Apache-Test/perl
/Apache-Test/php
/Apache-Test/parrot (someday soon)
and so on. in fact, it was the need for a home for php-related docs and
whatnot that prompted this move in the first pl
>> if you don't find any with grep, then there are none. So we should add
>> one then :)
:)
yes, now that it's officially ours we should do more to publicise it.
>>
>>> additionally, we should probably update httpd.apache.org/test and
>>> create a
>>> home for Apache-Test under perl.apache.org.
Stas Bekman wrote:
Geoffrey Young wrote:
Also Geoff please don't forget to update the documentation. Both inside
the module and at perl.apache.org docs. Thanks.
I couldn't find any mentions of the location of the repository outside of
README-SVN. do you know of others?
if you don't find any with
Geoffrey Young wrote:
Also Geoff please don't forget to update the documentation. Both inside
the module and at perl.apache.org docs. Thanks.
I couldn't find any mentions of the location of the repository outside of
README-SVN. do you know of others?
if you don't find any with grep, then there ar
> Also Geoff please don't forget to update the documentation. Both inside
> the module and at perl.apache.org docs. Thanks.
I couldn't find any mentions of the location of the repository outside of
README-SVN. do you know of others?
additionally, we should probably update httpd.apache.org/test
Stas Bekman wrote:
Also Geoff please don't forget to update the documentation. Both inside
the module and at perl.apache.org docs. Thanks.
(both the svn info and the lists)
and now we no longer have the archives. So if you could contact
http://marc.theaimsgroup.com and ask them to add these two n
Geoffrey Young wrote:
Stas Bekman wrote:
Geoffrey Young wrote:
the Apache-Test/ subdirectory of the perl-framework has migrated to a new
location:
https://svn.apache.org/repos/asf/perl/Apache-Test
what this means for you is that you need to manually adjust your checkout
$ rm -rf Apache-Test/
$
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>> the Apache-Test/ subdirectory of the perl-framework has migrated to a new
>> location:
>>
>> https://svn.apache.org/repos/asf/perl/Apache-Test
>>
>> what this means for you is that you need to manually adjust your checkout
>>
>> $ rm -rf Apache
Geoffrey Young wrote:
the Apache-Test/ subdirectory of the perl-framework has migrated to a new
location:
https://svn.apache.org/repos/asf/perl/Apache-Test
what this means for you is that you need to manually adjust your checkout
$ rm -rf Apache-Test/
$ svn update
ugh, rm is not a good idea i
Oden Eriksson wrote:
onsdag 26 januari 2005 00.47 skrev Stas Bekman:
One thing I want to figure out is that note in README that suggests to
write httpd.conf.in. Can we nuke that, or do you use that?
Please leave as is. It can come handy.
I for one wasn't able to get it to work as it's documented in
onsdag 26 januari 2005 00.47 skrev Stas Bekman:
> >>One thing I want to figure out is that note in README that suggests to
> >>write httpd.conf.in. Can we nuke that, or do you use that?
> >
> > Please leave as is. It can come handy.
>
> I for one wasn't able to get it to work as it's documented in
One thing I want to figure out is that note in README that suggests to
write httpd.conf.in. Can we nuke that, or do you use that?
Please leave as is. It can come handy.
I for one wasn't able to get it to work as it's documented in that file. I
think you said it did work for you. I didn't look at
tisdag 25 januari 2005 02.49 skrev Stas Bekman:
> Oden Eriksson wrote:
> >>>But now I need to feed it with defines somehow and make it include
> >>> module specific files from /etc/conf/conf.d/*.conf that should provide
> >>> further info.
> >>>
> >>>This is tricky, but fun!
> >>
> >>If you explain
Oden Eriksson wrote:
But now I need to feed it with defines somehow and make it include module
specific files from /etc/conf/conf.d/*.conf that should provide further
info.
This is tricky, but fun!
If you explain what exactly do you mean, we may know how to make that
easier.
It is tricky due many
torsdag 13 januari 2005 21.13 skrev Stas Bekman:
> Oden Eriksson wrote:
> >>Please try this patch:
> >
> > That worked! Thanks Stas!
>
> Now committed. Will be out in A-T 1.20 (let us know if you want us to make
> a new release).
Got the new release and the package is updated now.
> > But now I n
lördag 22 januari 2005 02.24 skrev Stas Bekman:
> Oden Eriksson wrote:
> > torsdag 13 januari 2005 16.15 skrev Stas Bekman:
> >>Oden Eriksson wrote:
> >
> > [...]
> >
> >The system is clean except for parts of mod_perl 1.x that seems to be
> > a requisite to get this mod_perl pick up missin
Oden Eriksson wrote:
torsdag 13 januari 2005 16.15 skrev Stas Bekman:
Oden Eriksson wrote:
[...]
The system is clean except for parts of mod_perl 1.x that seems to be a
requisite to get this mod_perl pick up missing pieces. Here's what's
installed:
what do you mean requisite? you mean mp2 require
torsdag 13 januari 2005 16.15 skrev Stas Bekman:
> Oden Eriksson wrote:
[...]
> >>>The system is clean except for parts of mod_perl 1.x that seems to be a
> >>>requisite to get this mod_perl pick up missing pieces. Here's what's
> >>>installed:
> >>
> >>what do you mean requisite? you mean mp2 re
fredag 14 januari 2005 13.16 skrev Oden Eriksson:
> Hi again.
>
> The port set in the config are all correctly chosen except for
> "filter_out_apache" that uses port zero for some reason.
Ahh, never mind. I had zombie httpd processes.
--
Regards // Oden Eriksson
Hi again.
The port set in the config are all correctly chosen except for
"filter_out_apache" that uses port zero for some reason.
--
Regards // Oden Eriksson
torsdag 13 januari 2005 21.17 skrev Stas Bekman:
> Oden Eriksson wrote:
> >>>Does the A-T stuff has to be installed? Is it required during mod_perl
> >>>runtime in any way?
> >>
> >>No and No.
> >
> > Thank you. I was planning to make this "make test" work first, then don't
> > install the A-T stuf
torsdag 13 januari 2005 21.30 skrev Stas Bekman:
> Stas Bekman wrote:
> Maybe it's a thing of the past, or I'm just too tired right now. At
> one time I saw something like "Found mod_perl-1.x, good, will install
> relatively to Apache2/". And that message was despite the
> MP_IN
Stas Bekman wrote:
Maybe it's a thing of the past, or I'm just too tired right now. At one
time I saw something like "Found mod_perl-1.x, good, will install
relatively to Apache2/". And that message was despite the
MP_INST_APACHE2=1 thing.
Hmm, do you think it's a misleading message? I guess we co
Oden Eriksson wrote:
Does the A-T stuff has to be installed? Is it required during mod_perl
runtime in any way?
No and No.
Thank you. I was planning to make this "make test" work first, then don't
install the A-T stuff from the mod_perl2 package but provide a new
perl-Apache-Test package that po
Oden Eriksson wrote:
Please try this patch:
That worked! Thanks Stas!
Now committed. Will be out in A-T 1.20 (let us know if you want us to make
a new release).
But now I need to feed it with defines somehow and make it include module
specific files from /etc/conf/conf.d/*.conf that should prov
torsdag 13 januari 2005 16.16 skrev Stas Bekman:
> Oden Eriksson wrote:
> [...]
>
> > To test this I have removed the tagging but got problems elsewhere
> > because we use defines to activate stuff in our config. So for example
> > *if* mod_env is installed we pass -DHAVE_ENV when starting apache.
torsdag 13 januari 2005 16.15 skrev Stas Bekman:
> Oden Eriksson wrote:
> [...]
>
> >>Please post the output of:
> >>% t/TEST -conf -trace=debug
> >
> > Attached.
>
> So it has matched it as revision 1:
> > [ debug] Matched Apache revision
>
> Apache-PREFORK-AdvancedExtranetServer/2.0.52 1
>
> Fr
Stas Bekman wrote:
> Geoffrey Young wrote:
>
>>> In which case we need to remove the custom patterns we have added so
>>> far?
>>
>>
>>
>> hmm, did we actually add any, or just make the regex a bit more loose? I
>> can't recall.
>
>
> can you see how Apache-PREFORK-AdvancedExtranetServer/2.0.
Geoffrey Young wrote:
In which case we need to remove the custom patterns we have added so far?
hmm, did we actually add any, or just make the regex a bit more loose? I
can't recall.
can you see how Apache-PREFORK-AdvancedExtranetServer/2.0.52 matches 1?
That's because our code is completely brok
Oden Eriksson wrote:
[...]
To test this I have removed the tagging but got problems elsewhere because we
use defines to activate stuff in our config. So for example *if* mod_env is
installed we pass -DHAVE_ENV when starting apache. I think the easiest thing
for me to do is to make a wrapper that
Oden Eriksson wrote:
[...]
Please post the output of:
% t/TEST -conf -trace=debug
Attached.
So it has matched it as revision 1:
> [ debug] Matched Apache revision
Apache-PREFORK-AdvancedExtranetServer/2.0.52 1
Frankly I have no idea how could it possibly happen.
And that's where the problem is
torsdag 13 januari 2005 15.34 skrev Stas Bekman:
> Geoffrey Young wrote:
> >>may be we should stop trying to parse the leading string and just gor
> >>for "/x.y.zz" part. Otherwise we will never satisfy everybody.
> >
> > I think the last time this came up we decided that we just couldn't
> > satsi
> In which case we need to remove the custom patterns we have added so far?
hmm, did we actually add any, or just make the regex a bit more loose? I
can't recall.
>
> +1, but the last time we added a new pattern when somebody brought an
> argument, that users weren't able to run A-T because of
Geoffrey Young wrote:
may be we should stop trying to parse the leading string and just gor
for "/x.y.zz" part. Otherwise we will never satisfy everybody.
I think the last time this came up we decided that we just couldn't satsify
everyone and we left it as is.
my personal pov is that Apache-Test
> may be we should stop trying to parse the leading string and just gor
> for "/x.y.zz" part. Otherwise we will never satisfy everybody.
I think the last time this came up we decided that we just couldn't satsify
everyone and we left it as is.
my personal pov is that Apache-Test is for the Apach
torsdag 13 januari 2005 04.05 skrev Stas Bekman:
> Oden Eriksson wrote:
> >>>I have been struggling for several hours now trying to understand how
> >>>Apache-Test is supposed to work with mod_perl-2.0.0-RC3, apache-2.0.52
> >>>and Mandrakelinux. I'm maintaining these softwares in Mandrakelinux.
>
Oden Eriksson wrote:
I have been struggling for several hours now trying to understand how
Apache-Test is supposed to work with mod_perl-2.0.0-RC3, apache-2.0.52
and Mandrakelinux. I'm maintaining these softwares in Mandrakelinux.
Apache-Test seems to think it's a apache-1.x environment passing -D
torsdag 13 januari 2005 01.56 skrev Stas Bekman:
> Hi Oden,
Hi Stas.
> > I have been struggling for several hours now trying to understand how
> > Apache-Test is supposed to work with mod_perl-2.0.0-RC3, apache-2.0.52
> > and Mandrakelinux. I'm maintaining these softwares in Mandrakelinux.
> >
>
Hi Oden,
I have been struggling for several hours now trying to understand how
Apache-Test is supposed to work with mod_perl-2.0.0-RC3, apache-2.0.52 and
Mandrakelinux. I'm maintaining these softwares in Mandrakelinux.
Apache-Test seems to think it's a apache-1.x environment passing -D APACHE1
Actually I think it's simpler than what I thought. Since the workaround is
needed when build A-T alone, this should do the trick. Could you please
test that it still does what it's supposed to do?
Index: Apache-Test/Makefile.PL
===
Geoffrey Young wrote:
doesn't seem to be right. sub is a compile time directive, so putting it
in a conditional doesn't prevent from it being compiled:
indeed. guess I wasn't thinking, which seems to be happening lots lately.
No worries :) There is a way too many things to think about.
Moreover i
> doesn't seem to be right. sub is a compile time directive, so putting it
> in a conditional doesn't prevent from it being compiled:
indeed. guess I wasn't thinking, which seems to be happening lots lately.
> Moreover it now introduces a warning in mp2 build
> Subroutine MY::libscan redefined
Seth, please always post any A-T related questions to the httpd-test list:
http://perl.apache.org/maillist/test-dev.html#Subscription_Information
Seth Gordon wrote:
OK, if I make the following change to Apache::TestServer
sub args {
my $self = shift;
my $vars = $self->{config}->{vars};
>
> Geoff, did you get all that? ;-)
kinda. I'll roll up a candidate for this next week and let you add/tweak
the appropriate Build.PL before I release it into the wild.
--Geoff
David Wheeler wrote:
On Jul 9, 2004, at 2:23 PM, Stas Bekman wrote:
I don't know how M::B does the version checking, but EU::MM does file
parsing, searching for the $VERSION line, so the version number must
be hardcoded there, unless you do something like:
$VERSION = do { require Apache2; requir
On Jul 9, 2004, at 2:23 PM, Stas Bekman wrote:
I don't know how M::B does the version checking, but EU::MM does file
parsing, searching for the $VERSION line, so the version number must
be hardcoded there, unless you do something like:
$VERSION = do { require Apache2; require mod_perl.pm;
$mod_
Randy Kobes wrote:
On Fri, 9 Jul 2004, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
What about requiring 'Apache' for mp1-related modules
(since 'Apache' doesn't exist within mp2), and for mp2
modules, requiring 'Apache2' (which doesn't exist within
mp1)?
It won't work since the version number li
On Fri, 9 Jul 2004, Stas Bekman wrote:
> Randy Kobes wrote:
[ ... ]
> > What about requiring 'Apache' for mp1-related modules
> > (since 'Apache' doesn't exist within mp2), and for mp2
> > modules, requiring 'Apache2' (which doesn't exist within
> > mp1)?
>
> It won't work since the version number
David Wheeler wrote:
On Jul 9, 2004, at 2:03 PM, Randy Kobes wrote:
But won't the CPAN indices (which are used by both CPAN.pm
and CPANPLUS.pm) still just recognize one version of
mod_perl.pm? Either the current one associated with mp1, or,
when mp2 is out of development, that associated with mp2
(
On Jul 9, 2004, at 2:03 PM, Randy Kobes wrote:
But won't the CPAN indices (which are used by both CPAN.pm
and CPANPLUS.pm) still just recognize one version of
mod_perl.pm? Either the current one associated with mp1, or,
when mp2 is out of development, that associated with mp2
(assuming mod_perl.pm
On Fri, 9 Jul 2004, David Wheeler wrote:
> On Jul 9, 2004, at 1:45 PM, David Wheeler wrote:
>
> > use 5.00503;
> > use Apache::TestMB;
> >
> > Apache::TestMB->new(
> > module_name=> 'Apache::Test::Skeleton',
> > license=> 'perl',
> > requires => { 'mod_perl' => ">=
On Jul 9, 2004, at 1:45 PM, David Wheeler wrote:
use 5.00503;
use Apache::TestMB;
Apache::TestMB->new(
module_name=> 'Apache::Test::Skeleton',
license=> 'perl',
requires => { 'mod_perl' => ">= 1.0, < 1.99",
},
build_requires => { Test::More
On Jul 9, 2004, at 1:38 PM, Stas Bekman wrote:
It won't work since the version number lives in the package mod_perl.
and most likely you'd want to require a minimal version at some point.
Ah, but this is one of the beauties of Module::Build, my friends.
Behold!
use 5.00503;
use Apache::TestMB;
A
Randy Kobes wrote:
On Fri, 9 Jul 2004, David Wheeler wrote:
On Jul 9, 2004, at 1:09 PM, Stas Bekman wrote:
There is no Apache.pm in mp2. You probably wanted to say:
requires => { 'mod_perl' => 0,
Right. In fact, it should probably be
requires => { 'mod_perl' => '1.0',
in t
On Fri, 9 Jul 2004, David Wheeler wrote:
> On Jul 9, 2004, at 1:09 PM, Stas Bekman wrote:
>
> > There is no Apache.pm in mp2. You probably wanted to say:
> >
> > > requires => { 'mod_perl' => 0,
>
> Right. In fact, it should probably be
>
> requires => { 'mod_perl' => '1.0
David Wheeler wrote:
On Jul 9, 2004, at 1:09 PM, Stas Bekman wrote:
There is no Apache.pm in mp2. You probably wanted to say:
> requires => { 'mod_perl' => 0,
Right. In fact, it should probably be
requires => { 'mod_perl' => '1.0',
in the MP1 example, and
requires
On Jul 9, 2004, at 1:09 PM, Stas Bekman wrote:
There is no Apache.pm in mp2. You probably wanted to say:
> requires => { 'mod_perl' => 0,
Right. In fact, it should probably be
requires => { 'mod_perl' => '1.0',
in the MP1 example, and
requires => { 'mod_perl' =>
David Wheeler wrote:
[...]
And in fact, to make it more generally useful, I think I'd actually make
it:
use 5.00503;
use Apache::TestMB;
Apache::TestMB->new(
module_name=> 'Apache::Test::Skeleton',
license=> 'perl',
requires => { 'Apache' => 0,
On Jul 9, 2004, at 11:41 AM, Stas Bekman wrote:
Isn't that Apache::TestMB?
D'oh! Yes! Sorry!
use 5.00503;
use Apache::TestMB;
Apache::TestMB->new(
module_name => 'Apache::Test::Skeleton',
)->create_build_script;
And in fact, to make it more generally useful, I think I'd actually
make it:
use
David Wheeler wrote:
On Jul 7, 2004, at 7:01 AM, Geoffrey Young wrote:
the bug reporting skeleton has become so useful for me (and others)
that I
have created two new skeletons:
I would add a Build.PL with these contents:
use 5.00503;
use Apache::Test::MB;
Isn't that Apache::TestMB?
Apache::Test:
On Jul 7, 2004, at 7:01 AM, Geoffrey Young wrote:
the bug reporting skeleton has become so useful for me (and others)
that I
have created two new skeletons:
I would add a Build.PL with these contents:
use 5.00503;
use Apache::Test::MB;
Apache::Test::MB->new(
module_name => 'Apache::Test::Skele
> Nice work, Geoff. May be they should live on CPAN, so one doesn't need
> to remember where to grab them from? e.g. create an empty
> Apache::Test::Skeleton::mod_perl(1|2) packages with versioning in those
> tars and upload to CPAN?
that's an idea, but kind of a long name :) maybe just
Apache::
Geoffrey Young wrote:
hi all...
the bug reporting skeleton has become so useful for me (and others) that I
have created two new skeletons:
http://perl.apache.org/~geoff/Apache-Test-skeleton-mp1.tar.gz
http://perl.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz
these are essentially the same a
On Jun 14, 2004, at 1:40 PM, Stas Bekman wrote:
I suppose we could fix Apache::testold (it was renamed) to have -d if
it can be made into more than a hack. Though I'm not sure when a new
version of mp1 is going to be released.
Looks like it would be pretty easy to add to MM_test(), though I don't
David Wheeler wrote:
On Jun 14, 2004, at 10:37 AM, David Wheeler wrote:
I was able to hack it in, but unfortunately it doesn't eliminate the
problem. Very odd...
No, I take it back; it _did_ help! I just got a different error:
Ouch! ap_mm_create(1048576,
"/Users/david/dev/perl/mason-1.2/dist/t/l
On Jun 14, 2004, at 10:37 AM, David Wheeler wrote:
I was able to hack it in, but unfortunately it doesn't eliminate the
problem. Very odd...
No, I take it back; it _did_ help! I just got a different error:
Ouch! ap_mm_create(1048576,
"/Users/david/dev/perl/mason-1.2/dist/t/logs/httpd.mm.8917") fa
On Jun 14, 2004, at 10:30 AM, David Wheeler wrote:
So this is what I needed to know; thanks. I'll try to hack the Apache
startup code in this module to use -d and see if that helps things.
I was able to hack it in, but unfortunately it doesn't eliminate the
problem. Very odd...
Regards,
David
On Jun 14, 2004, at 1:24 AM, Stas Bekman wrote:
A-T writes what it does:
Right, so does A-t:
/Users/david/dev/perl/mason-1.2/dist/t/httpd -f
/Users/david/dev/perl/mason-1.2/dist/t/httpd.conf
With Apache 1.x, A-T does this:
/usr/local/apache/bin/httpd -d
/Users/david/dev/perl/MasonX-Interp-WithCa
David Wheeler wrote:
On Jun 13, 2004, at 2:13 PM, Stas Bekman wrote:
I suppose so. Check that A-t generates ServerRoot setting
pointing to the local dir.
It does. I don't know what else might be the problem...what command does
A-T use to start Apache? Could it be different somehow than what A-t
On Jun 13, 2004, at 3:24 PM, Joe Orton wrote:
The problem is that if you use an EAPI-patched-1.3, you get a path to a
mutex file hard-coded into the httpd binary. If this path is absolute,
as above, then you need permission in that path to create a file, so
using httpd-test to run httpd as a user
On Jun 13, 2004, at 2:13 PM, Stas Bekman wrote:
I suppose so. Check that A-t generates ServerRoot setting
pointing to the local dir.
It does. I don't know what else might be the problem...what command
does A-T use to start Apache? Could it be different somehow than what
A-t uses?
Regards,
David
On Mon, Jun 14, 2004 at 12:13:53AM +0300, Stas Bekman wrote:
> David Wheeler wrote:
> >>Where does it create that semaphore file with A-T? May be it's the env
> >>val for $TMPDIR? but it's specific to modperl-2.0.
> >
> >All I know is what the error message says:
> >
> >Ouch! ap_mm_create(1048576,
David Wheeler wrote:
On Jun 11, 2004, at 8:24 PM, Stas Bekman wrote:
I'm working on a module in another project that's still using the old
Apache::test (not the lc "test").
Any reason why you wouldn't move to A-T?
Like I said, it's not my module, so it's not my call.
Neither I familiar with A-t.
On Jun 11, 2004, at 8:24 PM, Stas Bekman wrote:
I'm working on a module in another project that's still using the old
Apache::test (not the lc "test").
Any reason why you wouldn't move to A-T?
Like I said, it's not my module, so it's not my call.
Where does it create that semaphore file with A-T?
David Wheeler wrote:
Hi All,
I'm working on a module in another project that's still using the old
Apache::test (not the lc "test").
Any reason why you wouldn't move to A-T?
When I attempt to use it with my copy
of apache with mod_ssl statically compiled in with mm support, I get
this error:
O
Abhishek Khandelwal wrote:
Is there a way to count the total number of tests when the perl-test
suits are run.
If all the tests passes, then in final report it specifies the total
number of files and total number of tests run. But in case there are
tests which fails, it publishes a report which loo
On Jan 30, 2004, at 5:18 PM, Stas Bekman wrote:
David, I've committed the required changed. Please test that it works
for you.
I still have a few other things to fix (t/SMOKE), but they shouldn't
affect you.
Yep, works great for me. Thanks!
David
David, I've committed the required changed. Please test that it works for you.
I still have a few other things to fix (t/SMOKE), but they shouldn't affect you.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http:
I forgot that we already have the vars() shortcut, I have added a query mode
to it, so now you can do:
my $serverroot = Apache::Test::vars->{serverroot};
my $serverroot = Apache::Test::vars('serverroot');
my($top_dir, $t_dir) = Apache::Test::vars(qw(top_dir t_dir));
that's almost as good as
Geoffrey Young wrote:
Stas Bekman wrote:
David Wheeler wrote:
On Jan 28, 2004, at 2:21 PM, Stas Bekman wrote:
Then for now I'll just use:
my $serverroot = Apache::Test::config()->{vars}>{serverroot};
the idea is to get away from that - it's way too verbose to be conventient.
OK
AUTOLOAD is okay
Stas Bekman wrote:
> David Wheeler wrote:
>
>> On Jan 28, 2004, at 2:21 PM, Stas Bekman wrote:
>>
>>> Then for now I'll just use:
>>>
>>> my $serverroot = Apache::Test::config()->{vars}>{serverroot};
the idea is to get away from that - it's way too verbose to be conventient.
>> AUTOLOAD is o
David Wheeler wrote:
On Jan 28, 2004, at 2:21 PM, Stas Bekman wrote:
Then for now I'll just use:
my $serverroot = Apache::Test::config()->{vars}>{serverroot};
Surely you mean
my $serverroot = Apache::Test::config()->{vars}->{serverroot};
although this should work, too:
my $serverroot = Apach
On Jan 28, 2004, at 2:21 PM, Stas Bekman wrote:
Then for now I'll just use:
my $serverroot = Apache::Test::config()->{vars}>{serverroot};
Surely you mean
my $serverroot = Apache::Test::config()->{vars}->{serverroot};
although this should work, too:
my $serverroot = Apache::Test::config->{vars
Geoffrey Young wrote:
Stas Bekman wrote:
David Wheeler wrote:
On Jan 23, 2004, at 12:21 PM, Stas Bekman wrote:
If you really want to, we could install Apache::Test::AUTOLOAD
which will map $AUTOLOAD to
Apache::Test::config()->{vars}->{$AUTOLOAD}, so you could say:
Apache::Test::serverroot
Or, I
Stas Bekman wrote:
> David Wheeler wrote:
>
>> On Jan 23, 2004, at 12:21 PM, Stas Bekman wrote:
>>
>>> If you really want to, we could install Apache::Test::AUTOLOAD
>>> which will map $AUTOLOAD to
>>> Apache::Test::config()->{vars}->{$AUTOLOAD}, so you could say:
>>>
>>> Apache::Test::serverr
David Wheeler wrote:
On Jan 23, 2004, at 12:21 PM, Stas Bekman wrote:
If you really want to, we could install Apache::Test::AUTOLOAD
which will map $AUTOLOAD to
Apache::Test::config()->{vars}->{$AUTOLOAD}, so you could say:
Apache::Test::serverroot
Or, I imagine,
Apache::Test->serverroot
Yes
On Jan 23, 2004, at 12:21 PM, Stas Bekman wrote:
If you really want to, we could install Apache::Test::AUTOLOAD
which will map $AUTOLOAD to
Apache::Test::config()->{vars}->{$AUTOLOAD}, so you could say:
Apache::Test::serverroot
Or, I imagine,
Apache::Test->serverroot
That's kind of cool.
Davi
David Wheeler wrote:
On Jan 23, 2004, at 8:27 AM, Geoffrey Young wrote:
it's not that I don't agree this ought to be fixed, or that with the
patch
we have desirable behavior, it's just that I want it to be easy and the
current ServerRoot placement isn't really easy or intuitive. maybe
Apache::Tes
On Jan 23, 2004, at 8:27 AM, Geoffrey Young wrote:
it's not that I don't agree this ought to be fixed, or that with the
patch
we have desirable behavior, it's just that I want it to be easy and the
current ServerRoot placement isn't really easy or intuitive. maybe
Apache::Test could export a SERV
1 - 100 of 166 matches
Mail list logo
