Geoffrey Young wrote:
>
> Christopher H. Laco wrote:
>> Geoffrey Young wrote:
>>
>>>> Borked by my own patch. Serves me right. :-)
>>>> I shouldn't have assume $self->{'test'} was a hashref..
>>>>
>>>> Now
Geoffrey Young wrote:
>> Borked by my own patch. Serves me right. :-)
>> I shouldn't have assume $self->{'test'} was a hashref..
>>
>> Now I guess the other quesiton is what it is now..
>
> blarg, I was just bitten by this. please try this patch and make sure that
> whatever you were trying to fi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher H. Laco wrote:
> Christopher H. Laco wrote:
>
>>>After upgrading Apache-Test to 1.27, my Makefile.PL dies with this error:
>>>
>>>
>>>
>>>>>Can't use string ("Apache::Te
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christopher H. Laco wrote:
> After upgrading Apache-Test to 1.27, my Makefile.PL dies with this error:
>
>
>>>Can't use string ("Apache::TestMM") as a HASH ref while "strict refs" in use
>>>a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
After upgrading Apache-Test to 1.27, my Makefile.PL dies with this error:
> Can't use string ("Apache::TestMM") as a HASH ref while "strict refs" in use
> at /usr/local/lib/perl/5.8.7/Apache/TestMM.pm line 56.
It's not the most standard MAkefile in
ive to always point to t/logs/cgisock
> regardless of inherited and custom mod_cgid settings
> [Geoffrey Young]
>
> Prevent the config file from being overwritten
> on platforms such as WIN32 under certain conditions.
> [Randy Kobes]
>
> make sure that the TESTS Makefile.PL pa
Christopher H. Laco wrote:
> Christopher H. Laco wrote:
> [snip]
>
> I wonder, and this is only a wonder at this point, if there is something
> somewhere in A-T that is loading mod_perl2 along the way, befure it
> knows it's using Apache (APACHE_TEST_HTTPD=/usr/sbin/apache)
Christopher H. Laco wrote:
[snip]
I wonder, and this is only a wonder at this point, if there is something
somewhere in A-T that is loading mod_perl2 along the way, befure it
knows it's using Apache (APACHE_TEST_HTTPD=/usr/sbin/apache)...then whtn
it tries to load AxKit, which loads A
Geoffrey Young wrote:
t/xsp_cartAxKit at
/usr/local/lib/perl/5.8.4/Apache/Test.pm line 297.
Can't locate object method "boot" via package "mod_perl" at
/usr/lib/perl5/Apache/Constants.pm line 8.
Compilation failed in require at /usr/lib/perl5/Ap
Christopher H. Laco wrote:
> Geoffrey Young wrote:
>
>>>I'm still digging on it... any ideas?
>>
>>
>>no ideas, but look for the
>>
>> #print $@ if $@;
>>
>>around line 300 of lib/Apache/Test.pm. you can uncomment it a
Geoffrey Young wrote:
>>I'm still digging on it... any ideas?
>
>
> no ideas, but look for the
>
> #print $@ if $@;
>
> around line 300 of lib/Apache/Test.pm. you can uncomment it and run in
> verbose mode to get an idea what the eval error is...
>
> --Geoff
>
>
This can't be good...
>
Geoffrey Young wrote:
>> plan tests => 2, need [qw(CGI CGI::Cookie)],
>>- need_cgi, need_lwp;
>>+ need_cgi, need_lwp, need_something_else;
>
>
> oops, that's not part of the patch, of course :)
>
>
> -
Geoffrey Young wrote:
>> plan tests => 2, need [qw(CGI CGI::Cookie)],
>>- need_cgi, need_lwp;
>>+ need_cgi, need_lwp, need_something_else;
>
>
> oops, that's not part of the patch, of course :)
>
>
> -
Now that I have Apache::Test 1.26, Apache1/MP 1.29/Apache2/MP 2.0.2
running on my laptop, I've run into a strange problem with need().
Up until now, this test has worked on my win32 install:
http://handelframework.com/source/trunk/t/xsp_cart.t
More specifically, this line:
> Apache::Test::plan
Geoffrey Young wrote:
>>> - is your setup somehow nonstandard? my 2.0.54 worker install defaulted
>>>to mod_cgid and I have no problems with any tests?
>>
>>
>>If it is, it's whatever Ubuntu 5.04 installs.
>>I'll tinker more with it tonight and see where cgid leads me.
>>
>>I seem to recall it was
Geoffrey Young wrote:
>>> - is your setup somehow nonstandard? my 2.0.54 worker install defaulted
>>>to mod_cgid and I have no problems with any tests?
>>
>>
>>If it is, it's whatever Ubuntu 5.04 installs.
>>I'll tinker more with it tonight and see where cgid leads me.
>>
>>I seem to recall it was
Geoffrey Young wrote:
>>As it turned out, the Ubuntu Apache2 install comes with both mod_cgi AND
>>mod_cgid installed and mod_cgid enabled. A-T apparently detects cgid and
>>tries using that in the config. The dies a horrible death because my
>>user (or nobody when runnung A-T as root) can't fire u
In a fit of boredom, I wiped my FreeBSD install on my laptop and
installed Ubuntu. To continue that fit, I decided to install Apache2 and
give the Apache-Test 1.27 RC a testing.
At first shot, the cookies.t tests failed:
> [EMAIL PROTECTED]:~/Apache-Test-1.27-dev$ perl t/TEST t/cookies.t -verbose
It's not the prettiest thing in the world, but it works... :-)
http://handelframework.com/source/trunk/Makefile.PL
smime.p7s
Description: S/MIME Cryptographic Signature
Geoffrey Young wrote:
skip the tests entirely unless Apache::Test is 1.27? something akin to this
ought to do the trick...
http://search.cpan.org/src/GEOFF/Apache-Clean-0.05/Makefile.PL
--Geoff
That doesn't make a lot of sense in my case. Skipping ~20 test files
when only ~4 of those re
Geoffrey Young wrote:
Hey, why wait until I get home. See attached patch: TestMM.pm.patch.
thanks. applied, tested, committed.
--Geoff
So, with that in hand, how do I deal with the present, before 1.27?
I think I can just make my own Apache::TestMM::test in my Makefile.PL
after I load T
Geoffrey Young wrote:
Unless there's some reason that TestMM is deliberatly ignoring the
test=>TESTS option,
none that I can think of
I'll patch it this evening and send that to the list.
excellent.
--Geoff
Hey, why wait until I get home. See attached patch: TestMM.pm.patch.
All th
Christopher H. Laco wrote:
Unless there's some reason that TestMM is deliberatly ignoring the
test=>TESTS option, I'll patch it this evening and send that to the list.
-=Chris
Anoyher option, or something in addition to changing TestMM::test would
be to add a norecurse option t
Geoffrey Young wrote:
Hey, there's the empty TEST_FILES in TestMM::test. :-/
So, is this a bug, a feature, and oversite?
hmm...
well, I use TEST_FILES all the time
$ make test TEST_FILES=t/Foo TEST_VERBOSE=1
and it works just fine. the crux of this very long message is that TESTS in
Mak
I have a fun problem with Apache-Test and the EU::MM test=>TESTS option.
Long story longer.
I recently added t/*.t tests to test my Catalyst helper modules. These
tests call the helpers modules, which in turn cause Catalyst to create
files (modules, tests, templates) in t/TestApp. Some of thes
Stas Bekman wrote:
David Wheeler wrote:
On Apr 18, 2005, at 9:53 AM, Stas Bekman wrote:
As I've mentioned t/SMOKE is usually run after t/TEST fails, so it
has always relied on the fact that 'make test' was already run and
therefore didn't require to run its own setup.
Should `make smoke` rely on
Stas Bekman wrote:
When you see Perl in the class name, it really means ModPerl-specific.
i.e. it's a subclass that *requires* mod_perl and needed to be be able
to run under mod_perl.
And maybe that's my issue.
After looking at it again, I get the feeling that t/SMOKE for an A-T
dist using mod_
Christopher H. Laco wrote:
Assuming it's the right thing to do, adding the mod_perl config stuff
into TestSmokePerl from TestRunPerl shouldn't be too difficult.
I'm afraid of breaking anything that uses TestSmokePerl, but it doesn't
appear like much, if anything does?
Christopher H. Laco wrote:
So According to
http://perl.apache.org/docs/general/testing/testing.html#C_Apache__TestSmoke__Solution
The sample t/SMOKE.PL files is:
#file:t/SMOKE.PL
#---
#!perl
use strict;
use warnings FATAL => 'all';
use FindBin;
use lib &
Stas Bekman wrote:
Thanks for the explaination, Chris. It's clear now.
As I've mentioned t/SMOKE is usually run after t/TEST fails, so it has
always relied on the fact that 'make test' was already run and therefore
didn't require to run its own setup.
Patches to make it independent are very welc
Stas Bekman wrote:
For that matter, why does t/TEST use TestRunPerl while t/SMOKE uses
TestSmoke? I would've expected TestSmokePerl [no knowing yet the
difference between the two].
Apache::TestRunPerl is a subclass of Apache::TestPerl, which overrides
some method.
SMOKE generated by mod_perl/E
Stas Bekman wrote:
I meant, that I don't understand why do you get stuck at t/SMOKE? Are
you trying to use it and it's not working? Or is it the TestMB that
tries to create it and fails the whole thing, when you don't even want
t/SMOKE? You really need t/TEST for the test suite. t/SMOKE is for
Stas Bekman wrote:
Christopher H. Laco wrote:
Stas Bekman wrote:
I've CC'ed David, who developed Apache::TestMB, so he will hopefully
be able to give you the answers.
David, please take a look at this thread. I can't give you the link,
since I don't think this new list is
Stas Bekman wrote:
I've CC'ed David, who developed Apache::TestMB, so he will hopefully be
able to give you the answers.
David, please take a look at this thread. I can't give you the link,
since I don't think this new list is archived at all. Are you subscribed
to it at all?
Thanks for the fo
Christopher H. Laco wrote:
So, apparently it's trying to run the last script created via
generate_script instead of always running t/TEST.
-=Chris
And the offending part of the code ffrom TestMB.pm:
my $script = $self->localize_file_path($_[0]
? $self->apache_test_s
William McKee wrote:
I'm just spouting thoughts hoping it rings someone elses bell... sorry.
This reminds me of a discussion that took place recently on the MB
mailing list[1]. I wonder what would happen if you leave SMOKE.PL but
comment out all the code. Do the die statements get called? Perhaps
Christopher H. Laco wrote:
Great...two problems in one.
I was not seeing my dies because even though my Build.PL has:
$build->generate_script('t/TEST');
$build->generate_script('t/SMOKE');
The output from perl Build test is:
C:\Development\CPAN\Handel>perl Build test
Christopher H. Laco wrote:
Right, it must be run at test time.
I've worked my way though all of the custom_config_loads and
custom_config_exists I can find, and die-ing before any of them doesn't
make perl Build test die. :-(
This is a tough one...
Great...two problems in one.
I was
Stas Bekman wrote:
Christopher H. Laco wrote:
Christopher H. Laco wrote:
Stas Bekman wrote:
Chris, grep for custom_config_load() which loads that data. and see
why Build doesn't pick it up.
Found it. Should that be called during a test run, or just during the
build?
IF I slap a die
Christopher H. Laco wrote:
Stas Bekman wrote:
Chris, grep for custom_config_load() which loads that data. and see
why Build doesn't pick it up.
Found it. Should that be called during a test run, or just during the
build?
IF I slap a die right inside or custom_config_load, it doesn&
Stas Bekman wrote:
Chris, grep for custom_config_load() which loads that data. and see why
Build doesn't pick it up.
Found it. Should that be called during a test run, or just during the build?
IF I slap a die right inside or custom_config_load, it doesn't die
during 'perl Build test'
-=Chris
This is an all out please for help form someone who understands the
structure of A-T a little better than I.
Just to recap, under ExtUtils::MakeMaker, 'make test' reads the location
of Apache.exe just fine for me. 'perl Build test' fails to read or
receive the value and enters a continous loop aski
Geoffrey Young wrote:
we are pleased to announce the latest Apache-Test release, 1.22.
the important change to note for this release is that mod_perl support is
incompatible with mod_perl versions 1.999_21 and earlier. in other words if
you are a mod_perl user only upgrade to this release if you a
William McKee wrote:
Hi Chris,
Thanks for the extensive testing and reports. It will help me debug the
next time I run into this situation. Unfortunately I'm not familiar
enough with the innards of A::T to be of any further help. If you want
to continue tracking, perhaps you could try running your
William McKee wrote:
On Thu, Mar 31, 2005 at 07:29:51PM -0500, Christopher H. Laco wrote:
Any ideas?
Chris,
I've seen this happen before. Please post your entire Build.PL script.
Even better, take Ken's bug-reporting skeleton[1] and create a
reproducible example that we can try.
Willia
William McKee wrote:
On Thu, Mar 31, 2005 at 07:29:51PM -0500, Christopher H. Laco wrote:
Any ideas?
Chris,
I've seen this happen before. Please post your entire Build.PL script.
Even better, take Ken's bug-reporting skeleton[1] and create a
reproducible example that we can try.
Willia
Christopher H. Laco wrote:
After I started a big crapstorm on perl-qa about META.yml and
Module::Build, I now have to take my lumps and start using it. :-)
Following the TestMB pod, I have a working Build.PL that also calls:
$build->generate_script('t/TEST');
$build->generate
After I started a big crapstorm on perl-qa about META.yml and
Module::Build, I now have to take my lumps and start using it. :-)
Following the TestMB pod, I have a working Build.PL that also calls:
$build->generate_script('t/TEST');
$build->generate_script('t/SMOKE');
'perl Build.PL' runs without
Geoffrey Young wrote:
make test successful and all existing modules using A-T ran without
problems under:
5.6.1/apache 1.3.33 win32
5.8.4/apache 1.3.33 win32
5.8.6/apache 1.3.33 FreeBSD 5.3-STABLE
5.8.6/apache 1.3.33 win32
5.6.1/apache 1.3.31 FreeBSD 4.11-STABLE
excellent, than
Christopher H. Laco wrote:
Geoffrey Young wrote:
a release candidate for Apache-Test 1.21 is now available.
http://cvs.apache.org/~geoff/Apache-Test-1.21-dev.tar.gz
please take the time to excercise the candidate through all your existing
applications that use Apache-Test and report back
Geoffrey Young wrote:
It would be nice to not even get that MakeMaker param warning.
it sounds like you're using an old MakeMaker version, which doesn't
understand some of the newer tags. I think that's probably ok.
It's never caused me problems in the past. I just like the idea of not
used the
Christopher H. Laco wrote:
It would be nice to not even get that MakeMaker param warning.
Also, make distclean does clean out t/cgi-bin/cookies.pl or t/REPORT. Is
that by design?
s/does/doesn't/
smime.p7s
Description: S/MIME Cryptographic Signature
Geoffrey Young wrote:
a release candidate for Apache-Test 1.21 is now available.
http://cvs.apache.org/~geoff/Apache-Test-1.21-dev.tar.gz
please take the time to excercise the candidate through all your existing
applications that use Apache-Test and report back successes or failures.
--Geoff
This
Geoffrey Young wrote:
a release candidate for Apache-Test 1.21 is now available.
http://cvs.apache.org/~geoff/Apache-Test-1.21-dev.tar.gz
please take the time to excercise the candidate through all your existing
applications that use Apache-Test and report back successes or failures.
--Geoff
make
Geoffrey Young wrote:
a release candidate for Apache-Test 1.21 is now available.
http://cvs.apache.org/~geoff/Apache-Test-1.21-dev.tar.gz
I'm unable to download. I've tried at work and at home without success.
I just get a connection timeout error.
C:\Documents and Settings\claco>nslookup cvs.a
Stas Bekman wrote:
try the latest svn / snapshot, it is fixed there.
Is there a workaround without requiring A-T 1.21 or loading an ancillary
module in the AxKit package like Apache::AxKit::Exception instead of AxKit?
Thanks,
-=Chris
smime.p7s
Description: S/MIME Cryptographic Signature
Stas Bekman wrote:
Christopher H. Laco wrote:
[...]
perl Makefile.PL chokes with:
C:\Development\CPAN\Handel>perl Makefile.PL
[ info] generating script t/TEST
"C:\Development\CPAN\Handel" is not exported by the lib module
Can't continue after import errors at
C:/Development
Christopher H. Laco wrote:
Christopher H. Laco wrote:
What confuses me is this. If I change eval 'use AxKit' to your example
of eval {require 'AxKit'}; ... all is well.
That's a partial lie...
eval {require 'AxKit'};
yields:
Can't locate AxKit in @INC
Christopher H. Laco wrote:
What confuses me is this. If I change eval 'use AxKit' to your example
of eval {require 'AxKit'}; ... all is well.
That's a partial lie...
eval {require 'AxKit'};
yields:
Can't locate AxKit in @INC (@INC contains: C:/Developme
Geoffrey Young wrote:
if (eval { require 'AxKit' }) {
Apache::TestRunPerl->new->run(@ARGV, '-defines', 'AXKIT');
}
else {
Apache::TestRunPerl->new->run(@ARGV);
}
HTH
--Geoff
OK, I found something strange that I so don't understand at all. Can
someone clue me in?
I tweaked the ex
Geoffrey Young wrote:
and so on. then use a custom TEST.PL file to specify your defines:
if (eval { require 'AxKit' }) {
Apache::TestRunPerl->new->run(@ARGV, '-defines', 'AXKIT');
}
else {
Apache::TestRunPerl->new->run(@ARGV);
}
HTH
--Geoff
It should also be possible to put this
Geoffrey Young wrote:
the easiest way to do this is to let A-T run _everything_, both apache- and
non-apache related things. this works for just about everything, as long as
you have _some_ apache setup around (and is the approach I use most of the
time now). if you want to skip over AxKit if it'
What's the best approach to creating a dynamic extra.conf.in?
Long story longer. When I wrote the A-T tests for a project I'm working
on, I simple didn't call generate_script() or setup A-T if AxKit wasn't
installed since that was the only thing I was testing under A-T.
Now that I've backed myse
63 matches
Mail list logo
