Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigC.pm
Geoffrey Young wrote: >> +my $dversion = $self->server->dversion; > >> +if ($dversion eq '-DAPACHE1') { > > that's '-D APACHE1' in current cvs, no? so i saw, when my tests blew up. -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!"
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfigC.pm
> +my $dversion = $self->server->dversion; > +if ($dversion eq '-DAPACHE1') { that's '-D APACHE1' in current cvs, no? --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm
Geoffrey Young wrote: $ENV{APACHE_TEST_STARTUP_TIMEOUT} now supersedes -startup_timeout [...] What's the reason for this change? it was a follow up from something on modperl@ I almost always expect that command line arguments supercede env variables.. i.e. $> CVSROOT=foo cvs -d bar co foo Bad CVSROOT: `bar'. What you can see should win over what you can't see, IMO yeah, I thought about this after committing it - it's definitely better the way it was. but it leaves mod_perl users in a lurch if they want to up the startup time. the better solution is probably to have ModPerl::TestRun look at %ENV before it sets the startup timeout. I'll fit that tomorrow unless you or stas beat me to it. I've committed that change already. But I'll leave it to you to revert the one you committed ;) -- __ 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 TestServer.pm
>> $ENV{APACHE_TEST_STARTUP_TIMEOUT} now supersedes -startup_timeout >>[...] > > > What's the reason for this change? it was a follow up from something on modperl@ > I almost always expect that command > line arguments supercede env variables.. i.e. > > $> CVSROOT=foo cvs -d bar co foo > Bad CVSROOT: `bar'. > > What you can see should win over what you can't see, IMO yeah, I thought about this after committing it - it's definitely better the way it was. but it leaves mod_perl users in a lurch if they want to up the startup time. the better solution is probably to have ModPerl::TestRun look at %ENV before it sets the startup timeout. I'll fit that tomorrow unless you or stas beat me to it. --Geoff
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm
Philippe M. Chiasson wrote: On Thu, 2004-03-04 at 22:21 +, [EMAIL PROTECTED] wrote: geoff 2004/03/04 14:21:27 Modified:perl-framework/Apache-Test Changes perl-framework/Apache-Test/lib/Apache TestServer.pm Log: $ENV{APACHE_TEST_STARTUP_TIMEOUT} now supersedes -startup_timeout [...] What's the reason for this change? I almost always expect that command line arguments supercede env variables.. i.e. $> CVSROOT=foo cvs -d bar co foo Bad CVSROOT: `bar'. What you can see should win over what you can't see, IMO Yup, I've already pointed that out. I guess Geoff is not around. __ 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 patch] give a hint how to raise the timeout
Stas Bekman wrote: Well, you could still say "Or repeat the last command with the -startup_timeout=420 option". That would work, if the last command was 'make test' or any other wrapper. s/would/won't/ -- __ 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 patch] give a hint how to raise the timeout
David Wheeler wrote: Alternatively we could say: giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. For example set the env var APACHE_TEST_STARTUP_TIMEOUT to a longer value, e.g. 400 and repeat the last command. But can we trust the user to know how to set an env var? May be we should. Yeah, I think so, though you might want to say "environment variable", instead. Of course, I was just laze to type it out ;) The only reason I mentioned -startup_timeout=420 is that if they have already used that option, APACHE_TEST_STARTUP_TIMEOUT won't take an effect, since command line options override env vars. But may be they will figure it out on their own. Well, you could still say "Or repeat the last command with the -startup_timeout=420 option". That would work, if the last command was 'make test' or any other wrapper. Really, what I'm after is to give users as many hints as possible to get their side's problem resolved by themselves before they waste their and my time submitting a bug which is not. Of course, it's a good thing to do. I'm just nitpicking the wording. ;-) And thank you for 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: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestServer.pm
On Thu, 2004-03-04 at 22:21 +, [EMAIL PROTECTED] wrote: > geoff 2004/03/04 14:21:27 > > Modified:perl-framework/Apache-Test Changes >perl-framework/Apache-Test/lib/Apache TestServer.pm > Log: > $ENV{APACHE_TEST_STARTUP_TIMEOUT} now supersedes -startup_timeout > [...] What's the reason for this change? I almost always expect that command line arguments supercede env variables.. i.e. $> CVSROOT=foo cvs -d bar co foo Bad CVSROOT: `bar'. What you can see should win over what you can't see, IMO -- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5 signature.asc Description: This is a digitally signed message part
Re: [A-T patch] give a hint how to raise the timeout
On Mar 4, 2004, at 5:59 PM, Stas Bekman wrote: Ideally you'd know what was the original command they have executed, but it's not possible. The most correct answer would be $0, since they will at least get to run the correct part if it was a bigger 'make test' or something else. Right. Alternatively we could say: giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. For example set the env var APACHE_TEST_STARTUP_TIMEOUT to a longer value, e.g. 400 and repeat the last command. But can we trust the user to know how to set an env var? May be we should. Yeah, I think so, though you might want to say "environment variable", instead. Of course in my proposed wording: % APACHE_TEST_STARTUP_TIMEOUT=420 make test wont' work on C-shell complient systems, and hopefully they have /bin/env or a built-in 'env' function. So may be the above suggestion is the best. Right. The only reason I mentioned -startup_timeout=420 is that if they have already used that option, APACHE_TEST_STARTUP_TIMEOUT won't take an effect, since command line options override env vars. But may be they will figure it out on their own. Well, you could still say "Or repeat the last command with the -startup_timeout=420 option". Really, what I'm after is to give users as many hints as possible to get their side's problem resolved by themselves before they waste their and my time submitting a bug which is not. Of course, it's a good thing to do. I'm just nitpicking the wording. ;-) Regards, David
Re: [A-T patch] give a hint how to raise the timeout
David Wheeler wrote: On Mar 4, 2004, at 5:09 PM, Stas Bekman wrote: Not in this case. T-H wasn't called yet. It gets called only after server successfully starts. Ah, right, okay. If you they did: % make test but you'd suggest to run: % ./Build test not only it'll confuse the user, who aren't aware of Build or t/TEST (in caes of Makemaker) existance, but it also won't do what you wanted the user to do. For example 'make test' in mp2 runs several tests suites and also ensures to print a bug report banner. t/TEST will run only one test suite and won't print the banner (unless the flag -bugreport flag will be passed). All I'm saying is that it could be confusing if they ran './build test' and you're asking them to run 'make test'. But FWIW, I see this type of problem all the time. For example, CPAN and CPANPLUS will prompt you to run 'make install UNINST=1' when they notice older versions of a module you're installing, even if the module is using Module::Build and needs to run './Build install uninst=1'. I don't know of a simple answer to this problem, but using 'make install' is probably the simplest thing to do for the time being. Ideally you'd know what was the original command they have executed, but it's not possible. The most correct answer would be $0, since they will at least get to run the correct part if it was a bigger 'make test' or something else. Alternatively we could say: giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. For example set the env var APACHE_TEST_STARTUP_TIMEOUT to a longer value, e.g. 400 and repeat the last command. But can we trust the user to know how to set an env var? May be we should. Of course in my proposed wording: % APACHE_TEST_STARTUP_TIMEOUT=420 make test wont' work on C-shell complient systems, and hopefully they have /bin/env or a built-in 'env' function. So may be the above suggestion is the best. The only reason I mentioned -startup_timeout=420 is that if they have already used that option, APACHE_TEST_STARTUP_TIMEOUT won't take an effect, since command line options override env vars. But may be they will figure it out on their own. Really, what I'm after is to give users as many hints as possible to get their side's problem resolved by themselves before they waste their and my time submitting a bug which is not. __ 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 patch] give a hint how to raise the timeout
On Mar 4, 2004, at 5:09 PM, Stas Bekman wrote: Not in this case. T-H wasn't called yet. It gets called only after server successfully starts. Ah, right, okay. If you they did: % make test but you'd suggest to run: % ./Build test not only it'll confuse the user, who aren't aware of Build or t/TEST (in caes of Makemaker) existance, but it also won't do what you wanted the user to do. For example 'make test' in mp2 runs several tests suites and also ensures to print a bug report banner. t/TEST will run only one test suite and won't print the banner (unless the flag -bugreport flag will be passed). All I'm saying is that it could be confusing if they ran './build test' and you're asking them to run 'make test'. But FWIW, I see this type of problem all the time. For example, CPAN and CPANPLUS will prompt you to run 'make install UNINST=1' when they notice older versions of a module you're installing, even if the module is using Module::Build and needs to run './Build install uninst=1'. I don't know of a simple answer to this problem, but using 'make install' is probably the simplest thing to do for the time being. Regards, David
Re: [A-T patch] give a hint how to raise the timeout
David Wheeler wrote: On Mar 4, 2004, at 4:15 PM, Stas Bekman wrote: The patch below attempts to give users an idea to try before they rush to report a bug. For example: waiting 120 seconds for server to start: not ok giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. For example: % APACHE_TEST_STARTUP_TIMEOUT=420 make test or: % /home/stas/apache.org/mp2-cvs/Apache-Test/t/TEST -startup_timeout=420 server failed to start! (please examine t/logs/error_log) Well, to be compliant with the output that Test::Harness expects, you should precede each line that's intended for the user rather than for Test Harness with "# ". Not in this case. T-H wasn't called yet. It gets called only after server successfully starts. since most likely they run 'make test' I put that option first. How does that sound? It'd be better if you could tell what they were running. It might have been "./Build test" (and will be more and more, as soon as Apache::TestMB is done). If you they did: % make test but you'd suggest to run: % ./Build test not only it'll confuse the user, who aren't aware of Build or t/TEST (in caes of Makemaker) existance, but it also won't do what you wanted the user to do. For example 'make test' in mp2 runs several tests suites and also ensures to print a bug report banner. t/TEST will run only one test suite and won't print the banner (unless the flag -bugreport flag will be passed). __ 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 patch] give a hint how to raise the timeout
On Mar 4, 2004, at 4:15 PM, Stas Bekman wrote: The patch below attempts to give users an idea to try before they rush to report a bug. For example: waiting 120 seconds for server to start: not ok giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. For example: % APACHE_TEST_STARTUP_TIMEOUT=420 make test or: % /home/stas/apache.org/mp2-cvs/Apache-Test/t/TEST -startup_timeout=420 server failed to start! (please examine t/logs/error_log) Well, to be compliant with the output that Test::Harness expects, you should precede each line that's intended for the user rather than for Test Harness with "# ". since most likely they run 'make test' I put that option first. How does that sound? It'd be better if you could tell what they were running. It might have been "./Build test" (and will be more and more, as soon as Apache::TestMB is done). Regards, David
[A-T patch] give a hint how to raise the timeout
The patch below attempts to give users an idea to try before they rush to report a bug. For example: waiting 120 seconds for server to start: not ok giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. For example: % APACHE_TEST_STARTUP_TIMEOUT=420 make test or: % /home/stas/apache.org/mp2-cvs/Apache-Test/t/TEST -startup_timeout=420 server failed to start! (please examine t/logs/error_log) Index: lib/Apache/TestServer.pm === RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestServer.pm,v retrieving revision 1.78 diff -u -r1.78 TestServer.pm --- lib/Apache/TestServer.pm4 Mar 2004 05:51:31 - 1.78 +++ lib/Apache/TestServer.pm5 Mar 2004 00:11:34 - @@ -560,7 +560,16 @@ last; } elsif ($delta > $timeout) { -print $preamble, "giving up after $delta secs\n"; +my $suggestion = $timeout + 300; +print $preamble, "not ok\n"; +error < +giving up after $delta secs. If you think that your system +is slow or overloaded try again with a longer timeout value. +For example: + % APACHE_TEST_STARTUP_TIMEOUT=$suggestion make test +or: + % $0 -startup_timeout=$suggestion +EOI last; } } since most likely they run 'make test' I put that option first. How does that sound? __ 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