On Tue, 17 Sep 2002, David Hill wrote:
> Tried that (twice) and it did not help.
> Thanks for the pointer to the config blocks, missed that in my
> RTFM-ing.
>
> If I hand hack a conf file based on your pointer, things run much
> better, but what a pain
t/TEST -clean
t/TEST -trace=debug
wil
On Wed, 18 Sep 2002, Doug MacEachern wrote:
> On Wed, 18 Sep 2002, Geoffrey Young wrote:
>
> > I think the attached patch behaves as suggested.
>
> perfectly, thanks.
with 5.8.0 that is. with 5.6.1, dies with:
Error in option spec: "verbose:1"
On Wed, 18 Sep 2002, Geoffrey Young wrote:
> I think the attached patch behaves as suggested.
perfectly, thanks.
On Tue, 17 Sep 2002, David Hill wrote:
>
> Hi,
> I finally got my first run of the perl-framework against 2.0 on Tru64. I
> am using a pull from cvs from late last week, After rooting around in the
> failures, I noticed that none of the c-modules libraries are being loaded,
> and that of c
On Mon, 16 Sep 2002, Dave Hill wrote:
>
> Hi,
> Just starting to use the test framework on Tru64. Bumped into
> a compiler issue... Our compiler does not like multiline implicite strings.
> You can do muliline strings, you just need to end them with '\n\'. Attached
> is a diff -c of my chan
i think lwp does the right thing, but TestRequest.pm does not.
patch below should fix (untested).
--- Apache-Test/lib/Apache/TestRequest.pm 4 Apr 2002 00:54:26 - 1.71
+++ Apache-Test/lib/Apache/TestRequest.pm 17 Sep 2002 20:22:38 -
@@ -251,7 +251,7 @@
$credentials{$ke
> return $preamble . <<'EOF';
> +ifdef TEST_VERBOSE
> + override TEST_VERBOSE = -verbose
> +endif
pretty sure ifdef/endif/override/ifeq are not portable (gmake-isms)
better to have the Makefile run 't/TEST -verbose=$(TEST_VERBOSE)'
of course, would still want 't/TEST -v' to work as it does
On Mon, 3 Jun 2002, Justin Erenkrantz wrote:
> Um, I think you misread my commit. All I changed was StartServers.
totally, i only read - @MaxClients@ + 1, never even saw StartServers.
disregard my comments, they were meant for MaxClients, your change is
fine with me.
On Mon, 3 Jun 2002, Doug MacEachern wrote:
> umm, not with "MaxClients 1" it won't
oh wait, you changed StartServers not MaxClients, maybe that isn't a
problem.
On Mon, 3 Jun 2002, Justin Erenkrantz wrote:
> Um, as I pointed out, none of the other MPMs are configured like
> this. Only prefork would start multiple servers. The others
> always run under a single process. -- justin
yeah, cos threaded mpms can handle concurrent requests with one
process
On Mon, 3 Jun 2002, Justin Erenkrantz wrote:
> The reason I don't like that is because if I need to restart the
> server I have to quit my gdb. I want my gdb to last longer than
> the process (so my breakpoints et al remain the same).
you can use the -maxclients option or edit httpd.conf by han
On 3 Jun 2002 [EMAIL PROTECTED] wrote:
> aaron 2002/06/03 11:31:00
>
> Modified:perl-framework README
> Log:
> Add a note about envoking gdb.
note that this and heaps of other stuff is in
httpd-test/perl-framework/Apache-Test/README
which is where it belongs, since Apache-Test
On Mon, 3 Jun 2002, Aaron Bannert wrote:
> Cliff is always mentioning something like t/TEST -d gdb or something
> like that. Won't that run in -X mode automatically?
yes.
this change is wrong. please revert and explain what you need so we can
find the right solution.
On 3 Jun 2002 [EMAIL PROTECTED] wrote:
> jerenkrantz2002/06/03 11:03:42
>
> Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
> Log:
> Only start one server instance until
seems that the test suite now requires httpd-2.0-cvs from
HEAD? server does not start with 1.3.x or 2.0.36:
Syntax error on line 139 of .../t/conf/extra.conf
RewriteMap: map file or program not
found:/.../t/htdocs/modules/rewrite/append.pl
foo
On Sat, 25 May 2002, Cliff Woolley wrote:
>
> Now that the SSLLog is combined with the regular log, and since we run at
> full debug loglevel, the error_log is growing too fast. One run through
> t/TEST on my system gives about 60MB worth of error_log. No problem
> there. BUT, when you run t/S
On Mon, 20 May 2002, Stas Bekman wrote:
> Because the color setting doesn't have any effect if you build using the
> script. e.g. before my change this script won't work with colors:
>
> #!/bin/sh
> make clean
> APACHE_TEST_COLOR=1; export APACHE_TEST_COLOR
> /home/stas/perl/ithread/bin/perl Mak
On 19 May 2002 [EMAIL PROTECTED] wrote:
> stas02/05/19 00:56:32
>
> Modified:perl-framework/Apache-Test/lib/Apache TestConfig.pm
>perl-framework/Apache-Test README
> Log:
> make the APACHE_TEST_COLOR env setting work when running from script
> if running as bat
On Tue, 14 May 2002, Cliff Woolley wrote:
> Thanks. I had noticed that commit, but thought maybe there would be some
> way to fix it by just adjusting extra.conf.in rather than reverting. Oh
> well, whatever works. :)
it broke other stuff too. i have the functionality i was after now with
t
On Tue, 14 May 2002, Cliff Woolley wrote:
>
> Anybody know why this just started happening within the last few days?
i just backed out the change from yesterday that caused it, should be ok
now.
On Tue, 16 Apr 2002, Stas Bekman wrote:
> one last question. Should the ssl certificates be recreated on t/TEST
> -clean (or 'make test')?
yup. if you don't want them to be, there are several ways to keep
t/conf/ssl/ca from being deleted/regenerated. careful though, since new
ssl tests come
yup, t/TEST -conf will 'make' the c-modules, you can also just do
'make cmodules' if you only want to compile the changed c-modules.
On Sat, 13 Apr 2002, Stas Bekman wrote:
> but why 't/TEST -clean' removes the compiled modules? Shouldn't this be
> the job of 'make clean' and its variants?
i don't really care. i never use 'make test' or even 'make' here.
i have several checkouts of httpd-test/perl-framework that point to
di
On Fri, 12 Apr 2002, Stas Bekman wrote:
> Any idea why 'make test' in perl-framework is recompiling everything on
> each invocation without sources getting changed? Including rebuilding
> ssl certs.
because 'make test' always does a t/TEST -clean after itself.
it is a nice feature when it works, so i've re-enabled for linux only.
for the other platforms in the current state, its better to wait 60
seconds if the server fails to start than to throw and error and die when
it has successfully started.
On Fri, 5 Apr 2002, Cliff Woolley wrote:
> Doug. DOOD. You're working too hard. GO PARTY! ;)
well, i am drinking a beer at least. wasn't expecting this GA push today,
so i'm scrambling to get a modperl release together. then i will party
like never before!
On Tue, 2 Apr 2002, Cliff Woolley wrote:
> The old version for me was giving a res->code of 200, not 500, because it
> was sending the http request to port 8529, not 8530. Maybe it's related
> to the version of LWP I'm using?
strange. i don't think it is lwp related. probably not worth spendin
On 2 Apr 2002 [EMAIL PROTECTED] wrote:
> jwoolley02/04/01 23:20:34
>
> Modified:perl-framework/t/ssl http.t
> Log:
> Okay, well the test works now, but it still fails at the moment because
> mod_ssl really is broken. :)
this patch does not change anything that i can see, both th
On Fri, 18 Jan 2002, Justin Erenkrantz wrote:
> Failed Test Status Wstat Total Fail Failed List of Failed
> ssl/varlookup.t
> 723 4.17% 34, 36-37
>
> 34, 36, and 37 are related to the ciphers in use. It
On Fri, 18 Jan 2002, Stas Bekman wrote:
> any reason for this leading space stripping? If we have a vh block with
> many nested blocks it's nice to preserve the indentation, no? Unless
> this was done for a special reason, this patch keeps the config block as is.
that'll break all of the patter
On Wed, 16 Jan 2002, Sander Temme wrote:
> Hi all,
>
> Built and ran HEAD on Darwin 5.2, and ran the httpd-test perl-framework.
> This dies with the following protest:
>
> server has died with status 255 (please examine t/logs/error_log)
> Terminated
>
> The log says:
>
> [batmobile:perl-fram
On Thu, 10 Jan 2002, Rodent of Unusual Size wrote:
> Doug MacEachern wrote:
> >
> > well, i said it was incomplete, MMN need to be checked too.
>
> I saw that you added it, but I'm not sure how to check it..
my $config = Apache::Test::config();
my $info = $config
On Thu, 10 Jan 2002, Rodent of Unusual Size wrote:
> Um, but it's going to work with 2.0. Please revert your patch
> because it's broken. The test for a 500 return allows the
> test to skip on versions of Apache that don't have the directive
> (like 1.3.22). Your change will cause the skip to b
On Tue, 8 Jan 2002, Rodent of Unusual Size wrote:
> That test shouldn't even *run* for 2.0; it should get a 500
> and skip.
it does run (and fails) with 2.0. i just changed it to require apache
1.x for the moment, which i just realized isn't good enough. should
probably be something like:
my
On Mon, 7 Jan 2002, Rodent of Unusual Size wrote:
> In that case, would anyone object if I occasionally modify tests
> that currently frob .htaccess files so that they use static
> settings (such as separate directories or containers)
> in the t/htdocs/ tree?
if you don't need the config object
On Sun, 6 Jan 2002, William A. Rowe, Jr. wrote:
> Which flavor OS, doug?
win2k (5.00.2195)
> Is there an option to t/TEST to pass the local machine name?
t/TEST -servername foo
On Mon, 7 Jan 2002, Stas Bekman wrote:
> better move it to the top, in case it needs to be used earlier.
not sure what you mean by earlier? i don't see any problems with the way
it is, $parent_pid will be set before any of the subroutines are called.
On Mon, 7 Jan 2002, Stas Bekman wrote:
> I understand. So is that +1 to add Digest::MD5 to the Apache::Test Bundle?
sure, you can add anything to Apache::Test bundle. just need to keep
use of everything in there optional for running t/TEST.
On Mon, 7 Jan 2002, Stas Bekman wrote:
> Sorry, can we put it into the Bundle?
that's fine, but we cannot 'use Digest::MD5' the way it was before. else
'perl Makefile.PL' doesn't work without it.
> Because there can be hundreds of tests in @$ra_tests; Remember that the
> first run by default d
On Mon, 7 Jan 2002, Stas Bekman wrote:
> I needed it TestRun, whereas the fork was happening in TestServer. So it
> was definitely easier to do it locally.
are you saying the following patch would not work?
Index: Apache-Test/lib/Apache/TestRun.pm
==
perl-framework does not work with 5.6.1 due to Digest::MD5 requirement.
i don't see any reason why this:
my $digest = Digest::MD5::md5_hex(join '', @$ra_tests);
cannot just be this:
my $digest = join '', @$ra_tests;
??
On Sun, 6 Jan 2002, Stas Bekman wrote:
>
> That's not very good, because sometimes you want to -v to see all the
> configure tracing, but in most cases we use -v for verbose testing
> output, where we don't want any extra noise, but the debug prints from
> the tests.
ok.
> > i don't think th
On Sun, 6 Jan 2002, Stas Bekman wrote:
> I've done with this:
>
>
> -eval 'END {
> +eval 'my $parent_pid = $$;
> + END {
> + return unless $$ == $parent_pid; # because of fork
ok. i thought is_parent() could be useful elsewhere, but i guess we could
worry about th
On Fri, 4 Jan 2002, Stas Bekman wrote:
> Any idea how to disable the END blocks inheritance in the forked child?
my $Pid = $$;
sub is_parent {
$$ == $Pid;
}
my $pid = fork;
exit unless $pid;
END {
print "END pid=$$\n";
return unless is_parent();
print "stuff\n";
}
prints:
E
i wouldn't object to special casing to make win32 happy. though i find it
odd that things are working ok as-is on my win32 box and on others. is
there any info i can give you about my win32 setup that would help? fwiw
your script outputs the following on my box:
localhost is at 127.0.0.1
127.0.
On Mon, 31 Dec 2001, Stas Bekman wrote:
> Currently there are two tracing mechanisms used in Apache::Test, the
> on/off turning if which is not consistent. This patch replaces the ->trace
> calls with Apache::TestTrace::info().
>
> This patch makes things consistent through using the Apache::Test
On Mon, 24 Dec 2001, Stas Bekman wrote:
> This one preserves the original value of SIGCHLD and uses SIGINT instead
> of 15 in kill().
SIGINT or SIGTERM ?? either way, go with 'kill SIGFOO => $$' so it'll be
easier to get rid of POSIX.pm in the near future.
On Mon, 24 Dec 2001, Stas Bekman wrote:
> I've almost committed the stuff, but then I've tried to apply it to
> httpd-test/perl-framework's t/TEST and couldn't do it because t/TEST had:
>
> %Apache::TestConfig::Argv = qw(apxs /home/stas/httpd/prefork/bin/apxs);
>
> which is not generic (and th
On Mon, 24 Dec 2001, Stas Bekman wrote:
> ok, here it is. Have no clue whether you can re-use this for win32.
+1. i'm sure it can't be used for win32, but hopefully Win32::Process
does the right thing.
> hmm, probably I should use POSIX::SIGINT() instead of 15 in kill.
shame we have to pull
On Mon, 24 Dec 2001, Stas Bekman wrote:
> this patch:
> - s/scan/scan_core/ for consistency with warn_core
> - don't complain aload when an old core from some old run is found
> (i'm tired of remembering to remove old core files)
nice, +1
On Mon, 24 Dec 2001, Stas Bekman wrote:
> if the config token get mistyped, e.g. @servrename@ the current replace()
> sub will simply die without helping to locate which token is unknown to
> Apache-Test. This patch reports the offensive token (of course it'd be
> nice to tell which file it comes
On Sun, 23 Dec 2001, Stas Bekman wrote:
> That means two different ways to add configuration.
yup. because we're doing different things. and for the record: there
are already more than 2 ways to add configuration. tho only one to run
the CONFIGURE routine.
> Why cannot we make the .pm scanne
On Fri, 28 Dec 2001, William A. Rowe, Jr. wrote:
>
> but is anyone familiar with the following failure cases on win32?
all tests were passing for me on win32 before i left on 12/23.
(i won't have access to a win32 box again until 1/4.)
for ssl tests to pass, this line needs to be commented out o
On Fri, 21 Dec 2001, Stas Bekman wrote:
> I was thinking some more about this issue and came to a conclusion that
> there is nothing we should add, since we have already a working solution:
close, but the current .pm scanner a bit too specific to mod_perl in terms
of location (where the .pm's h
On Fri, 21 Dec 2001, Stas Bekman wrote:
> This patch removes the need for t/TEST.PL, t/SMOKE.PL, build/bugreport.pl
> and implements in each set of the classes used by these scripts a
> generate_script() method, which generates these scripts.
nice.
> Issues:
> - should it generate t/REPORT or
On Fri, 21 Dec 2001, Stas Bekman wrote:
> OK, here it is: I've finally called it skip_all() as it's a standalone
> function now.
cool, +1. but would rather it still be called skip_unless()
Crypt::SSLeay crashes with win32 perl 5.6.1, patch below fixes and should
work fine with older perls too..
--- SSLeay.xs~ Wed Oct 31 15:29:59 2001
+++ SSLeay.xs Tue Dec 18 19:30:08 2001
@@ -371,7 +371,7 @@
str = X509_NAME_oneline(X509_get_subject_name(cert));
#endif
RETVA
backwards logic error. has nothing todo with the Makefile or Makefile.PL
try now.
i'll have a look on win32 later, in the meantime you can grab this:
http://perl.apache.org/~dougm/httpd-test-sslca.tar.gz
unpack it inside the httpd-test/perl-framework directory.
and there will be no attempt to use openssl or generate the ca.
openssl is not a requirement, the current code just a
On Fri, 14 Dec 2001, Stas Bekman wrote:
> I didn't suggest to change colors, I suggested to add more methods :)
what i'm saying is there should only be one meaning for each color.
> scream "It's a hit!"; # 'blue'
info is blue.
> whisper "nothing important"; # 'yell
On Fri, 14 Dec 2001, Stas Bekman wrote:
> In Apache::SmokeTest I use warning/error subs from TestTrace to make the
> generated output easy to read and distinguish important prints from less
> important. But of course error and warning aren't the right names to
> use. What's the best thing to do
On Thu, 13 Dec 2001, Rodent of Unusual Size wrote:
> Um, how does t/ssl/basicauth.t know to which port the request should
> be directed? As a f'r instance?
Apache::TestRequest::scheme('https'); sets the default scheme to https
(as does t/TEST -ssl). which underneath triggers the port lookup t
On Fri, 14 Dec 2001, Stas Bekman wrote:
>
> - create the non-existing directories in the path of the file or dir
> - add write_perl_script() - create executable perl-script
+1
On Fri, 14 Dec 2001, Stas Bekman wrote:
> I need to autogenerate a few executable Perl scripts at
> APACHE_TEST_CONFIGURE and have them persist till -clean. So I've added
> this function.
+1
On Thu, 13 Dec 2001, Stas Bekman wrote:
> I guess 'restrictive' wasn't the right word. I've a gut feeling that
> test writers will not remember that it must be a first line and there
> will be no warnings that they've done it wrong (e.g. put it as a seconf
> line). Oh well.
i don't think we sh
On Thu, 13 Dec 2001, Rodent of Unusual Size wrote:
> You know what's popping my corn right now? Trying to
> find out where the flippin' .conf files get a lot of their
> contents. For instance, t/conf/extra.conf contains:
it is generated from this config in extra.conf.in:
ProtocolE
On Thu, 13 Dec 2001, Stas Bekman wrote:
> ok, the only problem with this specific script is that it doesn't belong
> to Apache::Test. It's a bug reporting tool. Hmm, bugreport in modperl
> doesn't use Apache::Test at all. bugreport in httpd-test/perl-framework
> need Apache::Test only to get t
On Thu, 13 Dec 2001, Stas Bekman wrote:
> agreed, but the other suggestion to check the first line of .t is too
> restrictive.
how so? the first line thing is just to say 'scan this file'. if the
magic isn't on the first line, the file isn't scanned.
> Also when you want to get to the CONFIG
On Tue, 11 Dec 2001, Stas Bekman wrote:
nice. but again, build/bugreport.pl would have to be copied for every
project that uses Apache-Test. would be better if there was an
Apache::TestReport module and tiny generated t/REPORT script.
i'm also thinking we should have:
Apache::TestRun->generate
On Wed, 12 Dec 2001, Stas Bekman wrote:
> another idea would be to have a second file for this purpose. So if you
> have foo.t you'd add foo(.t?).conf.in in the same directory with
> whatever things you want. This is a snap to add (we already scan t/conf
> for .in files now we can just scan al
i just added a t/conf/ssl/README with descriptions.
i would hope that the ibm ssl module can understand the same certificates
and keys, as they are standard formats. the same if verisign or other
well known ca were to issue them. what does ibm use for a crypto library?
rsa? openssl? or does ibm
On Tue, 11 Dec 2001, Rodent of Unusual Size wrote:
> What's the point of -ssl_module_name, then, if it means only
> mod_ssl?
i use it for covalent_ssl which supports the same directives as mod_ssl.
i imagine there are others (RedHat?) that can make use of this as well.
we could also extend it to
On Mon, 10 Dec 2001, Rodent of Unusual Size wrote:
-ssl_module_name assumes mod_ssl directives are supported. will any
of the t/ssl/*t. pass with the ibm ssl module? they all assume mod_ssl
directives and then some (e.g. varlookup triggers a call to an optional
function).
if you just need t/TES
On Mon, 10 Dec 2001, Rodent of Unusual Size wrote:
> I have some lines that need to be added to extras.conf, but I'd
> prefer to embed them in the .t file rather than editing extras.conf.in.
> I want to be able to drop in a .t file without having to modify
> any of the existing framework to accomm
On Fri, 7 Dec 2001, Rodent of Unusual Size wrote:
> I'll try it.. Bing! It works! Commit that sucker!
done with a new Apache::TestUtil::chown function, in case we need this
elsewhere in the future.
> But ewww, this is one of those 'we MUST be on the
> same system as the server' things.. :-(
On Fri, 7 Dec 2001, Rodent of Unusual Size wrote:
> @#*&(^(#(&@# windows.. }-(
>
> After a lot of travail I've gotten to the point at which all
> the prerequisites for modules/dav on Windows can be run.
> (Only the Expat bundled with Apache seems to suffice for
> XML::Parser, btw; the Win32 downl
concept sounds great, +1
haven't looked at the code, but i should probably be in a module, like
Apache::TestSmoke. that can either be run with -M or a tiny generated
t/SMOKE (like t/TEST) or from t/TEST. else each project that wants to use
it needs a copy of util/smokerandom.pl
the idea has alway
On Thu, 6 Dec 2001, Rodent of Unusual Size wrote:
> Eh. So why am I not seeing Client-Request-Num in the LWP
> output? Rrrr...
because your are using lwp 5.62?
the change was actually made in 5.61, from Changes:
"- Client-Request-Num renamed to Client-Response-Num"
On Thu, 6 Dec 2001, Rodent of Unusual Size wrote:
> Client-Response-Num: 3
...
> my $request_num = $res->header('Client-Request-Num');
...
> Was that supposed to be 'Client-Response-Num' instead of 'Request'?
no, that's correct for lwp 5.60. i just made a change so both versions
are supported.
On Wed, 5 Dec 2001, Rodent of Unusual Size wrote:
> Now I'm getting this on Linux (RH 5.2 with Perl 5.6.1):
...
> I'm *not* seeing these on more recent Linux versions (also
> with Perl 5.6.*)..
what version of LWP? those tests should be skipped unless >= 5.60
if >= 5.60 output of t/TEST -d lwp
On Tue, 4 Dec 2001, Rodent of Unusual Size wrote:
> Was 'foo' supposed to be a vhost on the current system, or
> was it supposed to be able to be a remote system? The
> latter is my goal (testing things like DAV on Win32 bites
> the Harry Houdini..).
the latter.
On Wed, 5 Dec 2001, Stas Bekman wrote:
> with mnemonic: block until ping and then run? the problem is that ping
> is an exit option, will have to change things a bit.
minor change, see recent commit.
> I still like the new -poll option, since in the future we may extend
> other options funct
On Wed, 5 Dec 2001, Stas Bekman wrote:
> having two places where the test can be told to skip is confusing.
confusing to who? have you forgotten the perl motto?
> So you only want to preserve:
>
>plan tests => $tests, ['lwp', 'cgi'];
and anything else that currently works, like:
plan te
On Wed, 5 Dec 2001, Stas Bekman wrote:
> ok, but that catches only syntax errors. if we can catch the return
> status from system() we can catch all errors, causing the failure.
that would be great.
On Wed, 5 Dec 2001, Stas Bekman wrote:
> I didn't suggest to change how the default -run works (see the patch).
but you did ask:
"- any reason for not making -poll turned on by default for -run?"
> I've suggested a new option -poll, which when used will poll the server
> till it starts. since
On Wed, 5 Dec 2001, Stas Bekman wrote:
> I didn't get you? do you prefer to make this change and disengage skip
> stuff from plan:
>
> skip_unless(...);
> plan tests => $tests;
i'd like it if the current shorthand continues to work:
plan tests => $tests, ['lwp', 'cgi'];
i would not like i
On Wed, 5 Dec 2001, Stas Bekman wrote:
> I suggest having an APACHE_TEST_CRON_MODE env var which will also
> replace APACHE_TEST_NO_COLOR. Sounds OK?
i'd just rather have a different name. this'll be useful for more than
cron. in fact i'd be happy to stick with APACHE_TEST_NO_COLOR.
On Tue, 4 Dec 2001, Stas Bekman wrote:
> Actually, we don't have to run -t to test for failure, since the normal
> execution fails as well and for all cases (not only syntax errors). The
> problem is that we run:
>
>system "command &";
we can run "$cmd -t|" before that and check if the ou
On Thu, 29 Nov 2001, Rodent of Unusual Size wrote:
> modules\\dav
> ssl\\all
modules.dav
ssl.all
should work on both platforms, since '.' will match the / on unix and \ on
win32.
On Fri, 23 Nov 2001, Stas Bekman wrote:
> I've figured out that I have to run many times t/TEST -run
> until it successfully pings the server under t/TEST -d, so I want the
> polling functionality for -run too. Since now we have 3 places where the
> polling happens (start/ping/run), this patch:
i
On Thu, 22 Nov 2001, Stas Bekman wrote:
> I can extend it to engulf the plan() extension that we have added and then
> the only function you will ever call with plan() is skip_unless. I
> think this:
>
> plan ..., skip_unless('cgi', 'lwp');
there's no point in overloading plan anymore then.
one thing we need to "fix" with this new feature is the ability to turn
off this output. for the same reason we have $ENV{APACHE_TEST_NO_COLOR}
to turn off the colors. for when t/TEST output is redirected to a file,
like from a cron job. at the moment t/TEST > test.log outputs a bunch of
"waiti
On Tue, 27 Nov 2001, Gary Benson wrote:
>
> On Tue, 27 Nov 2001, Rodent of Unusual Size wrote:
>
> > Can it be done?
>
> Not without some trickery: loads of the scripts rely on being able to
> write directly to the server root.
we should fix that. the original plan was for this to work:
% t/
On Sat, 1 Dec 2001, Cliff Woolley wrote:
>
> Is this really a bug in httpd, or is it a bug in the test? I think it's a
> bug in the test that only shows up days 1-9 of the month, but I just
> thought I'd check before I went and 'fixed' the test.
bug in the test, fixed. there was another that w
this broke something. i keep getting:
% t/TEST
...
waiting for server to start: ok (waited 0 secs)
...
still waiting for server to warm up: ok (waited 1 secs)
failed to start server! (please examine t/logs/error_log)
and yet the server is running.
On Thu, 29 Nov 2001, Stas Bekman wrote:
> that's not what I meant. Look at the script I've posted:
then add this to your ./.gdbinit:
define myrun
handle SIGPIPE pass
handle SIGPIPE nostop
set auto-solib-add 0
b ap_run_pre_config
run -DONE_PROCESS -d `pwd`/t -f `pwd`/t/conf/httpd.
On Thu, 29 Nov 2001, Stas Bekman wrote:
> How does it live with t/.gdb-test-start, or do you start it manually (I
> mean without t/TEST -d)?
it just works. try it:
% cat .gdbinit
define sr
printf "%s\n", ap_server_root
end
% t/TEST -d
ctrl-c
(gdb) sr
/home/dougm/ap/httpd-test/perl-frame
On Wed, 28 Nov 2001, Stas Bekman wrote:
> I debug different things and with gdb's dynamic libs symbol loading
> slowness now I have to *craft* gdb scripts to do what I want. I cannot
> call them all .gdbinit. Makes sense? In any case Apache-Test already
> generates a gdb script which collides wit
On Thu, 22 Nov 2001, Stas Bekman wrote:
> isn't it "common" only for httpd-test, but not really common for other
> projects using Apache-Test, e.g. mod_perl comes to mind.
nope. Apache::TestCommon::run_write_test could also be used against
mod_perl, php, java, python, ssi, cgi, or anything tha
On Thu, 22 Nov 2001, Stas Bekman wrote:
> I'm documenting the configuration file tokens substitution feature
> (@ServerRoot@, etc). Currently Apache::Test doesn't provide the list of
> valid tokens (and their purpose), neither programmatically nor
> documentally. What would be the best way to appr
1 - 100 of 204 matches
Mail list logo
