Re: Minor doc fix for Apache::TestRequest
Boris Zentner wrote:
Hi,
Am Dienstag 19 Oktober 2004 00:15 schrieb Stas Bekman:
Ops, sorry.
hard to explain in english, here is a example:
perl -we 'sub have_lwp {} my $redir = have_lwp ? [qw(GET HEAD POST)] :
1;'
% perl -we 'sub have_lwp {}; my $redir = have_lwp ? [qw(GET HEAD POST)] :
1;' Search pattern not terminated at -e line 1.
Hmm, I wonder where does it find a search pattern there
Perl thinks ? is the start of the ?PATTERN? operator. See perldoc perlop for
more on it. I never used it. And I'm amazed too.
Hmm, I wasn't even aware of the existance of this operator.
That sounds like a parser bug to me. Care to ping p5p about it? At least
this caveat needs to be documented in perl docs I believe (if it isn't
already).
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Fix: Apache::TestRequest::redirect_ok
David Wheeler wrote: On Oct 18, 2004, at 4:52 PM, Boris Zentner wrote: No, in that case I return $RedirectOK. I think that at least the return 0 if $request-method eq 'POST'; line is wrong, since I clearly have no chance to redirect a post request. I just left it that way because that the way it was when I started playing with it. It never made sense to me that there would be a difference in redirection between GET and POST requests. Ask Doug. ;-) Is it because you can't really do redirects on real POST requests? The body will get lost, isn't it? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: outdated docs ( testing.html )
Boris Zentner wrote: Hi, while browsing http://perl.apache.org/docs/general/testing/testing.html, I discovered that the page describe the have function. But the Changelog of A::T says the have function is removed in falvor of need. it wasn't removed, it was replaced by need. and the original behavior of have has changed not to push the skip reasons. Please feel free to improve the docs, but if you do, please post a patch against testing.pod (so one probably need to do s/have/need/ and mention have as something to use when one doesn't want the skip reason to be added). http://perl.apache.org/contribute/index.html Thanks Boris. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Fix: Apache::TestRequest::redirect_ok
David Wheeler wrote: On Oct 19, 2004, at 5:22 AM, Stas Bekman wrote: Is it because you can't really do redirects on real POST requests? The body will get lost, isn't it? No, we do them all the time in Bricolage. In which case, can you please review Boris' patch and commit it if you think it's good? As I haven't coded and haven't used much this feature, I'd rather let somebody who is more familiar with it do the decision. If it breaks something, we can always fix that later. And of course when changing something it's a good idea to add a new test which exercises that fix. Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Minor doc fix for Apache::TestRequest
Boris Zentner wrote: Hi, please include this fix in the next release of Apache::Test. Thanks Boris. And what's the error it is trying to fix? have_lwp is imported into the code, I can't see why there should be a problem. --- a/Apache-Test-1.14/lib/Apache/TestRequest.pmThu Sep 30 05:32:13 2004 +++ b/Apache-Test-1.14/lib/Apache/TestRequest.pmMon Oct 18 13:56:08 2004 @@ -758,7 +758,7 @@ if there is only one value and that value is not POST: # Always allow redirection. - my $redir = have_lwp ? [qw(GET HEAD POST)] : 1; + my $redir = have_lwp() ? [qw(GET HEAD POST)] : 1; Apache::TestRequest::user_agent(reset = 1, requests_redirectable = $redir); -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: time for Apache-Test 1.14?
Geoffrey Young wrote: hi all... unless mod_perl 1.99_17 is imminent I'd like to roll Apache-Test 1.14 - now that Devel::Cover works with mod_perl, 1.14 will be the first Apache-Test release that has the ability to take advantage of Devel::Cover without significant user modifications (namely due to the addition of -one-process and built-in support from TestMB). objections? If you don't want to wait for 1.99_17 go ahead, it shouldn't make much difference, other than you will probably have to release Apache-Test 1.15 if mp is released shortly thereafter even if there will be no changes to A-T after 1.14 release (since Apache-Test will care a higher version in the mp2 package on release). Actually it's not true, while _ is in the modperl version PAUSE won't index it, so I guess it's fine for now. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: time for Apache-Test 1.14?
Geoffrey Young wrote: Stas Bekman wrote: Geoffrey Young wrote: hi all... unless mod_perl 1.99_17 is imminent I'd like to roll Apache-Test 1.14 - now that Devel::Cover works with mod_perl, 1.14 will be the first Apache-Test release that has the ability to take advantage of Devel::Cover without significant user modifications (namely due to the addition of -one-process and built-in support from TestMB). objections? If you don't want to wait for 1.99_17 go ahead, it shouldn't make much difference, other than you will probably have to release Apache-Test 1.15 if mp is released shortly thereafter even if there will be no changes to A-T after 1.14 release (since Apache-Test will care a higher version in the mp2 package on release). right. which is why I was kinda asking about the next mp2 release. if you tell me it's going to be in the next week or so it probably makes sense to hold off. if it's going to (realistically) be longer than that it makes more sense to move forward. Can't promise anything, we are sort of ready to release _17 but there is a problem with a worker mpm. Depending on how quickly it's resolved, and assuming that no other problems will be found, it'll get released. So it's up to you, probably give it a few days and if you don't see the candidate by let's say this weekend, go ahead and release it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::Test and OpenBSD
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};
my $dversion = $self-dversion; #for .conf version conditionals
my $defines = $self-config_defines;
## the version of Apache distributed with OpenBSD will run
## chrooted unless given the '-u' flag
my $openbsd_flag = '';
if (`uname` eq OpenBSD\n $vars-{httpd} eq '/usr/sbin/httpd') {
$openbsd_flag = '-u';
}
$openbsd_flag -d $vars-{serverroot} -f $vars-{t_conf_file}
$dversion $defines;
}
...and run make test in an Apache-Test distribution that I unpack
myself, then it works fine. If I run make test in the directory that
CPANPLUS unpacks for me, I get this...
It's because your CPANPLUS shell is running under root and in the
directory that's accessible only under root, so
# make test
/usr/bin/perl -Iblib/arch -Iblib/lib t/TEST -clean
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT=
APACHE_TEST_USER= APACHE_TEST_APXS= /usr/bin/perl -Iblib/arch
-Iblib/lib t/TEST -bugreport -verbose=0
[warning] root mode: changing the files ownership to 'nobody' (32767:32767)
[warning] testing whether 'nobody' is able to -rwx
/var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t
/usr/bin/perl -Mlib=lib -MApache::TestRun -e 'eval {
Apache::TestRun::run_root_fs_test(32767, 32767,
q[/var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t]) }';
[warning] result: OK
[warning] the client side drops 'root' permissions and becomes 'nobody'
/usr/sbin/httpd -u -d /var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t
-f /var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t/conf/httpd.conf -D
APACHE1
What are the permissions on this directory?
% ls -l /var/perl/cpanplus/5.8.2/build/Apache-Test-1.13
using Apache/1.3.29
*** About to run command from start: /usr/sbin/httpd -u -d
/var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t -f
/var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t/conf/httpd.conf -D
APACHE1
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 0 secs)
server localhost.ropine.com:8529 started
t/bad_codingok
t/ping..NOK 3# Failed test 3 in t/ping.t at line 16
t/ping..FAILED test 3
Failed 1/3 tests, 66.67% okay
t/redirect..NOK 4# Failed test 4 in t/redirect.t at line 17
t/redirect..NOK 6# Failed test 6 in t/redirect.t at line 23
t/redirect..FAILED tests 4, 6
Failed 2/6 tests, 66.67% okay
t/request...NOK 1# Failed test 1 in t/request.t at line 11
t/request...NOK 5# Failed test 5 in t/request.t at line 16
t/request...NOK 8# Failed test 8 in t/request.t at line 20
t/request...NOK 9# Failed test 9 in t/request.t at line 22
t/request...FAILED tests 1, 5, 8-9
Failed 4/9 tests, 55.56% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/ping.t31 33.33% 3
t/redirect.t62 33.33% 4 6
t/request.t 94 44.44% 1 5 8-9
Failed 3/4 test scripts, 25.00% okay. 7/19 subtests failed, 63.16% okay.
[ error] error running tests (please examine t/logs/error_log)
+-+
| To report problems please refer to the SUPPORT file |
+-+
*** Error code 1
Stop in /var/perl/cpanplus/5.8.2/build/Apache-Test-1.13 (line 831 of
Makefile).
# cat t/logs/error_log
[Mon Sep 27 12:55:47 2004] [notice] Initializing etag from
/var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t/logs/etag-state
[Mon Sep 27 12:55:47 2004] [crit] (1)Operation not permitted: could not
chown /var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t/logs/etag-state
If I try running the test under GDB, I get this...
There is no need to run it under GDB. Instead you need send the verbose
output of the test suite, which is:
t/TEST -verbose
Thanks.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Workaround (maybe) for getting Apache::Test 1.13 tested on a stock OpenBSD system
Seth Gordon wrote: There was a message sent to this list on June 29, reporting that Apache::Test failed make test on an i386 OpenBSD 3.5 machine. I got the same result on a G4 running OpenBSD 3.5. The error log is: [quote] # cat t/logs/error_log [Fri Sep 24 12:56:40 2004] [notice] Initializing etag from /var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t/logs/etag-state [Fri Sep 24 12:56:40 2004] [crit] (1)Operation not permitted: could not chown /var/perl/cpanplus/5.8.2/build/Apache-Test-1.13/t/logs/etag-state [unquote] The version of Apache that is distributed with OpenBSD will chroot to the ServerRoot by default. To run httpd in unsecure mode, you need to pass it the -u command-line switch. I suspected that Apache::Test was failing because it didn't pass that switch on to Apache, so I tried creating a /usr/sbin/httpdu file, with the same ownership and permissions as /usr/sbin/httpd, that said this: [quote] #!/bin/sh exec /usr/sbin/httpd -u $@ [unquote] When I unpack the tarball by hand, set APACHE_TEST_HTTPD=/usr/sbin/httpdu, and run perl Makefile.PL; make; make test, everything passes. This is true whether or not I am executing the commands as root. How can we programmatically figure out when to add the -u flag? If we can't then we can add APACHE_TEST_HTTPD_OPTIONS env var, which you can set to -u. But when I try installing the module through the CPANPLUS shell with the same environment variable setting, I get this: [quote] waiting 60 seconds for server to start: . waiting 60 seconds for server to start: ok (waited 0 secs) server localhost.ropine.com:8529 started still waiting for server to warm up: . the server is down, giving up after 61 secs +-+ | To report problems please refer to the SUPPORT file | +-+ [ error] failed to start server! (please examine t/logs/error_log) *** Error code 1 [unquote] ...with nothing appended to t/logs/error_log that might indicate the source of this problem. Try to run the program under strace or its equivalent, ans see what's going wrong. I'm not sure whether or not the modules that depend on Apache::Test for their own testing will still be able to run with this workaround. Even if they can, I would appreciate a patch that will allow Apache::Test to insert the -u option when it starts up the server, so I don't have to rely on this weirdness. (Or is there some easier solution to the problem that I missed?) You are the first one to ever mention this problem, so please help us to solve it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: -one-process configuration option
Geoffrey Young wrote: Stas Bekman wrote: + save no-httpd one-process); may be it's better to use _ instead of - in the option names, so one doesn't need to quote them in the code. -no_httpd, -one_process. It's especially nice for -one_process, since it's the same as -DONE_PROCESS. Consistency is good :) drat, I didn't read this in time. sorry. I suppose we can do that, but it would mean changing all of these: -no-httpd run the tests without configuring or starting httpd -one-process run the server in single process mode -run-tests run the tests -start-httpd start the test server -stop-httpdstop the test server while -no-httpd isn't that big of a deal since it's new, -run-tests, -start-httpd, and -stop-httpd might be a bigger issue. well, issue is kinda strong, but you get the idea... ah, I forgot that we had others as well. So never mind. odd that legacy TestConfig arguments all have underscores, while TestRun arguments have dashes. maybe it's to remind you that TestConfig uses -apxs /foo/apxs (no equals) while TestRun uses -debug=ddd (equals). yet another fine example of consistency in this codebase ;) Consistency above all :) p.s. that config vs run options syntax difference is certainly confusing -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: -one-process configuration option
Geoffrey Young wrote:
hi all...
I've found it necessary to toggle single server mode when using Apache-Test,
specifically for getting Devel::Cover to work with mod_perl 1.0 nicely. so,
I'd like to add an option for switching back to single server mode on demand
for a normal run.
the problem is that TestServer, which controls how the server is started,
does not have access to TestRun parsed configuration options. TestServer
has access to TestConfig options, but all of those take arguments and
persist until the next time you run -clean, which isn't desirable.
we've run into this issue before, wanting to give TestServer access to
per-run directives, but we never really had a decent solution. this one
just adds an Apache::TestRun object to the Apache::TestServer hash at the
appropriate times, which TestServer can then use if it so chooses. other
solutions welcome.
+1, with the style fix below:
Index: Apache/TestServer.pm
+my $one_process = $self-{run}-{opts}-{'one-process'} ?
+ $self-version_of(\%one_process) :
+ '';
should be:
my $one_process = $self-{run}-{opts}-{'one-process'}
? $self-version_of(\%one_process)
: '';
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: -one-process configuration option
+ save no-httpd one-process); may be it's better to use _ instead of - in the option names, so one doesn't need to quote them in the code. -no_httpd, -one_process. It's especially nice for -one_process, since it's the same as -DONE_PROCESS. Consistency is good :) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
[EMAIL PROTECTED] wrote: gozer 2004/09/16 14:36:13 Modified:perl-framework/Apache-Test Changes perl-framework/Apache-Test/lib/Apache TestConfig.pm Log: Added an apxs query cache for improved test performance It doesn't seem to make any difference for me. I'm not sure why it made such a significant difference on your machine. Perhaps your apxs util is for some reason is too slow. % time perl -le 'qx[~/httpd/prefork/bin/apxs -q CFLAGS] for 1..30' 3.411u 1.786s 0:05.35 97.0% 0+0k 0+0io 0pf+0w -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: run_tests and test_clean
Geoffrey Young wrote: hi all... in TestMM.pm we have this: test_clean : ... run_tests : test_clean ... test :: pure_all run_tests test_clean in a test suite with *lots* of files, test_clean takes forever. however, I experience has shown me that test_clean is only really required when you make changes to a configuration file or have autogenerated files you want to regenerate, making it a waste common development circumstances where a single test file is run over and over again. I'd like to suggest that test_clean _not_ be a prerequisite for run_tests, but instead shuffle the 'test' target around a bit. with the attached patch, you can save *lots* of cycles by doing something similar to the following: $ make test TEST_FILES=t/foo.t $ make run_tests TEST_FILES=t/foo.t $ make run_tests TEST_FILES=t/foo.t ... in my current situation, the first (with t/TEST -clean) runs in 45 seconds, while the second (and subsequent) iteration runs in 29 seconds. definitely a plus for me :) Are you sure that there will be no side effects? If yes, then +1 Why not just run t/TEST directly instead of using make? I never use make when developing tests. So it was never an issue for me. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: run_tests and test_clean
Geoffrey Young wrote: Are you sure that there will be no side effects? I'm pretty sure. it's not like test_clean won't be called under normal 'make test' circumstances, it's just that now there would be a way around it if the user thinks it is beneficial. Oh, now I remember where it was used. In the httpd-dev test suite: 'make test' was always nuking .so files and ssl stuff, which was a pain in an arse. But I don't know why Doug programmed it this way. It wasn't us who introduced that change. If yes, then +1 ok, cool. if things blow up then I'll revert it, but I'm not seeing any problems on my end. sure Why not just run t/TEST directly instead of using make? I never use make when developing tests. So it was never an issue for me. t/TEST works fine for smallish things, but make is nice for automatically computing and including library directories spread out all over the place. +1 -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Patch] Caching apxs queries
Philippe M. Chiasson wrote: I had been investigating into ways to make test runs run faster, and I found that one of the biggest bottlenecks on my test machine was useless repetitive calls to apxs. The following patch caches apxs queries. For instance, timings for mod_perl test run: + Before: Files=218, Tests=2512, 1032 wallclock secs (594.94 cusr + 431.33 csys = 1026.27 CPU) + After: Files=218, Tests=2512, 246 wallclock secs (196.69 cusr + 33.55 csys = 230.24 CPU) gozer++, +1 -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test Changes
Geoffrey Young wrote:
[EMAIL PROTECTED] wrote:
stas2004/08/26 17:51:55
Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
perl-framework/Apache-Test Changes
Log:
Make sure that when Apache-Test is a part of modperl-2.0 checkout, the
interactive configuration is properly run (it must not be run when
mod_perl 2.0 is tested since it should have all the info needed to run
the tests).
-use constant IS_MOD_PERL_2_BUILD = IS_MOD_PERL_2
-require Apache::Build Apache::Build::IS_MOD_PERL_BUILD();
-
use constant IS_APACHE_TEST_BUILD =
grep { -e $_/lib/Apache/TestConfig.pm } qw(Apache-Test . ..);
+use constant IS_MOD_PERL_2_BUILD =
+IS_MOD_PERL_2 !IS_APACHE_TEST_BUILD
+require Apache::Build Apache::Build::IS_MOD_PERL_BUILD();
+
this borked the mod_perl build. IS_APACHE_TEST_BUILD now reports back true
for a mod_perl checkout, which makes IS_MOD_PERL_2_BUILD false. the result
is that Apache2.pm is added to t/TEST but lib/ is not, so t/TEST can't run
on a fresh checkout (where there are no mod_perl files in site_lib).
I think the attached patch makes more sense, but I'm not sure if it collides
with the problem you were trying to solve.
--Geoff
Index: Apache-Test/lib/Apache/TestConfig.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.243
diff -u -r1.243 TestConfig.pm
--- Apache-Test/lib/Apache/TestConfig.pm 27 Aug 2004 01:03:55 - 1.243
+++ Apache-Test/lib/Apache/TestConfig.pm 3 Sep 2004 14:23:24 -
@@ -31,7 +31,7 @@
eval { require mod_perl $mod_perl::VERSION = 1.99 } || 0;
use constant IS_APACHE_TEST_BUILD =
-grep { -e $_/lib/Apache/TestConfig.pm } qw(Apache-Test . ..);
+grep { -e $_/lib/Apache/TestConfig.pm } qw(. ..);
use constant IS_MOD_PERL_2_BUILD =
IS_MOD_PERL_2 !IS_APACHE_TEST_BUILD
thanks Geoff for the heads up, I think I've found a more suitable solution
for this. One shouldn't run 'perl Makefile.PL' from within Apache-Test/
when that is a checkout inside modperl-2.0. I have been bitten by that
quite a few times, as there are many bad sideeffects when
Apache-Test/t/conf is populated (it gets picked up by modperl tests then
causing all kind breakages).
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test 1.13
William McKee wrote: On Fri, Aug 20, 2004 at 01:56:05PM -0700, Stas Bekman wrote: So all the problems you have reported before are now resolved, William? I knew you were going to ask me that g! It's not necessarily the case. I did not do a complete test under Windows using my test suite; I just ran the basic tests that come with A::T. I'll try to get to that over the weekend and let you know. Sure. Take your time, William. I think at least the problem of the endless interactive config loop has been solved now. Yes, I'm not seeing that behavior (although I might be specifying the httpd path by habit when I run `perl Makefile.PL`). OK, I tested the new release with my full test suite and am still getting Statement unlikely to be reached failures in TestRun.pm at lines 643 and 747. I'm simply patching this file which works for my needs. It seems this is a perl issue under Win32; I'm still running 5.8.3 on that platform. Well, I tried to fix it some time ago, but w/o being able to reproduce it I wasn't very successful. If you have ideas to what could be the problem, please let us know/send a patch. It's interesting that no other win32 user has complained about this. Randy, have you possibly seen this? The original William's report can be found here: http://marc.theaimsgroup.com/?t=10789562352r=1w=2 -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test 1.13
William McKee wrote: On Thu, Aug 19, 2004 at 12:17:37PM -0700, Stas Bekman wrote: You can download the release candidate from here: http://www.apache.org/~stas/Apache-Test-1.13-dev.tar.gz If there are no problems reported Apache-Test 1.13 will be released tomorrow. It's working fine for me under both Linux and Windows. Thanks! So all the problems you have reported before are now resolved, William? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test 1.13
William McKee wrote: On Fri, Aug 20, 2004 at 11:08:33AM -0700, Stas Bekman wrote: It's working fine for me under both Linux and Windows. Thanks! So all the problems you have reported before are now resolved, William? I knew you were going to ask me that g! It's not necessarily the case. I did not do a complete test under Windows using my test suite; I just ran the basic tests that come with A::T. I'll try to get to that over the weekend and let you know. Sure. Take your time, William. I think at least the problem of the endless interactive config loop has been solved now. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: shell_ready function
Geoffrey Young wrote:
Joe Orton wrote:
Does the quote escaping really work in this function?
hmm, it doesn't look like it does. I think this was part of some work that
stas and ken were doing, though, and IIRC it was some win32 command line
thing. but I could be wrong.
It confuses emacs
font-lock mode which doesn't see a closing quote so thinks the rest of
the file is part of the string. This fixes at least the latter:
-$arg =~ s//\/g;
+$arg =~ s//\\/g;
that looks better, but I'm not sure it's right either - if the input is
already escaped then you've (both) over-quoted (if the first worked at all,
that is :) so, you look to be fine here if pre-quoted input is forbidden or
not expected, but not so if it's already quoted, in which case something
like this is better:
$arg =~ s!([^\\])!$1\\!g;
the attached script runs through a few different regex and input
combinations for visual inspection. hopefully that will help sort this
issue out a bit (or the original author will clear things up ;)
Yeah, I guess it's the best to ask Ken, it worked for him.
Jon's looks better, and Geoff's is even better,
I've checked CPAN and found
http://search.cpan.org/src/ROSCH/String-ShellQuote-1.00/ShellQuote.pm
but it probably is not what you are after, right?
Either way +1 to Geoff's version.
and here is the optimized version of Geoff's one:
sub shell_ready_stas {
my $arg = shift;
$arg =~ s!\\?!\\!g;
return qq[$arg];
}
:)
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Joe Orton wrote:
On Tue, Aug 10, 2004 at 09:56:12AM -0700, Stas Bekman wrote:
Aha! Excellent, Geoff! Does it solve the problem by moving those
default_module calls after getting httpd config?
Moving the calls one line further on fixed it for me. OK to check in?
(BTW your patch had whitespace issues and only applied with patch -l)
Index: Apache-Test/lib/Apache/TestConfig.pm
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestConfig.pm,v
retrieving revision 1.235
diff -u -r1.235 TestConfig.pm
--- Apache-Test/lib/Apache/TestConfig.pm 9 Aug 2004 06:19:15 - 1.235
+++ Apache-Test/lib/Apache/TestConfig.pm 10 Aug 2004 21:12:59 -
@@ -313,13 +313,6 @@
$vars-{proxyssl_url} ||= '';
$vars-{defines} ||= '';
-$self-default_module(cgi= [qw(mod_cgi mod_cgid)]);
-$self-default_module(thread = [qw(worker threaded)]);
-$self-default_module(ssl= [qw(mod_ssl)]);
-$self-default_module(access = [qw(mod_access mod_authz_host)]);
-$self-default_module(auth = [qw(mod_auth mod_auth_basic)]);
-$self-default_module(php= [qw(mod_php4 mod_php5)]);
-
$self-{hostport} = $self-hostport;
$self-{server} = $self-new_test_server;
@@ -359,6 +352,14 @@
}
$self-inherit_config; #see TestConfigParse.pm
+
+$self-default_module(cgi= [qw(mod_cgi mod_cgid)]);
+$self-default_module(thread = [qw(worker threaded)]);
+$self-default_module(ssl= [qw(mod_ssl)]);
+$self-default_module(access = [qw(mod_access mod_authz_host)]);
+$self-default_module(auth = [qw(mod_auth mod_auth_basic)]);
+$self-default_module(php= [qw(mod_php4 mod_php5)]);
+
$self-configure_httpd_eapi; #must come after inherit_config
$self-{server}-post_config;
I'd rather see it moved two statements (it still works, doesn't it?) so
the eapi comes right after inherit_config. Otherwise, yes, please commit it.
so are we all clean now? Any other problems?
As a result of my changes, now the API has two wrappers
Apache::Test::config (full config as before), and
Apache::Test::basic_config, which is the same sans httpd information.
For example to autogenerate t/TEST and other files you don't need to
know anything about httpd, and therefore you shouldn't require users to
supply that info before it's really needed. Until now things were
silently failing (to find httpd stuff), making it really hard to trace
some problems. Now things fail when something goes wrong, so this
separation was important.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: forcing full config in Makefile.PL (was Re: failing httpd-test tests)
Geoffrey Young wrote: As a result of my changes, now the API has two wrappers Apache::Test::config (full config as before), and Apache::Test::basic_config, which is the same sans httpd information. For example to autogenerate t/TEST and other files you don't need to know anything about httpd, and therefore you shouldn't require users to supply that info before it's really needed. one of the things I've tried to do but was never able to get working was call have_apache within Makefile.PL. being able to do this would be a nice way to add a PREREQ_PM-type precondition for building modules that rely on, say, httpd 2.1. as a user it doesn't quite make sense why this wouldn't work - Makefile.PL is getting passed -apxs or -httpd, so you would think that after the call to filter_args the httpd version would be known. being able to support something like this, whether automatically or on command would be really great. that is, forcing a full configuration before calling WriteMakefile so that all the standard Apache::Test functions are available. Sure, just call Apache::Test::config and voila you have the full config in Makefile.PL. Don't forget that at the moment 99.9% of users will not have that provision of httpd/apxs during Makefile.PL, so you will want to check whether it's provided (and that's not bogus). Otherwise asking for a full config with no httpd/apxs provision will trigger interactive config at the Makefile.PL level, which doesn't sound good at all for the general case. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Joe Orton wrote: On Wed, Aug 11, 2004 at 01:17:04AM -0700, Stas Bekman wrote: I'd rather see it moved two statements (it still works, doesn't it?) so the eapi comes right after inherit_config. Otherwise, yes, please commit it. Yes, great, done. so are we all clean now? Any other problems? No failures with HEAD again now - thanks a lot. Excellent. Thanks Joe! -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Geoffrey Young wrote: But things are getting more and more fragile and dependant on each other indeed. right now a fresh checkout will not even run for me because I don't have an ssl-enabled apache to run against. this is not a minor issue, as I suspect I'm in the majority for normal users. Agreed. I'll try to reproduce it and resolve it. Sorry for the breakage. making the code less and less maintainable. exactly - I'm kind of at a loss for what exactly to do here to fix it. you made a few suggestions, but I really don't know what's best - between the sticky configuration stuff (that I still don't care for) and the new configuration breakdown I'm pretty much lost at the moment. We need to rethink how the things are configured in A-T, I think it all used to be just fine. well, maybe not fine but maintainable to a certain degree. then we started adding magic things like sticky preferences and the ability to move the test directory around and things got considerably more complex. Well, those things aren't magical, they were just solutions to the existing (some pretty bad) problems. I've a way too many other things to do, to just go and break Apache-Test for fun. write some sort of test suite to cover what's working, then completely rewrite the configuration process from scratch, making sure that things are still working. ideally, sure. I just can't think of how to do that. Do what? The test suite? I think this is the first step. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Stas Bekman wrote: Geoffrey Young wrote: But things are getting more and more fragile and dependant on each other indeed. right now a fresh checkout will not even run for me because I don't have an ssl-enabled apache to run against. this is not a minor issue, as I suspect I'm in the majority for normal users. Agreed. I'll try to reproduce it and resolve it. Sorry for the breakage. Oh, yeah, I got it right away when trying to build mp2. Looking at it. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache Test.pm TestConfig.pm TestRun.pm
[EMAIL PROTECTED] wrote: stas2004/08/08 23:19:16 Modified:perl-framework/Apache-Test/lib/Apache Test.pm TestConfig.pm TestRun.pm Log: another round of fixes of fixes We are definitely not ready for the planned release. My recent attempts to fix a fatal configuration bug affecting end users, have unstabilized things, as I have shuffled some of the execution sequences, and w/o tests I couldn't do through testing. So I discover problem as I deply A-T in various context. I hope it'll be back to stable soonish. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Geoffrey Young wrote:
Joe Orton wrote:
There is something funky in the default_module detection; it's picking
up mod_auth.c and mod_access.c as the {auth,access}_module settings
rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0.
$ grep access_ conf/apache_test_config.pm
'access_module_name' = 'mod_access',
'access_module' = 'mod_access.c
that the failures I'm seeing here.
any ideas?
I'm not sure if that's something stas touched or not.
I think not, but I'm not 100% sure. All I did is split the A-T
configuration process in 2 parts, postponing the httpd-specific
information finding to a later stage.
helpful information at this point would be some of the verbose output from
the module selection reports using 'export APACHE_TEST_TRACE_LEVEL=debug'
when running t/TEST -conf.
it's simpler with: t/TEST -conf -trace=debug :)
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: failing httpd-test tests
Joe Orton wrote:
There is something funky in the default_module detection; it's picking
up mod_auth.c and mod_access.c as the {auth,access}_module settings
rather than mod_auth_basic.c and mod_authz_host.c as expected with 2.0.
$ grep access_ conf/apache_test_config.pm
'access_module_name' = 'mod_access',
'access_module' = 'mod_access.c
that the failures I'm seeing here.
./TEST -debug seems to have stopper working sometime too
$ ./TEST -debug
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl /tmp/regressPPKikg/pf/t/TEST -debug
[warning] server localhost.localdomain:8529 shutdown
Use of uninitialized value in concatenation (.) or string at
Apache-Test/lib/Apache/TestServer.pm line 130.
any ideas?
Indeed. I've committed the fix.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
failing httpd-test tests
Do you also get these tests failing with the current httpd-2.0? Failed Test Stat Wstat Total Fail Failed List of Failed --- t/apache/limits.t 102 20.00% 7 9 t/ssl/basicauth.t32 66.67% 2-3 t/ssl/env.t 28 14 50.00% 15-28 t/ssl/proxy.t 169 116 68.64% 1-58 112-169 t/ssl/require.t 52 40.00% 2 5 t/ssl/varlookup.t 72 72 100.00% 1-72 t/ssl/verify.t 31 33.33% 2 It's hard to know whether my recent changes in Apache-Test didn't break things, when so many tests fail (they were failing before my changes). -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm TestRun.pm TestServer.pm
[EMAIL PROTECTED] wrote: stas2004/08/06 11:20:42 Modified:perl-framework/Apache-Test Changes Makefile.PL perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm TestRun.pm TestServer.pm Log: move the custom config code into Apache::TestConfig, split the config object creation in 2 parts - first not requiring the knowledge of httpd location, the second requiring one, refactor the custom config interactive prompting into the second phase, if failed to find httpd. Reshuffle the code to run first bits not requiring the knowledge of httpd location. I had to do some re-shuffling to change the timing of the httpd detection, as a few things were broken. I hope I didn't break anything. Please do extensive testing. Thanks. (I wish there was a test suite for Apache-Test itself, not the internal tests, but the configuration tests) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
expected/received swap?
mp2 had its t_cmp args adjusted, but not httpd-test. So we get this confusing: # expected: 500 Not a SCALAR reference # received: 102400 any takers on swapping the args of t_cmp to comply with recent A-T changes? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: libwww-perl 5.800 failures
Geoffrey Young wrote:
hi all...
I just upgraded to libwww-perl 5.800 and found that a few POST tests started
failing where they didn't before, namely t/apache/post.t and t/http11/post.t.
I think the underlying problem is this change in HTTP::Message:
HTTP::Message will now allow an external 'content_ref'
to be set. This can for instance be used to let HTTP::Request
objects pick up content data from some scalar variable without
having to copy it.
which I think means that you can no longer set
my $content = sub {...};
$request-content($content);
as we do in Apache::TestCommonPost::lwp_do(). I didn't write that code and
am having a hard time following it, but I assume that the coderef assumed
LWP would call the coderef until the C-L was fulfilled, which seems to no
longer be true.
so, if anyone is familiar with how TestCommonPost works and what it is
testing, it would be really helpful if you could explain why the buffering
in lwp_do is required and why we can't just set $response-content to the
C-L size up front.
What lwp_do was trying to do is to avoid the copying of 10MB strings
between the A-T code and LWP, feeding LWP in chunks. I suppose that
5.800 dropped that functionality, but since it made content_ref
settable, I've used that as a workaround.
Now, that was definitely not a showstopper, since it seems like
everything in TestCommon* is really httpd-test specific. Or do you think
it can be reused anywhere else? If not, may be we should drop all that
code from Apache-Test and move it into perl-framework/t/lib?
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Test::More server support redux
= qw(all);
+
+use Apache::TestRequest 'GET_BODY_ASSERT';
+print GET_BODY_ASSERT /TestMore__testmorepm;
+
--- /dev/null 2003-09-15 06:40:47.0 -0700
+++ t/more/03testpm.t 2004-08-05 07:17:31.0 -0700
@@ -0,0 +1,8 @@
+# see the description in t/more/all.t
+
+use strict;
+use warnings FATAL = qw(all);
+
+use Apache::TestRequest 'GET_BODY_ASSERT';
+print GET_BODY_ASSERT /TestMore__testpm;
+
--- /dev/null 2003-09-15 06:40:47.0 -0700
+++ t/more/04testmore.t 2004-08-05 07:17:35.0 -0700
@@ -0,0 +1,8 @@
+# see the description in t/more/all.t
+
+use strict;
+use warnings FATAL = qw(all);
+
+use Apache::TestRequest 'GET_BODY_ASSERT';
+print GET_BODY_ASSERT /TestMore__testmorepm;
hmm, what are you trying to achieve with repeating two tests twice? what
if you don't hit the same interpreter if that's what you are after? It's
probably better to use 1 test and run the same_interprter framework?
--- /dev/null 2003-09-15 06:40:47.0 -0700
+++ t/response/TestMore/testmorepm.pm 2004-08-05 06:43:16.0 -0700
@@ -0,0 +1,21 @@
+package TestMore::testmorepm;
+
+use strict;
+use warnings FATAL = qw(all);
+
+use Test::More;
+use Apache::Test qw(-withtestmore);
+
+sub handler {
+
+ plan shift, tests = 2;
+
+ is (1, 1, 'called Test::More::is()');
+
+ like ('wow', qr/wow/, 'called Test::More::like()');
+
+ 0;
What's 0? Should it be Apache::OK?
+}
+
+1;
--- /dev/null 2003-09-15 06:40:47.0 -0700
+++ t/response/TestMore/testpm.pm 2004-08-05 06:40:14.0 -0700
@@ -0,0 +1,18 @@
+package TestMore::testpm;
+
+use strict;
+use warnings FATAL = qw(all);
+
+use Apache::Test;
+use Apache::TestUtil;
+
+sub handler {
+
+ plan shift, tests = 1;
+
+ ok t_cmp(1, 1, 'called Apache::Test::ok()');
+
+ 0;
ditto
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Test::More server support redux
Geoffrey Young wrote:
+Note that ITest::Builder 0.18_01, available in ITest::Simple
+version 0.48_01 on CPAN, is required to use this feature.
drop that, as 2 copies of the same thing in different places will go out
of sync at some point. check on the code level should be sufficient.
instead the error message could say where to find the required version.
well, maybe it's not clear - colloquially most people I've talked to refer
to Test::More. but Test::More isn't a distribution, it's part of
Test::Simple (as is Test::Builder).
anyway, I'll know more about the module versions when Test::Simple 0.49 is
released - if all the versions of the underlying packages are correct I'll
just require 0.49 and be done with it.
sure, all I'm saying is that move that explanation into the error
message if the version is not satisfied (eval it to trap it :)
-my $lib = catfile Apache::Test::vars('top_dir'), qw(Apache-Test
lib);
-my $cmd = qq[$^X -Mlib=$lib $file];
+# so we can find Apache/Test.pm from both the perl-framework
+# and Apache-Test. note that IS_APACHE_TEST_BUILD returns
+# true for the perl-framework as well
+my $lib = join ':',
+catfile(Apache::Test::vars('top_dir'), qw(Apache-Test lib)),
+catfile(Apache::Test::vars('top_dir'), 'lib');
+my $cmd = qq[PERL5LIB=$lib $^X $file];
why this change? is there anything wrong with -Mlib?
yes. the problem is that currently all.t does not get run properly from
Apache-Test/. the current code adds makes @INC look like
perl-framework/Apache-Test/Apache-Test/lib when running from the A-T directory.
right, so the solution is to expand it to the full path as everywhere
else. Don't rely on relative paths.
PERL5LIB will be
ignored under -T -- code will be broken.
yes, but it shouldn't be a problem, since $lib is only important if A-T
can't be found, which is presumably only when running from the
perl-framework/ or Apache-Test/ directories. which is why I have my comment
that IS_APACHE_TEST_BUILD is insufficient to determine whether it is a real
A-T build or someone running from the perl-framework.
still, let's not pollute things with env vars. remember that they affect
other things indirectly. using a full path will do the trick.
+
+IfModule mod_perl.c
+ IfDefine APACHE2
+PerlModule Apache2
+ /IfDefine
why not put the stuff below into extra.last.conf.in. Apache2 will be
loaded by then. It's better not to mess with Apache2 before times.
because unless I use TestRunPerl (over TestRun) nothing mod_perl will be set
up, including Apache2. so it's not a matter of timing, but rather if
Apache2 is loaded at all.
ah, ok, may be add a comment then, so the question doesn't raise again
(the fact that you use TestRun).
+use Apache::TestRequest 'GET_BODY_ASSERT';
+print GET_BODY_ASSERT /TestMore__testmorepm;
hmm, what are you trying to achieve with repeating two tests twice? what
if you don't hit the same interpreter if that's what you are after?
the reason they are run twice (and in alternating Test.pm and Test::More
order) is that when I first coded it there was a bug in that Test::More
would never release itself from the tests due to some global variables.
0.49 addresses this with an official API for persistent environments, which
I can now call (and is why we can't use any earlier versions).
so, yes, I suppose it is an interpreter issue.
It's probably better to use 1 test and run the same_interprter framework?
well, the multiple test calls are to make sure that users can intermix
Test.pm and Test::More plans on the server, so I clearly want multiple tests
and not just one if I'm going to mimic user activity. but I'll look into
using same_interpreter to make sure that threaded mpms work properly as well.
I understood that. The problem is that your tests are very fragile,
since if they don't hit the same interpreter they are useless ;)
Unfortunately the same_interpreter framework works inside the same
client. I'm not sure how to extend it to work across several clients.
+ 0;
What's 0? Should it be Apache::OK?
sure.
you want it to run under mp1 and mp2, right? so this should do the trick:
BEGIN {
require mod_perl;
if ($mod_perl::VERSION = 1.99) {
require Apache::Const;
Apache::Const-import('OK');
}
else {
require Apache::Constants;
Apache::Constants-import('OK');
}
}
...
return OK;
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Test::More server support redux
Geoffrey Young wrote:
why this change? is there anything wrong with -Mlib?
yes. the problem is that currently all.t does not get run properly from
Apache-Test/. the current code adds makes @INC look like
perl-framework/Apache-Test/Apache-Test/lib when running from the A-T
directory.
right, so the solution is to expand it to the full path as everywhere
else. Don't rely on relative paths.
the problem isn't relative versus absolute paths - vars{'top_dir'} is
already absolute. the problem is that top_dir is different when run from
perl-framework/ versus perl-framework/Apache-Test/ - so
perl-framework/t/php/all.t hits that code and all is well,
perl-framework/Apache-Test/t/more/all.t hits it and can't find the proper lib.
I thought there was some code I could use to resolve the issue for me (in
the I've moved t/ code) but I didn't see it.
Ah sorry, I've missed the Apache-Test/Apache-Test/ concat.
Still this is a run-time thingy, why can't you check at run time whether
a directory exists and pick the right one? Pushing both just in case,
doesn't sound right.
Me thinking that run_t simply wasn't adjusted to accomodate the change
of moving into t/ on the startup. See what I mean?
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] new need functions
Geoffrey Young wrote:
hi all
ok, attached is a patch that implements the new need variants and alters the
old have variants. basically, all I did was a global rename of have to
need, then implement the have routines in terms of need with the AutoLoader.
I thought this made a bit more sense than redefining all of those
subroutines again when the only difference was simply not populating
@SkipReasons.
the mod_perl test suite continues to run, as does the perl-framework, so
nothing (that I can see at least) should be broken.
anyway, comments welcome, as well as documentation - I couldn't decide where
to add the have stuff so I just didn't do anything.
I'd suggest to simply explain that there are have_ and need_ functions
at the beginning of that section that explains need_* ones. And one
should use need_* inside plan(), because of the skip messages. Otherwise
use have_*.
Please don't commit w/o the docs. Once it's committed, the docs are most
likely will be forgotten.
You don't want to remember to update two places when you add new
functions. So there should be a need* functions array and when you
populate the @EXPORT list you generate the have* list. Also there should
be no have() function, but only need(). The rest map need_* = have_*.
Next you can use that have* list to generate the actual functions on the
fly, similar to the generation of the subs similar to log levels subs in
Apache::TestTrace. So you don't really need AUTOLOAD. It'll take the
same amount of code w/o AUTOLOAD.
+sub AUTOLOAD {
+
+use vars qw($AUTOLOAD @SkipReasons);
haven't you declared the two at the top of Test.pm already?
+(my $method) = $AUTOLOAD =~ m/.*::(.*)/;
+
+return unless $method =~ m/^have/;
+
+$method =~ s/^have/need/;
+
+if (my $cv = Apache::Test-can($method)) {
+my @skip = @SkipReasons;
+my $rc = $cv-(@_);
+@SkipReasons = @skip;
+return $rc;
why not just:
local @SkipReasons;
return $cv-(@_);
+}
+else {
+die could not find function $AUTOLOAD;
+}
+}
+
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Infinite looping in self-configuration mode (was Re: [RELEASE CANDIDATE] Apache-Test-1.06)
Geoffrey Young wrote: OK, please let us know when and if you see it again. I see that there were quite a few changes since the last A-T release, any volunteers to wear the Release Manager cap and get a new version out? I'll do it, once the need_* functions have been implemented (which I'll do as well :) Thanks Geoff! -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm
[EMAIL PROTECTED] wrote: theory 2004/07/30 19:43:33 + # Always allow redirection. + my $redir = have_lwp ? [qw(GET HEAD POST)] : 1; + Apache::TestRequest::user_agent(reset = 1, + requests_redirectable = $redir); Using have_ macros for non-plan() usage should be avoided, since it populates the SKIP messages array and if later the test is skipped, for a different reason it'll misleadingly tell the user that LWP was also a requirement for that test (which quite possibly could be what we want). We need to fix that in general (since this issue is recurrent) and have a better way to handle requirements check+skip and only requirements check. Ideas? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm
Geoffrey Young wrote:
Using have_ macros for non-plan() usage should be avoided, since it
populates the SKIP messages array and if later the test is skipped, for
a different reason it'll misleadingly tell the user that LWP was also a
requirement for that test (which quite possibly could be what we want).
We need to fix that in general (since this issue is recurrent) and have
a better way to handle requirements check+skip and only requirements
check. Ideas?
have_foo('bar', 1); # don't populate @SkipReason
or
check_foo('bar');# same as have_foo but don't populate @SkipReason
or a combination of both (where check_foo() is a wrapper around
have_foo($a,1) and we keep the interface undocumented).
I'm in favor of having two distinct base names in order to keep things
intuitive -- it's hard to remember what the extra argument in
have_foo('bar', 1) means: should 1 add skip messages, or should it not...
My suggestion for the names selection:
have_foo # don't populate @SkipReason
need_foo # populate @SkipReason
so, have_foo is intuitive to be used anywhere in the code, and plan now
will look like:
plan tests = 5, need_lwp, need_cgi, need_php;
or call it require_foo, or want_foo, or desire_foo, etc...
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestRequest.pm
David Wheeler wrote: On Jul 31, 2004, at 1:14 AM, Stas Bekman wrote: so, have_foo is intuitive to be used anywhere in the code, and plan now will look like: plan tests = 5, need_lwp, need_cgi, need_php; I like this, but isn't it putting the onus of change on module owners and introducing the likelihood of unexpected test failures when module owners don't realize that they need to change their Cuse lines from have_* to need_*? Perhaps we leave have_* with its current semantics, but then add got_* for the new semantics to be used anywhere in the code: # Always allow redirection. my $redir = got_lwp ? [qw(GET HEAD POST)] : 1; Apache::TestRequest::user_agent(reset = 1, requests_redirectable = $redir); to me, got and have are exactly the same thing. How are you going to remember which one to use when? Authors of the existing tests don't have to change anything, have_foo will work just the same, but won't add the skip reason anymore. This won't make affect the existing tests in any way, rather than not printing the reason for a tests being skipped. But, yes, the transition could be made 100% perfect, by keeping have_ as it is, and adding a new interface which doesn't add the skip reason. But we need to find an unambiguous name for it. skip_foo will be good, but we have a general function have(), which can't be replaced with skip(). So may be want_foo() is a better choice. Or may be you have a better name... -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cookie_jar ignored with requests_redirectable = 1
David Wheeler wrote: [...] So does passing the array reference actually affect the way the LWP user agent object operates? If so, that's cool, but it's undocumented. I'm not sure whether it should be documented, though, since if LWP isn't installed it certainly won't work with the simple request interface that Apache::TestRequest uses in its place. if you want to rely on LWP-specific features, you always need to have: plan tests = $tests, have_lwp; in your client tests. So the documentation should mention that requirement. Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cookie_jar ignored with requests_redirectable = 1
Stas Bekman wrote: David? Boris Zentner wrote: We are all at the OSCon at the moment, so we hardly get a chance to sleep. I suppose David will follow up soonish :) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cookie_jar ignored with requests_redirectable = 1
David?
Boris Zentner wrote:
Hi,
recently I try to use Apache::Test with HTTP::Cookies. But it did not work as
expected. I suppose the way to add a cookie_jar to A::T was with
'Apache::TestRequest::user_agent'. I read the docs from
Apache::TestRequest::user_agent. Here is the relevant part of it.
And finally, the semantics of the requests_redirectable
parameter is different than for LWP::UserAgent: It
either follows redirects for a request, or it doesn't.
Thus requests_redirectable is a boolean value instead of
the array reference that LWP::UserAgent expects. To
This implies to me that I have the choice to enable or disable redirects for
this useragent with a bool value.
Apache::TestRequest::user_agent(
reset = 1,
cookie_jar = $cookie_jar,
requests_redirectable = 1
);
But this way the cookies are ignored. I expected that
HTTP::Cookies-extract_cookies is called after every request. Therefor I
create the cookie_jar from
package My::Cookies;
use base 'HTTP::Cookies';
sub extract_cookies {
warn extract_cookies!!!;
shift-SUPER::extract_cookies(@_);
}
To get it work, I need to parse the cookie headers myself or
Apache::TestRequest::user_agent(
reset = 1,
cookie_jar = $cookie_jar,
requests_redirectable = 0
);
But here I need to redirect myself or do it with the undocumented
Apache::TestRequest::user_agent(
reset = 1,
cookie_jar = $cookie_jar,
requests_redirectable = [qw~x y~]
);
that does anything I want but is undocumented!
Here is a part from Apache::TestRequest::user_agent that looks wrong to me.
my $redir = $args-{requests_redirectable};
if (ref $redir and (@$redir 1 or $redir-[0] ne 'POST')) {
$RedirectOK = 1;
} else {
$RedirectOK = 0;
}
##
And a test script.
use strict;
use warnings FATAL = 'all';
use Apache::Test;
use Apache::TestUtil;
use Apache::TestRequest qw'GET POST';
plan tests = 3, have 'LWP';
require HTTP::Cookies;
require HTML::Form;
use Data::Dumper;
package My::Cookies;
use base 'HTTP::Cookies';
sub extract_cookies {
warn extract_cookies!!!;
shift-SUPER::extract_cookies(@_);
}
package main;
my $cookie_jar = My::Cookies-new;
Apache::TestRequest::user_agent(
reset = 1,
cookie_jar = $cookie_jar,
requests_redirectable = [qw/c d/]
);
# check if we can request a page
my $r = GET '/x';
ok t_cmp( $r-code, 200, '$r-code == HTTP_OK?');
ok t_cmp( qr:\Qnew account:, $r-content, new account page );
$r = POST '/y', [
email = '[EMAIL PROTECTED]',
login = 'boris16',
];
ok t_cmp( $r-code, 200, '$r-code == HTTP_OK?');
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Infinite looping in self-configuration mode (was Re: [RELEASE CANDIDATE] Apache-Test-1.06)
William McKee wrote: On Mon, May 24, 2004 at 11:19:02AM -0700, Stas Bekman wrote: I'm not sure, but you could run both with tracing on -trace=debug or APACHE_TEST_TRACE_LEVEL=debug and then compare the logs. Could be that in one case it finds a global httpd.conf but not in the other? Hi Stas, Finally getting back to this thread Even with the latest Apache-Test from CVS, I'm still getting the infinite looping when A::T tries to do it's self-configuration. Sorry for taking so long to followup, William. It's hard to guess what could the problem be, when I can't reproduce it. How about the current cvs? Do you still get it? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Doc Links?
David Wheeler wrote: Why not use L for links in the docs? Because it's not supported by Pod::POM and wasn't part of the perlpodspec until recently. Pod::POM detects and auto-links http:// refs on its own, without needing L. --- src/docs/general/testing/testing.pod.~1.33.~Sat May 1 16:53:19 2004 +++ src/docs/general/testing/testing.podFri Jul 16 10:36:15 2004 @@ -3167,7 +3167,7 @@ to test any web application from end to end based application as if it were a black box accepting inputs and returning outputs. -It's available from http://puffin.sourceforge.net/ +It's available from Lhttp://puffin.sourceforge.net/ -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Test Docs Internal Links
David Wheeler wrote: Hi All, I expect that there was a reason that these links were created as they were? % podchecker -nowarnings src/docs/general/testing/testing.pod *** ERROR: unresolved internal link 'Writing_Tests' at line 89 in file src/docs/general/testing/testing.pod *** ERROR: unresolved internal link 'Using_Apache__Test_to_Speed_up_Project_Development' at line 210 in file src/docs/general/testing/testing.pod *** ERROR: unresolved internal link 'Debugging_Tests' at line 756 in file src/docs/general/testing/testing.pod *** ERROR: unresolved internal link 'item_extreme_programming_methodology' at line 776 in file src/docs/general/testing/testing.pod *** ERROR: unresolved internal link 'Basic_Testing_Environment' at line 3065 in file src/docs/general/testing/testing.pod src/docs/general/testing/testing.pod has 5 pod syntax errors. Because really, the POD tools should be able to resolve the links without us having to change everything to underscores. For example, that first one should just be: LWriting Tests|Writing Tests ...and then the POD conversion tools should be able to properly find the internal link and do any necessary transformations. Or do they? Because we use Pod::POM with custom callbacks for generating #fragments. don't use podchecker, use bin/build -l to do links validation. See bin/build -h for more options. When DocSet, which powers modperl-docs, was written, the podspec was unsatisfactory for many purposes, so custom implementations were done. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Is CVS Down?
David Wheeler wrote: % cvs ci -m 'Remove empty list item.' src/docs/general/testing/testing.pod cvs.apache.org: Connection refused cvs [commit aborted]: end of file from server (consult above messages if any) works fine for me -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Test Doc =items
David Wheeler wrote: Hi All, Still looking at the testing.pod, I see list items like this: =over =item * -order=rotate rotate the tests: a, b, c, a, b, c =item * -order=repeat repeat the tests: a, a, b, b, c, c =item * -order=random run in the random order, e.g.: a, c, c, b, a, b =back I think that's generally considered a mixing of item styles. Is there a reason not to just make it: =over =item -order=rotate rotate the tests: a, b, c, a, b, c =item -order=repeat repeat the tests: a, a, b, b, c, c =item -order=random run in the random order, e.g.: a, c, c, b, a, b =back ? Without * it won't generate the bullets. I wanted the bullets so * is there. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestConfigPerl.pm
Geoffrey Young wrote: And may be this is a good idea for the A-T skeleton as well :) indeed :) actually, the bug reporting skeleton used t/My/Handler.pm, and I'll certainly change that to t/lib not. ECANTPARSETHAT the A-T module skeleton actually starts with no supporting modules, since you would want to install the module you're testing. but maybe I'll come up with something anyway :) :) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
t_cmp() revisited
so we reverted the args to t_cmp() to comply with other Test modules conventions, but why reverting the debug printout? I find it confusing: # received: undef # expected: foobar Do the other test modules also print it reversed? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: t_cmp() revisited
Stas Bekman wrote: so we reverted the args to t_cmp() to comply with other Test modules conventions, but why reverting the debug printout? I find it confusing: # received: undef # expected: foobar Do the other test modules also print it reversed? OK, as agreed over irc I've reversed those only for the debug printout. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test module skeletons
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::MB-new( module_name = 'Apache::Test::Skeleton', )-create_build_script; Regards, David -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re:
David Wheeler wrote: now I think I'll commit a change so that TestMB only outputs the Generating test running script message if verbosity is enabled. Maybe you'd like to consider that for TestMM, too? I think we should try to be consistent with all TestM* frontends, no? I think we kept this message, in the same fashion to MakeMaker writing what does it do. and it's good to tell the user that a utility was created, so they know they can use it. e.g. we tell people to use t/TEST -v foo when running specific tests, so it's good to know that it was created. But I don't have a strong feeling about that. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test module skeletons
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,
},
There is no Apache.pm in mp2. You probably wanted to say:
requires = { 'mod_perl' = 0,
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test module skeletons
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 = { 'mod_perl' = '1.99',
in the MP2 example, yes?
That's right. But better do it:
requires = { 'mod_perl' = '1.9914',
to show how to require 1.99_14,
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Silence TestMB?
oops, thanks for the subject :) David Wheeler wrote: On Jul 9, 2004, at 1:01 PM, Stas Bekman wrote: I think we should try to be consistent with all TestM* frontends, no? Yes. I think we kept this message, in the same fashion to MakeMaker writing what does it do. and it's good to tell the user that a utility was created, so they know they can use it. e.g. we tell people to use t/TEST -v foo when running specific tests, so it's good to know that it was created. Hrm. That's a point. I was just thinking that it might be good not to change the usual output of MM or MB unless we were asked to be verbose. But I don't have a strong feeling about that. Me, neither, it was just easy to add. I'll revert the change if others feel strongly about it. It's up to you, since at the moment you are the only MB dev -- you are the king :) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test module skeletons
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 the MP1 example, and
requires = { 'mod_perl' = '1.99',
in the MP2 example, yes?
Assuming this is for the benefit of CPAN/CPANPLUS to install
dependencies, doesn't this run into a couple of problems
that, in particular, Stas has raised:
- CPAN doesn't yet support multiple module versions, only
the latest (which currently is mp1, as mp2 is marked as
a development version);
- if someone had mp2 installed in an Apache2/ subdirectory,
CPAN/CPANPLUS wouldn't see it unless somehow 'use Apache2'
was invoked to adjust @INC;
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 lives in the package mod_perl.
and most likely you'd want to require a minimal version at some point.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test module skeletons
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 (assuming mod_perl.pm of mp2 has a higher version compared to that of mp1). Or will CPANPLUS go beyond the CPAN indices? That I don't know. I would ask the CPANPLUS developers. http://cpanplus.sourceforge.net/ It won't. Since PAUSE index doesn't contain anything, but the latest version. So the syntax sugar of M::B is not quite helpful to satisfy the dependencies at the moment. One (qualitatively similar) example is the GD module, for which there's two major (incompatible) versions, 1 and 2. Currently CPAN.pm reports GD as being version 2.12, and so to install an earlier version 1.x, you have to tell CPAN.pm explicitly which distribution you want to install. Right, the indexing is still a problem. However, for those who have the proper mp installed already, it should just work. And for those who don't, installation should fail, but they'll be told why. But I agree that the indexing issue is important. Perhaps there should be a META.yml rule to tell CPAN what to index, so as to keep track of older versions of modules for those that really need to? There is no such support yet. Even though it was discussed long, long, long time ago. I dunno. Something to ask Jarkko about. That would probably be Andreas and Autrijus. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test module skeletons
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 lives in the
package mod_perl. and most likely you'd want to require a
minimal version at some point.
That's true - I forgot about that ... One could tie the
version of Apache.pm (for mp1) or Apache2.pm (for mp2) to
the corresponding mod_perl.pm version, and make a note of
that in the RELEASE notes, but I agree, that's not
addressing the underlying issue.
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_perl::VERSION }
since EU::MM is going to run that in eval STRING. I thikn CPAN.pm does
the same, not sure about CPANPLUS.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test module skeletons
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; require mod_perl.pm;
$mod_perl::VERSION }
Module::Build uses the same approach. I think that the efforts were
synchronized here.
This patch adds that functionality to mp2:
Index: lib/Apache/Build.pm
===
RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
retrieving revision 1.164
diff -u -r1.164 Build.pm
--- lib/Apache/Build.pm 4 Jul 2004 18:44:49 - 1.164
+++ lib/Apache/Build.pm 9 Jul 2004 22:05:56 -
@@ -1752,7 +1752,12 @@
sub generate_apache2_pm {
my $self = shift;
-my $fixup = !$self-{MP_INST_APACHE2}
+my $fixup = 'EOF';
+our $VERSION = do { require Apache2; require mod_perl;
$mod_perl::VERSION };
+
+EOF
+
+$fixup .= !$self-{MP_INST_APACHE2}
? '# MP_INST_APACHE2=0, do nothing'
: 'EOF';
BEGIN {
it's a bit wicked that Apache2 requires itself:
package Apache2;
our $VERSION = do { require Apache2; require mod_perl; $mod_perl::VERSION };
but it's needed to find the right mod_perl.pm. May be a comment is due.
PAUSE and any tools based on ExtUtils::MakeMaker version parser should
be happy:
% perl -Mblib -MExtUtils::MakeMaker -le 'print MM-parse_version(shift)'
lib/Apache2.pm
1.9915
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-Test module skeletons
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 as the bug reporting skeletons but geared toward new module development - a basic handler exists in lib/Apache/Handler.pm, references to bugs have been removed, etc. 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? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB returns 1
David Wheeler wrote:
On Jul 5, 2004, at 11:09 AM, David Wheeler wrote:
Can't locate object method generate_script via package
Apache::TestMB at Build.PL line 62.
Oh, sorry, it's generate_test_script().
And I have no idea why it is, since it's generate_script in the other
A::T modules, and I documented it that way. Apologies. This patch will
fix it (Stas, we should commit this for the next release):
-- TestMB.pm.~1.2.~Fri Jun 25 18:55:53 2004
+++ TestMB.pmMon Jul 5 11:10:36 2004
@@ -15,7 +15,7 @@
my $self = $pkg-SUPER::new(@_);
$self-{properties}{apache_test_args} = $vars;
$self-{properties}{apache_test_script} ||= 't/TEST';
-$self-generate_test_script;
+$self-generate_script;
return $self;
}
@@ -92,7 +92,7 @@
sub ACTION_cmodules_clean { shift-_cmodues('clean') }
# XXX I'd love to make this optional.
-sub generate_test_script {
+sub generate_script {
my $self = shift;
# If a file name has been passed in, use it. Otherwise, use the
Committed, should there be a log in Changes?
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [cpan #6800] Thread safety: work around perl sort bug
Thanks Andrew. But it's not a problem for us, since we don't run Apache-Test under threads. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Fwd: FAIL Apache-Test-1.12 OpenBSD.i386-openbsd 3.5]
Geoffrey Young wrote: [...] waiting 60 seconds for server to start: . waiting 60 seconds for server to start: ok (waited 0 secs) server localhost.alianet:8529 started t/ping# Failed test 3 in t/ping.t at line 16 FAILED test 3 Failed 1/3 tests, 66.67% okay t/redirect# Failed test 4 in t/redirect.t at line 17 # Failed test 6 in t/redirect.t at line 23 FAILED tests 4, 6 Failed 2/6 tests, 66.67% okay t/request.# Failed test 1 in t/request.t at line 11 # Failed test 5 in t/request.t at line 16 # Failed test 8 in t/request.t at line 20 # Failed test 9 in t/request.t at line 22 FAILED tests 1, 5, 8-9 Failed 4/9 tests, 55.56% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/ping.t31 33.33% 3 t/redirect.t62 33.33% 4 6 t/request.t 94 44.44% 1 5 8-9 Failed 3/3 test scripts, 0.00% okay. 7/18 subtests failed, 61.11% okay. [ error] error running tests (please examine t/logs/error_log) +-+ | To report problems please refer to the SUPPORT file | +-+ *** Error code 1 Stop in /home/alian/.cpanplus/5.8.4/build/Apache-Test-1.12 (line 831 of Makefile). error_log is missing. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Patch] add TEST_EXTRA_ARGS to allow passing arguments to t/TEST thru make invocation
Philippe M. Chiasson wrote: I am working on an Apache::Test based test framework, and being able to pass extra conditionnal arguments to t/TEST thru make test would be very much usefull. Since right now, you can only turn verbose on or off. $ make test TEST_EXTRA_ARGS=-port 8899 -debug=gdb For instance. Otherwise, I end up creating other make targets that look like some_special_test: $(FULLPERL) -I$(INST_ARCHLIB) -I$(INST_LIB) \ t/TEST -port 8899 -bugreport -verbose=$(TEST_VERBOSE) $(TEST_FILES) Forcing me to duplicate too much code for my taste. Thoughts? +1 on the concept I'm not sure about the name choice. $(TEST_VERBOSE) and $(TEST_FILES) are the same as other Test packages use. Do they have $TEST_EXTRA_ARGS too? Otherwise we may better use some name specific to Apache-Test? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Patch] add TEST_EXTRA_ARGS to allow passing arguments to t/TEST thru make invocation
Geoffrey Young wrote: I'm not sure about the name choice. $(TEST_VERBOSE) and $(TEST_FILES) are the same as other Test packages use. Do they have $TEST_EXTRA_ARGS too? Otherwise we may better use some name specific to Apache-Test? MakeMaker looks to support only three: TEST_VERBOSE, TEST_FILE(S), and TESTDB_SW. so how about APACHE_TEST_EXTRA_ARGS? it's verbose but it shouldn't be too bad and it beats making tons of extra targets. +1 -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test Changes
David Wheeler wrote: On Jun 28, 2004, at 6:14 AM, Geoffrey Young wrote: that's ok - I have rerolled a new candidate with these changes incorporated for you to test ;) if all looks good to you I'll release. All tests pass for me. I don't know if this was intentional, but the new tests I introduced last week aren't in the current tarball. It might just make sense to put t/redirect.t into MANIFEST after this release, so that there is some more testing of them between now and 1.13. Although they should just work, and where they don't it should identify bugs in the current code anyway...But I leave it up to you guys. Added. We used to not do that manually, since modperl-2.0 automatically generates MANIFEST. Not the case with A-T. Geoff, just go ahead and release it with the new MANIFEST. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test-1.12
David Wheeler wrote: On Jun 25, 2004, at 4:49 PM, David Wheeler wrote: Hrm, nope. I just installed the latest on another box and the redirection still works properly. Odd... So let's introduce some tests to see where it happens, hrm?? Thanks, committed. David, in the future please create patches with 'cvs diff' so that they can be applied easily, thanks :) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: cvs commit: httpd-test/perl-framework/Apache-Test Changes
[EMAIL PROTECTED] wrote: stas2004/06/27 11:46:03 Modified:perl-framework/Apache-Test/lib/Apache TestReportPerl.pm perl-framework/Apache-Test Changes Log: Force projects that use Apache::TestReportPerl to implement report_to() if they use t/REPORT in their projects. ay, didn't realize the candidate is still out there and wasn't released. Sorry about that. Though these changes should be harmless :) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test-1.12
David Wheeler wrote: On Jun 28, 2004, at 12:39 PM, Stas Bekman wrote: Thanks, committed. David, in the future please create patches with 'cvs diff' so that they can be applied easily, thanks :) Heh, sorry. Should have been easily do-able with patch -p1, though. Ah, right, too many flags to remember :) it's easier when all patches are in the same format :) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test-1.12
William McKee wrote: On Thu, Jun 24, 2004 at 02:35:39PM -0400, William McKee wrote: On Thu, Jun 24, 2004 at 09:30:29AM -0400, Geoffrey Young wrote: please take the time to excercise the candidate through all your existing applications that use Apache-Test and report back successes or failures. Looks good for me. Ooops, spoke too soon again. I'm still having problems with TestRun.pm in Windows XP. Here's the output: [Thu Jun 24 17:21:56 2004] [error] [client 127.0.0.1] Statement unlikely to be reached at c:\TigerCub\perl5\5.8.3/Apache/TestRun.pm line 669. Compilation failed in require at c:\TigerCub\perl5\5.8.3/Apache/TestServer.pm line 25. BEGIN failed--compilation aborted at c:\TigerCub\perl5\5.8.3/Apache/TestServer.pm line 25. Compilation failed in require at c:\TigerCub\perl5\5.8.3/Apache/TestConfig.pm line 51. BEGIN failed--compilation aborted at c:\TigerCub\perl5\5.8.3/Apache/TestConfig.pm line 51. Compilation failed in require at c:\TigerCub\perl5\5.8.3/Apache/Test.pm line 23. BEGIN failed--compilation aborted at c:\TigerCub\perl5\5.8.3/Apache/Test.pm line 23. Compilation failed in require at C:\TigerCub\t\response/Xfer/_get_next_valid_candidate.pm line 11. BEGIN failed--compilation aborted at C:\TigerCub\t\response/Xfer/_get_next_valid_candidate.pm line 11. Compilation failed in require at (eval 6) line 3. Commenting out lines 669 and 1696 make it work fine. I remember having this discussion a few months back but did not find a solution. Apparently it is still an issue. Yup, but it was an issue with previous A-T releases as well, so it's not a showstopper. Someone who can reproduce this problem ought to find a fix. Commenting out code is not quite a fix. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: A::T - Running tests against multiple servers
William McKee wrote: Hi, Here's an interesting problem I've come across. I have an application that is occassionally retrieving duplicate data from a BerkeleyDB. I've written a couple tests which, so far, cannot duplicate the problem (one using a direct database interface and another using A::T). This has led me to believe that the problem must result from a different Apache process interfering with an already running process (there is a gap between reading the record and deleting it whereby another process could come in and read the record again). Thus, I need to get A::T to run several clients in synch against my application in order to hound out this error. Is there a way to do this with A::T or should I be using another utility? You can do that easily: 1) start the server: t/TEST -start 2) start as many clients as you want (e.g. 3 clients): t/TEST -run [tests] t/TEST -run [tests] t/TEST -run [tests] -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Module::Build] Re: Apache::TestMB
Randy Kobes wrote: On Tue, 22 Jun 2004, David Wheeler wrote: On Jun 22, 2004, at 7:32 AM, Randy Kobes wrote: Right now the Makefile is generated by methods within Apache/TestConfigC.pm, which generally consists of calling the apxs utility to compile the module (as well as implementing a 'clean' target). In principle I think this could be done via Module::Build with an appropriate Build.PL and the corresponding changes within Apache/TestConfigC.pm to call it. Okay. I've put in some placeholder methods for this; Randy, can you add the necessary code? Sure, it should be relatively straightforward ... But I'd like to get, especially, Stas' opinion on this - adding this in will necessarily introduce a few branches in the Apache/TestConfigC.pm code related to, first of all, whether to write a Makefile.PL or a Build.PL (and the ensuing different syntax), and then secondly, how to use them. Let's deal with that when the need arises. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
Ken Williams wrote: On Jun 22, 2004, at 5:15 PM, Stas Bekman wrote: David Wheeler wrote: I figured. I like my style, too (mainly just cperl-mode style). ;-) pretty much the same here, cperl-mode too :) For HTML::Mason we found it helpful to add the following as the first line of source files: # -*- cperl-indent-level: 4; cperl-continued-brace-offset: -4; cperl-continued-statement-offset: 4 -*- If every A-T developer was using emacs, it'd make sense. Since that's not the case, I think we don't want to start clutter the files with special modes embedded for each editor used by developers. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
David Wheeler wrote: Now committed with a few minor tweaks, please test it since I don't know how to test it. Thanks David. Moreover, I think it's time to give you commit access to A-T if you wish to. Do you have an account at apache.org? I don't. How do I get one? A quick look around www.apache.org/dev/ doesn't reveal much... It's a well kept secret :) existing committers need to vote first, I'll keep you posted as I get more information. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
David Wheeler wrote: On Jun 23, 2004, at 9:02 AM, Stas Bekman wrote: Now committed with a few minor tweaks, please test it since I don't know how to test it. Thanks David. Cool, thanks. What do you need to be able to feel comfortable/ready to release it? As I mentioned I don't know how to test it, so if you think it's good, then nothing stops us from doing that. We ought to post a release candidate and 24 later go on CPAN. Geoff, if you have no objections, can you handle this release? I'm on the road and not the most suitable person to do the release at the moment. p.s. perhaps someone can approve my posts to module-build-general, I keep on getting those moderation awaiting notices or drop that list from CC. Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: new runtime option: -no-httpd
Geoffrey Young wrote:
hi all.
we have been using Apache-Test to run our entire testing framework, which is
great - we can mix and match apache-related and non-apache related tests
under the same testing tree and it all works without a hitch.
the only problem is that when working on small testing units that don't
require apache the overhead Apache-Test introduces when cleaning,
configuring, starting, and stopping the server is significant. so, I'd like
to add a new runtime option to remove apache-based foo from the test running
process. the usage would be something like this
$ t/TEST -no-httpd t/TMCS/Constants/01compile.t -v
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl /home/geoff/src/tmtest/unit/t/TEST
-no-httpd 't/TMCS/Constants/01compile.t' -v
[warning] skipping configuration: -no-httpd specified
t/TMCS/Constants/01compile1..1
ok 1 - use TMCS::Constants;
ok
All tests successful.
the net result is that this takes, on average, half the time to run this
test when apache is taken out of the picture (, which is much better for
developers - reducing developer frustration is an important step toward the
road to overall test adoption :)
anyway, patch attached.
+1
+if ($self-{opts}-{'no-httpd'}) {
+warning skipping configuration: -no-httpd specified;
may be it's better to sayskipping httpd configuration?
+return
please don't forget ; if } is on the next line.
+}
+
-$self-start;
+$self-start unless $self-{opts}-{'no-httpd'};
$self-run_tests;
-$self-stop;
+$self-stop unless $self-{opts}-{'no-httpd'};
}
may be use -nohttpd, so that you don't need to quote the key string?
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
David Wheeler wrote:
On Jun 22, 2004, at 10:33 AM, Stas Bekman wrote:
Absolutely. It's really just:
MyTest-new-run(@ARGV);
where MyTest is a subclass of Apache::TestRunPerl
I tried that, but it didn't work. I'm not sure why. The first problem
was this code:
$0 = File::Spec-rel2abs($0);
if (-e $0) {
my $top = dirname dirname $0;
chdir $top if $top and -d $top;
}
Which moved things out of the module root, since Build.PL isn't in t/. I
got 'round that by doing Clocal $0 = '', but then nothing else
happened. Odd.
ah, yes, it tries to figure out where it is and move out of t/, as per your
request earlier. Feel free to suggest a way to work it out. That particular
code could be made into a subclassable method, which your subclass could
implement differently.
Though you will need to figure out how to pass the options, which is
already not trivial at all, since there are quite a few ways to feed
them in at different phases.
Yes, that's the other thing I wanted to avoid.
How are you going to avoid that? I mean your users need to be able to run
certain features of Apache-Test, which are beyond 'make test'. May be you want
to always create t/TEST, but run 'make test' without invoking t/TEST?
* I wasn't sure how the TEST_FILES environment variable was supposed
to work. So I'm just passing it to the call to t/TEST if it exists.
Stas, is this the correct thing to do?
I think yes, but why not keep it an env var?
It is an environment variable. If, however, you mean that t/TEST spots
the environment variable and does the right thing, then cool, I'll
simply take out out of TestMB.
Creo que si, i.e. yes :)
I believe it's autogenerated, I didn't write that code, so you can
look just as well :) You can use libapreq-2's source from CPAN to see
how c-modules work.
Pass. I don't really do C. I put in some stubs for it, though.
there is no C, there is perl that creates the necessary build environment.
I've skimmed the source, it looks good David, but please use
indentation of 4 everywhere.
I did; only lines that continue from a previous line use two spaces. If
you want four there (confusing, IMO), I can change it.
Yes please, we use 4 everywhere.
Also how the following code is supposed to work?
my $infile = '$script.PL';
if (-f $infile) {
It will use t/TEST.PL to generate t/TEST if t/TEST.PL exists. Otherwise,
it generates t/TEST like TestConfig::generate_script(). does.
I meant the fact that '$script.PL' doesn't interpolate $script.
Also you can use shortcuts from Apache::TestTrace to do logging.
Um, I have no idea what you're talking about here. Sorry.
use Apache::TestTrace;
debug foo;
error bar;
etc...
The tracelevel will automatically enable and disable various trace levels. See
Apache::TestTrace for more info.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
David Wheeler wrote: How are you going to avoid that? I mean your users need to be able to run certain features of Apache-Test, which are beyond 'make test'. May be you want to always create t/TEST, but run 'make test' without invoking t/TEST? I meant that I wanted to avoid dealing with it. ;-) The current approach works, but if I get rid of t/TEST, I would have to deal with it. The only other approach would be if this stuff was abstracted into a function or method in Apache::TestRun. Then I could just call it with the appropriate arguments. It may be a fairly complex logic to add, though you could write wrappers that simply push things into @ARGV, emulating the command line. Though I'd rather have one way to do things. It's already a non-trivial thing with all the multiple options. If we have to explain to the user in trouble with the test suite more than one way to help us show their problems, it makes things even more complex and confusing. So if you can keep t/TEST as it is I think it'll be a good thing. Feel free to convince me otherwise. Admittedly I have never used MB, so I may miss some things. there is no C, there is perl that creates the necessary build environment. Oh, sorry. Where do I find it? Somewhere around that code that deals with cmodules: grep -Ir cmodules Apache-Test/lib/Apache/ Yes please, we use 4 everywhere. Ick. Done. I only noticed two spaces in one place in generate_script(). Unless you want lines following an opening paren (as in the calls to do_system()) to be indented only 4 spaces, rather than lined up with the previous line? No, no, it's fine. But don't worry, once the patch is finished I'll go over it to make it consistent with the rest of the code. Most of things are just perfect. I meant the fact that '$script.PL' doesn't interpolate $script. Oh, duh. Fixed. I guess that part of the code is not really tested :) Also you can use shortcuts from Apache::TestTrace to do logging. Um, I have no idea what you're talking about here. Sorry. use Apache::TestTrace; debug foo; error bar; etc... The tracelevel will automatically enable and disable various trace levels. See Apache::TestTrace for more info. Um, okay, but what needs to change in TestMB.pm to address this? Is there something missing? I didn't notice anything about this in TestMM.pm. Instead of: print Bar tar car\n; use Apache::TestTrace; debug Bar tar car\n; Now replace debug with whatever level you want this message to be printed at. By default the trace level is 'info', so unless user changes the default, traces: emerg alert crit error warning notice info will always log things, whereas debug() won't. So for example in your case you could use the notice() func. Apache::TestTrace really mimicks the LogLevel from Apache. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::TestMB
David Wheeler wrote: On Jun 22, 2004, at 2:44 PM, Stas Bekman wrote: It may be a fairly complex logic to add, though you could write wrappers that simply push things into @ARGV, emulating the command line. Though I'd rather have one way to do things. It's already a non-trivial thing with all the multiple options. If we have to explain to the user in trouble with the test suite more than one way to help us show their problems, it makes things even more complex and confusing. So if you can keep t/TEST as it is I think it'll be a good thing. Feel free to convince me otherwise. Admittedly I have never used MB, so I may miss some things. I'll leave it; I don't have the tuits to change it. I'm just happy to have something that works with Module::Build. My only thought was that t/TEST seemed like a hack to get something Perlish to work in a Cmake environment. And since Module::Build is a Perl environment, that hack is no longer necessary. But I recognize that there has been a lot built up around that hack, so it's much simpler to follow the 80/20 rule and get it done the way it is. Yes, but it won't work for modules not using MB, so it's better to have something common. We can always change things later if we find it beneficial. Nothing is cast in stone as long as it doesn't add a huge overhead for the user's learning curve. Somewhere around that code that deals with cmodules: grep -Ir cmodules Apache-Test/lib/Apache/ Yes, Randy has been pointing it out. But does TestMB need this support in an initial release? Seems like those who depend on the Makefile will keep using TestMM for a while. I doubt so. Just make it die with the appropriate message, so that if someone needs it they will know that it'll be added in the future. No, no, it's fine. But don't worry, once the patch is finished I'll go over it to make it consistent with the rest of the code. Most of things are just perfect. I figured. I like my style, too (mainly just cperl-mode style). ;-) pretty much the same here, cperl-mode too :) I meant the fact that '$script.PL' doesn't interpolate $script. Oh, duh. Fixed. I guess that part of the code is not really tested :) I never, *ever,* create my own t/TEST.PL, so no, it isn't. generate_script does it for you too. Instead of: print Bar tar car\n; use Apache::TestTrace; debug Bar tar car\n; Now replace debug with whatever level you want this message to be printed at. By default the trace level is 'info', so unless user changes the default, traces: emerg alert crit error warning notice info will always log things, whereas debug() won't. So for example in your case you could use the notice() func. Apache::TestTrace really mimicks the LogLevel from Apache. Are you suggesting that it be used inside Apache::TestMB? There's only one print statement, in generate_script(), and there I followed the approach of Module::Build, even though TestMM used info. It doesn't matter for now. I was just mentioning a feature that you may find useful. So, what more do you need before committing this puppy? I'm ready to take advantage of it with my module and upload that module to CPAN! ;-) It'd be nice to actually try your patch in action with some module that uses MB before committing it. Other than that +1 and thank you, David. Moreover, I think it's time to give you commit access to A-T if you wish to. Do you have an account at apache.org? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::test + mod_ssl
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 uses? A-T writes what it does: % t/TEST -start setting ulimit to allow core files ulimit -c unlimited; /home/stas/perl/5.8.4-ithread/bin/perl5.8.4 /home/stas/apache.org/mp2-pool/ModPerl-Registry/t/TEST -start /home/stas/httpd/prefork/bin/httpd -d /home/stas/apache.org/mp2-pool/ModPerl-Registry/t -f /home/stas/apache.org/mp2-pool/ModPerl-Registry/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS using Apache/2.0.50-dev (prefork MPM) -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::test + mod_ssl
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/logs/httpd.mm.8917) failed But I know how to fix that; there's no logs directory! Thanks again for the help. :) 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. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache::test + mod_ssl
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. 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, /usr/local/apache/logs/httpd.mm.6521) failed Error: MM: mm:core: failed to open semaphore file (Permission denied): OS: No such file or directory I'm guessing that under A-T, it creates it in the test directory. I suppose so. Check that A-t generates ServerRoot setting pointing to the local dir. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: switching t_cmp() argument order
Geoffrey Young wrote:
But it's quite possible that argument could be readonly while not a
string, a simple example is a return value of a function:
% perl -le 'a(b(), b); sub a {($_[0], $_[1]) = ($_[1], $_[0]);}; \
sub b { 5 }'
Modification of a read-only value attempted at -e line 1.
I think you need to revisit that example :)
I fail to see what do you mean.
ok, the attached patch reflects that.
excellent!
the only remaining nit is the deprecation cycle, let's say we happen to
release the next few versions within this month, then you hit 1.15 really
soon. I think it's a matter of time and not release numbers. So may be it's
better to say, let's give people some 3 months to move over and set a certain
date as a cutoff rather than a version number? Just an idea...
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: switching t_cmp() argument order
Geoffrey Young wrote:
Stas Bekman wrote:
Geoffrey Young wrote:
But it's quite possible that argument could be readonly while not a
string, a simple example is a return value of a function:
% perl -le 'a(b(), b); sub a {($_[0], $_[1]) = ($_[1], $_[0]);}; \
sub b { 5 }'
Modification of a read-only value attempted at -e line 1.
I think you need to revisit that example :)
I fail to see what do you mean.
perl -le 'a(b(), c()); sub a {($_[0], $_[1]) = ($_[1], $_[0]);}; \
sub b{5}; sub c{6};
I still don't get it. What are you trying to say?
ok, the attached patch reflects that.
excellent!
the only remaining nit is the deprecation cycle, let's say we happen to
release the next few versions within this month, then you hit 1.15
really soon. I think it's a matter of time and not release numbers. So
may be it's better to say, let's give people some 3 months to move over
and set a certain date as a cutoff rather than a version number? Just an
idea...
sure, we could do that, but then the cutoff isn't really clear. I think
that three revisions will get us through at least another mod_perl release,
when people are perhaps likely to glance at the Changes file.
but if we need more time I think we can take it. if the deprecation cycle
is very long (like 3 new releases takes us a year) I don't think that's
necessarily a bad thing.
Not for Apache-Test. There will be lots of new mp2 releases in the next few
months to come. Once the API is completed and a few remaining release issues
resolved we will start doing release candidates. So as long as we do at least
one tweak to A-T between these releases I promise you A-T 1.15 before the end
of the summer.
but either way is fine. I just didn't want it removed in, say, the release
after the next one.
just add a line like, remove after Sep 15th or so. and may be take it into
if ($deprecated) { ...}
so it's easy to remove the whole branch at once without thinking too much.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: switching t_cmp() argument order
Geoffrey Young wrote:
just add a line like, remove after Sep 15th or so. and may be take it into
if ($deprecated) { ...}
so it's easy to remove the whole branch at once without thinking too much.
the logic was already wrapped in an if block, so I just made a note that we
want it removed by mid september and left it at that. committed, but feel
free to tweak it more if you like.
no, it's fine
thanks for the input :)
;)
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [PATCH] full[er] disclosure on module not-found
Geoffrey Young wrote: Rodent of Unusual Size wrote: have_module() currently is rather terse when the problem with a perl module is actually with something the module requires or uses. here's a patch which will extract a little more info from $@ if it can, and provide it as part of the message. helpful for tracking down what is *actually* at fault.. well, in the _vast_ majority of cases I would expect the error message to read Can't locate that's the purpose of have_module after all, to ping if the module is there or not. in the rare cases where the module is there but can't be loaded (such as modules in development) it might be useful to have additional information. but have_module() really isn't there as a development tool - that's what perl -cw is for :) Seconded. In addition extra verbosity in the terse mode is not helpful at all, it makes the output hard to read. Especially when you have lots of tests. I think it's OK to add any extra logging in the verbose mode though (when -verbose is passed) if you find it helpful as a developer. The verbose mode is for developers and for when users have problems, so any extra useful info is a goodness. nevertheless, it might be useful if you swapped the logic around, adding additional $why only if the error isn't the standard Can't locate Bar.pm in @INC... Yes, I don't quite understand what's the added value of your patch, as you add the extra output when it can't find the file. Where is your supporting email, talks about the opposite case. You probably wanted something like: $why .= $@ unless $@ =~ /^Can't locate/; no? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
William McKee wrote: Thanks for the info Stas and Joe. I will try rebuilding with Joe's suggestion. However, I'm curious why things work just fine when I run the tests and pass in the path to httpd. For example: t/TEST -httpd /usr/local/apache/bin/httpd I'm not sure, but you could run both with tracing on -trace=debug or APACHE_TEST_TRACE_LEVEL=debug and then compare the logs. Could be that in one case it finds a global httpd.conf but not in the other? -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: APACHE_TEST_NO_STICKY_PREFERENCES problems
Geoffrey Young wrote: Stas Bekman wrote: Geoff, why did you make APACHE_TEST_NO_STICKY_PREFERENCES prevent from saving autoconfig? however it's done, I want an option wereby absolutely nothing sticky is ever generated or used. the don't touch my system option was my goal, which really isn't unreasonable. Granted, instead of using APACHE_TEST_NO_STICKY_PREFERENCES one could go and delete the custom config files, but one needs to find them first and it's error prone for testing. I'd like to see APACHE_TEST_NO_STICKY_PREFERENCES do its job w/o getting on the way of things that we need to test. so you're arguing that we should write out the sticky files, even if the user doesn't ever want them interfering? I'm not arguing at all. It's just when APACHE_TEST_NO_STICKY_PREFERENCES=1 and no arguments passed, the logic is broken. The program gets into a loop it can't break out of. I've suggested a fix, if you don't like it, please suggest a different one. For example do not run interactive config if APACHE_TEST_NO_STICKY_PREFERENCES=1. But it's a pity, since we could suggest users this technique to override older saved config (in addition to -save). May be we need a more granular approach and have two variables, one for NO_READ and another NO_WRITE, e.g.: APACHE_TEST_CUSTOM_CONFIG=0 # read/write (00) APACHE_TEST_CUSTOM_CONFIG=1 # no read(01) APACHE_TEST_CUSTOM_CONFIG=2 # no write (10) APACHE_TEST_CUSTOM_CONFIG=3 # no read and no write (01 | 10) or anything else you'd like, preferrably with less typing then the current variable. if you prefer words, may be: APACHE_TEST_CUSTOM_CONFIG=0 APACHE_TEST_CUSTOM_CONFIG=NO_READ APACHE_TEST_CUSTOM_CONFIG=NO_WRITE APACHE_TEST_CUSTOM_CONFIG=NO_RDWR In case of 'no_write' (interactive config should disabled to fix the logic). -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: APACHE_TEST_NO_STICKY_PREFERENCES problems
Geoffrey Young wrote: so you're arguing that we should write out the sticky files, even if the user doesn't ever want them interfering? I'm not arguing at all. It's just when APACHE_TEST_NO_STICKY_PREFERENCES=1 and no arguments passed, the logic is broken. The program gets into a loop it can't break out of. an endless loop? hmm, I hadn't seen that. _something_ definitely needs to be fixed, then. the endless loop in the following way: you don't provide args and you tell the program not to use the previous config, so it starts interactive config, you answer the questions, it tries to save them, but APACHE_TEST_NO_STICKY_PREFERENCES=1 prevents it from saving them. the program restarts, and goes again into the same loop. I've suggested a fix, if you don't like it, please suggest a different one. ok For example do not run interactive config if APACHE_TEST_NO_STICKY_PREFERENCES=1. But it's a pity, since we could suggest users this technique to override older saved config (in addition to -save). well, I think I'd like to see some more intelligence with the sticky preferences option. for instance, I'd like to see a -remove option that removed all hints of sticky preferences, to avoid exactly the error-prone manual removal you mentioned in your last message. I think you don't want it to be removed, you want it to be ignored. If it doesn't get on your way, why should you care if it's there or not. If it's removed you have to configure it again, which is annoying. But sure, if you want to code -remove option that's fine. perhaps change -save to extend to -custom_config=[save|remove]. and you have a valid point - is there any way to override existing sticky preferences? IIRC that was my main problem with all of this, that the sticky preferences were too sticky for my needs. rather than abolish them altogether, it would be nice to have an -interactive option to force interactive configuration again (which would not be saved unless -save was specified). That's how I coded it. Please see the documented logic. It's quite possible that I didn't take into account some things that you do, but it perfectly works for all my setups. speaking of -save, I can't recall if that is the default, but if it is I wonder if it should be. it's the default if no config already saved. -save is really -override. it might not be easier on end users to save the first time, but it might help them in the long run if things were not saved until explicitly given -save. what if the first time they run A-T it's against a development apache version? it's not exactly intuitive how to un-stick yourself, so being sticky by default (rather than on demand) might end up causing trouble down the line. That's not the case with most of users. Most users will install mp2 which will save the config for them anyway (regardless of A-T), then they will run other modules against that. If the upgrade their server and A-T can't find it in the same location it has saved, it'll ignore that config. As I said above -remove is a good idea, but I doubt it can be easily implemented correctly if at all. Unless you make it a separate path (i.e. remove and quit) you are complicating the already complex logic even more complex. That's because the custom config may get loaded from Makefile.PL or from the test suite itself. In fact that's exactly where it won't work - if you call -remove and it deletes system-wide file, you will still have it locally. Moreover it may require root perms. And you may have hidden @INCs which may kick in later... I'd rather see a good test case of yours where things don't work as expected (i.e. custom config gets on the way of the explicit options) and get that fixed. That's all said, I'm not disagreeing that we need an intuitive way to fix any stale custom configs. May be option -save should have a bit of overloading in it: ignore any custom configs, use the explicit options, passed via env vars, command line args or interactive config, and save them overriding the old configs. Which is similar to my idea of NO_READ in the previous post. just some ideas. Yeah, but we still have a problem to solve. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
William McKee wrote: On Thu, May 20, 2004 at 11:58:36AM -0700, Stas Bekman wrote: Thanks William, it was due to my recent change to remove the use of revision 2 as a default. I was able to reproduce it. Now fixed in cvs. Please confirm that it works for you. Hi Stas, Actually I just pulled it out of CVS and am stuck in an endless configuration loop. It is giving me the following option: Please provide a full path to 'httpd' executable or choose from the following options: [1] /usr/local/apache/bin/httpd [1] If I hit enter, I'm returned back to this prompt. If I type in the address, it returns me back to the prompt. Any ideas or other tests you'd like me to run? Make sure you don't have APACHE_TEST_NO_STICKY_PREFERENCES env var turned on. That's exactly the problem I've raised in the other thread. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
William McKee wrote: On Thu, May 20, 2004 at 08:00:36PM -0700, Stas Bekman wrote: Make sure you don't have APACHE_TEST_NO_STICKY_PREFERENCES env var turned on. That's exactly the problem I've raised in the other thread. Yeah, I read some of that thread though didn't follow the exact details. In any case, the only A::T related setting in my env is APACHE_TEST_COLOR. Please show us the verbose trace: t/TEST -trace=debug including the part where you completed the interactive questions, and it brought you back to interactive config again. Thanks. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
Geoffrey Young wrote: Please show us the verbose trace: t/TEST -trace=debug including the part where you completed the interactive questions, and it brought you back to interactive config again. ok, the plan was to roll an official release this afternoon (as in now). what's the feeling on this? release as is or wait for a fix? the mod_perl release is dependent on this, as each mod_perl release really needs to come with an official version of Apache-Test (for reasons we've discussed before). Please go ahead and release both. mod_perl is not affected since it configures A-T on its own. We can release a new A-T later, when William follow ups and we figure out what the problem is, if at all. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
William McKee wrote: On Thu, May 20, 2004 at 08:29:33PM -0700, Stas Bekman wrote: Please show us the verbose trace: t/TEST -trace=debug including the part where you completed the interactive questions, and it brought you back to interactive config again. Got the latest version from CVS again and this time received the following message when running `perl Makefile.PL': generating script t/TEST Checking if your kit is complete... Warning: the following files are missing in your kit: META.yml Please inform the author. Writing Makefile for Apache::Test The trace is attached. Note that this test was performed on a different system which apparently did not have the location of my server cached so I had to type it in. I still saw the same looping behavior. All tests pass if I run `t/TEST -httpd /usr/local/apache/bin/httpd'. Thanks William, what do you have inside: /home/william/.apache-test/Apache/TestConfigData.pm -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: APACHE_TEST_NO_STICKY_PREFERENCES problems
Geoffrey Young wrote: just some ideas. Yeah, but we still have a problem to solve. well, go ahead and remove the lack of save then, if you're certain that it fixes the problem you're having. You will be having them too :) That's one of the modes we need to test before making a new release. I don't really have the time at the moment to implement an entire new mechanism. actually, I'd rather stay away from the sticky stuff entirely, as it's overly complex for me and (as a user :) I never saw the need for it anyway. Not really a new mechanism, just to tweak the current one that you added to have a better granularity. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
William McKee wrote:
On Fri, May 21, 2004 at 10:38:59AM -0700, Stas Bekman wrote:
Thanks William, what do you have inside:
/home/william/.apache-test/Apache/TestConfigData.pm
[...]
$Apache::TestConfigData::vars = {
'httpd' = '/usr/local/apache/bin/httpd',
So does this file exist and executable? /usr/local/apache/bin/httpd? any
symlinks involved? I fail to reproduce it on my machine.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [RELEASE CANDIDATE] Apache-Test-1.06
William McKee wrote: On Fri, May 21, 2004 at 01:43:49PM -0700, Stas Bekman wrote: So does this file exist and executable? /usr/local/apache/bin/httpd? any symlinks involved? I fail to reproduce it on my machine. Yes, it exists and is executable. I wonder if there is a permissions problem That appears to be a problem. If I try to run it as a normal user (which is how I was testing), I get the following error: Ouch! ap_mm_create(1048576, /usr/local/apache/logs/httpd.mm.6895) failed Error: MM: mm:core: failed to open semaphore file (Permission denied): OS: No such file or directory Of course, that is using the default configuration file which is probably the reason its trying to write to /usr/local/apache/logs. However, if I go to the t/conf directory and try the following command: /usr/local/apache/bin/httpd -f httpd.conf I'm getting similar output: Ouch! ap_mm_create(1048576, /usr/local/apache/logs/httpd.mm.7012) failed Error: MM: mm:core: failed to open semaphore file (Permission denied): OS: No such file or directory so it's not A-T's problem. It tries to run httpd to get the needed info and it fails since httpd is broken. Now, why is it broken I don't know. Something to do with libmm I guess. Have you upgraded it or something? I guess you want to ask that at the apache-users mailing list. I have never seen this kind of problem before. -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
APACHE_TEST_NO_STICKY_PREFERENCES problems
Geoff, why did you make APACHE_TEST_NO_STICKY_PREFERENCES prevent from saving
autoconfig?
sub custom_config_save {
my $self = shift;
if ($ENV{APACHE_TEST_NO_STICKY_PREFERENCES}) {
debug skipping save of custom config data;
return;
}
I mean, APACHE_TEST_NO_STICKY_PREFERENCES already prevents the loading of that
config, why not let saving you. It breaks the interactive configuration
process which we need to add to the RELEASE doc to test. I try to do:
env APACHE_TEST_NO_STICKY_PREFERENCES=1 perl-5.8.4-ithread Makefile.PL
env APACHE_TEST_NO_STICKY_PREFERENCES=1 APACHE_TEST_TRACE_LEVEL=debug make test
and when the interactive config is over, we get:
skipping save of custom config data
rerunning '/home/stas/perl/5.8.4-ithread/bin/perl5.8.4 /tmp/Apache-Test/t/TEST
-bugreport -verbose=0' with new config opts
trying to load custom config data
...
and so we get into interactive config again.
Granted, instead of using APACHE_TEST_NO_STICKY_PREFERENCES one could go and
delete the custom config files, but one needs to find them first and it's
error prone for testing. I'd like to see APACHE_TEST_NO_STICKY_PREFERENCES do
its job w/o getting on the way of things that we need to test.
Besides removing that clause in custom_config_save we also need to turn off
that env var, after custom config is over, in order to pick up those vars. So
overall it looks like:
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.169
diff -u -r1.169 TestRun.pm
--- lib/Apache/TestRun.pm 13 May 2004 01:09:26 - 1.169
+++ lib/Apache/TestRun.pm 20 May 2004 19:58:12 -
@@ -1412,11 +1412,6 @@
sub custom_config_save {
my $self = shift;
-if ($ENV{APACHE_TEST_NO_STICKY_PREFERENCES}) {
-debug skipping save of custom config data;
-return;
-}
-
my $vars = $self-{test_config}-{vars};
my $conf_opts = $self-{conf_opts};
my $config_dump = '';
@@ -1684,6 +1679,8 @@
# the problem is various cached data which won't be refreshed. so
# the simplest is just to restart the run from scratch
chdir $orig_cwd;
+# we also need to enable sticky preferences, otherwise re-run will fail
+$ENV{APACHE_TEST_NO_STICKY_PREFERENCES} = 0;
warning rerunning '$original_command' with new config opts;
exec $original_command;
die exec $original_command has failed; # shouldn't be reached
If applied now all we need is to add one more step to RELEASE testing
procedures:
Index: RELEASE
===
RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/RELEASE,v
retrieving revision 1.9
diff -u -r1.9 RELEASE
--- RELEASE 19 Apr 2004 02:38:58 - 1.9
+++ RELEASE 20 May 2004 20:02:16 -
@@ -4,13 +4,25 @@
etc. Now test this generated package (not cvs) with as many
configurations as possible on as many platforms as possible.
- a. nuke any preinstalled Apache-Test libs and run 'make test'
+ a. copy Apache-Test away from within the modperl-2.0 build, since it
+ affects the way things are configured.
- b. test that you can 'make install' and then run 'make test' again
+ b. nuke any preinstalled Apache-Test libs and run 'make test'
- c. test whether we still 100% OK on systems with no LWP:
+ c. test that you can 'make install' and then run 'make test' again
+
+ d. test whether we still 100% OK on systems with no LWP:
% APACHE_TEST_PRETEND_NO_LWP=1 make test
+
+ e. now test without sticky config, which involves an interactive
+ custom config:
+
+ % APACHE_TEST_NO_STICKY_PREFERENCES=1 perl-5.8.4-ithread Makefile.PL
+ % APACHE_TEST_NO_STICKY_PREFERENCES=1 make test
+
+ the env var is needed for both steps, to avoid picking up
+ preconfigured data.
2. once confident that the package is good, upload a release candidate
to perl.apache.org/~username and post 24 hour-ish candidate alert
This step would have detected the problem William has reported.
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Apache-httpd -Test coverage
Abhishek Khandelwal wrote: Hi, I am trying to find out the code-coverage for httpd using the perl-testframework. I am trying to use Rational's PureCoverage tool to do that. One of the requirements for Purecoverage tool is to insert purecov before CC(cc or gcc) in makefile. Does anyone have idea, how to insert purecov before cc in makefile? Since the makefile of httpd is automatically generated using configure script, it has to be done automatically. I tried to pass CC=purecov gcc to the configure, but it inserts purecov everywhere and purecov tries to instrument .a and .so files as well, which should not be done at compile time. Anyone has any idea about how to proceed, please let me know. Dunno about Rational's but gcov works: http://apr.apache.org/coverage/index.html replace ./testall with 'make test' Philippe has done that for mod_perl 2.0 resulting in: http://gozer.ectoplasm.org/mod_perl/coverage/report.html -- __ Stas BekmanJAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide --- http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
