Re: cvs commit: httpd-test/perl-framework/t/modules include.t
* [EMAIL PROTECTED] wrote: > Modified:perl-framework/t/modules include.t > Log: > cross-version updates Thanks. You just forgot to commit echo3.shtml and size.shtml :-) nd
Re: apr_psprintf thread safe?
The question was due to a typo in a hastily written description; At 08:55 PM 1/8/2004, Donald Doane wrote: >The following comment is from apr_lib.h: > > * apr_vformatter does not call out to any other code, it is entirely > * self-contained. This allows the callers to do things which are > * otherwise "unsafe". For example, apr_psprintf uses the "scratch" > * space at the unallocated end of a block, and doesn't actually > * complete the allocation until apr_vformatter returns. apr_psprintf > * would be completely broken if apr_vformatter were to call anything > * that used a apr_pool_t. Similarly http_bprintf() uses the "scratch" s/used a apr_pool_t/used this pool/ > * space at the end of its output buffer, and doesn't actually note > * that the space is in use until it either has to flush the buffer > * or until apr_vformatter returns. > > > >>>Donald Doane wrote: > > > >Can someone please confirm whether or not "apr_psprintf" is thread safe. So the answer is yes, provided that each thread has it's own pool, which is the only sane application design. Apache httpd allocates one pool per thread for each worker, from which the connection and request pools are all created. If the application you are concerned about does the same you are safe. Of course separate pools per thread also eliminates alot of mutex protection on the allocator, which is a very good thing for performance. Bill
Re: sticky preferences in Apache-Test
On Tue, 13 Jan 2004, Stas Bekman wrote: > Randy Kobes wrote: > > > > I haven't worked through this yet, but I find a similar > > problem ... I have two Perls, both of which have mp2 > > installed, but one has the CPAN Apache-Test and the other > > has the cvs Apache-Test installed. In building the > > cvs Apache-Test, I get the first-time dialogue with > > the perl with the CPAN Apache-Test installed, but don't > > get the dialogue with the perl with the cvs Apache-Test > > installed. I'm a bit baffled as to why, as this occurs > > even if I delete the system TestConfigData.pm. > > But CPAN A-T doesn't have this feature, so you must have > installed mp2-cvs on top of it. Also check that you don't > have ~/.apache-test/. I don't have an ~/.apache-test/, and yes, using the perl with the CPAN A-T installed to build the cvs A-T is fine. Where I run into problems in not seeing the configuration dialogue is using the perl with the cvs A-T installed in building the cvs A-T, even if I delete the installed TestConfigData.pm. -- best regards, randy
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm TestRun.pm
Randy Kobes wrote:
On Sun, 11 Jan 2004, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
my Apache is D:\Apache2\bin\Apache.exe, which would
get reported as d:\apache2\bin\apache.exe. If there isn't
an easy way to preserve the case yet still remove such
duplicates, I'll do that - it's not a big deal.
Randy, you are the expert on win32 ;) I have no idea what
method to use to get a consistent case on case-insenstive
file systems. Really I think it's time to extend
File::Spec to handle that and not solve this problem every
time we need to read a filename.
This is an annoyance, for sure ... However, in a sense we
(Apache-Test) have some control over this problem. In
another section we're looking for 'Apache', and then in
TestRun.pm we also look for 'apache'. So both get reported
as being present. However, on Win32, looking for 'apache' is
somewhat misleading, as the default installation (either
binary or source) results in 'Apache'. What about the
following:
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.138
diff -u -r1.138 TestRun.pm
--- lib/Apache/TestRun.pm 11 Jan 2004 15:25:12 - 1.138
+++ lib/Apache/TestRun.pm 13 Jan 2004 14:36:41 -
@@ -1343,11 +1343,13 @@
{
my %choices = ();
+my @tries = Apache::TestConfig::WIN32 ?
+qw(Apache httpd Apache2 httpd2) :
+qw(apache httpd apache2 httpd2);
better less dups, and comments are helpful too ;)
my @tries = qw(httpd httpd2);
# win32 has Apache and Apache2 and not apache and apache2
push @tries, WIN32 ? qw(Apache Apache2) : qw(apache apache2);
for (grep defined $_,
map({ catfile $vars->{$_}, $vars->{target} } qw(sbindir bindir)),
$test_config->default_httpd, which($vars->{target}),
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, $ENV{APACHE2}, map {which($_)} @tries) {
$choices{$_}++ if -e $_ && -x _;
otherwise +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: sticky preferences in Apache-Test
> Are you sure that your not problem is elsewhere?
I have no idea where it's tripping up. here's my nightly build process:
1 - nuke all Apache foo from my perls
$ find /perl/ -name "Apache*" -exec sudo rm -rf {} \;
2 - nuke my apache installs
3 - build each apache
4 - cd mod_perl-2.0 && make realclean && perl Makefile.PL MP_APXS=...
so, essentially I'm starting from a fresh @INC at the start of each night.
but it chokes when apache moves from 2.1 to 2.0, since the binaries are
incompatable. in reality, though, it's probably not using the right httpd
for any but the first iteration.
but even if it is "user error" on my part, I _still_ haven't found a way to
fix it short of purging my entire system of TestConfigData.pm files. and we
shouldn't need to expect users to do this when they upgrade mod_perl or
decide to build mod_perl against a different apache - right now both appear
to be broken.
--Geoff
Re: sticky preferences in Apache-Test
Randy Kobes wrote: On Tue, 13 Jan 2004, Stas Bekman wrote: Geoffrey Young wrote: [ ... ] what I do know, however, is that my nightly builds start with 2.1 then move to 2.0, issuing 'make realclean' between each. for the past few nights, the 2.0 tests don't run because it's loading TestConfigData.pm from my global @INC. at that point, TestConfigData.pm is from the last install, which is a 2.1 install. this seems wrong to me - I have no remedy short of removing TestDataConfig.pm between builds - at I think it would affect users that upgrade as well. Are you sure that your not problem is elsewhere? I see this issue too though with non-mp2 build, just didn't have a chance to work on it yet. How do you build your mp2? It should ignore the custom config already, there must be some glitch. I haven't worked through this yet, but I find a similar problem ... I have two Perls, both of which have mp2 installed, but one has the CPAN Apache-Test and the other has the cvs Apache-Test installed. In building the cvs Apache-Test, I get the first-time dialogue with the perl with the CPAN Apache-Test installed, but don't get the dialogue with the perl with the cvs Apache-Test installed. I'm a bit baffled as to why, as this occurs even if I delete the system TestConfigData.pm. But CPAN A-T doesn't have this feature, so you must have installed mp2-cvs on top of it. Also check that you don't have ~/.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: sticky preferences in Apache-Test
On Tue, 13 Jan 2004, Stas Bekman wrote: > Geoffrey Young wrote: [ ... ] > > what I do know, however, is that my nightly builds start > > with 2.1 then move to 2.0, issuing 'make realclean' > > between each. for the past few nights, the 2.0 tests > > don't run because it's loading TestConfigData.pm from my > > global @INC. at that point, TestConfigData.pm is from > > the last install, which is a 2.1 install. > > > > this seems wrong to me - I have no remedy short of removing > > TestDataConfig.pm between builds - at I think it would affect users that > > upgrade as well. > > Are you sure that your not problem is elsewhere? I see > this issue too though with non-mp2 build, just didn't have > a chance to work on it yet. > > How do you build your mp2? It should ignore the custom > config already, there must be some glitch. I haven't worked through this yet, but I find a similar problem ... I have two Perls, both of which have mp2 installed, but one has the CPAN Apache-Test and the other has the cvs Apache-Test installed. In building the cvs Apache-Test, I get the first-time dialogue with the perl with the CPAN Apache-Test installed, but don't get the dialogue with the perl with the cvs Apache-Test installed. I'm a bit baffled as to why, as this occurs even if I delete the system TestConfigData.pm. -- best regards, randy
Re: sticky preferences in Apache-Test
Geoffrey Young wrote: Stas Bekman wrote: Geoffrey Young wrote: I think the patch below handles that fine for any mp2 builds. I've done some more digging - this patch seems to be required. How does it map on the thought from my previous email: "Let's see if we can stay without making a modperl-2.0 build special. Why? Because it should use the modperl-2.0 build args for any 3rd party modules A-T runs, if it's installed and used. So it's really the same as modperl-2.0's "make test". " I can't really grok what you mean here. what I do know, however, is that my nightly builds start with 2.1 then move to 2.0, issuing 'make realclean' between each. for the past few nights, the 2.0 tests don't run because it's loading TestConfigData.pm from my global @INC. at that point, TestConfigData.pm is from the last install, which is a 2.1 install. this seems wrong to me - I have no remedy short of removing TestDataConfig.pm between builds - at I think it would affect users that upgrade as well. Are you sure that your not problem is elsewhere? I see this issue too though with non-mp2 build, just didn't have a chance to work on it yet. How do you build your mp2? It should ignore the custom config already, there must be some glitch. I'm going to complete the Apache manpages generation and then work on 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: sticky preferences in Apache-Test
Stas Bekman wrote: > Geoffrey Young wrote: > >>> I think the patch below handles that fine for any mp2 builds. >> >> >> >> I've done some more digging - this patch seems to be required. > > > How does it map on the thought from my previous email: > > "Let's see if we can stay without making a modperl-2.0 build special. > Why? Because it should use the modperl-2.0 build args for any 3rd party > modules A-T runs, if it's installed and used. So it's really the same as > modperl-2.0's "make test". " I can't really grok what you mean here. what I do know, however, is that my nightly builds start with 2.1 then move to 2.0, issuing 'make realclean' between each. for the past few nights, the 2.0 tests don't run because it's loading TestConfigData.pm from my global @INC. at that point, TestConfigData.pm is from the last install, which is a 2.1 install. this seems wrong to me - I have no remedy short of removing TestDataConfig.pm between builds - at I think it would affect users that upgrade as well. HTH --Geoff
Re: sticky preferences in Apache-Test
Geoffrey Young wrote:
I think the patch below handles that fine for any mp2 builds.
I've done some more digging - this patch seems to be required.
How does it map on the thought from my previous email:
"Let's see if we can stay without making a modperl-2.0 build special. Why?
Because it should use the modperl-2.0 build args for any 3rd party modules A-T
runs, if it's installed and used. So it's really the same as modperl-2.0's
"make test". "
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.135
diff -u -r1.135 TestRun.pm
--- lib/Apache/TestRun.pm 8 Jan 2004 04:54:06 - 1.135
+++ lib/Apache/TestRun.pm 8 Jan 2004 21:07:01 -
@@ -1291,6 +1291,11 @@
sub custom_config_load {
debug "trying to load custom config data";
+if (Apache::TestConfig::IS_MOD_PERL_2_BUILD()) {
+debug "modperl-2.0 build - ignore any custom config data";
+return;
+}
+
if (my $custom_config_path = custom_config_path()) {
debug "loading custom config path '$custom_config_path'";
--
__
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 TestRun.pm
On Sun, 11 Jan 2004, Stas Bekman wrote:
> Randy Kobes wrote:
[ ... ]
> > my Apache is D:\Apache2\bin\Apache.exe, which would
> > get reported as d:\apache2\bin\apache.exe. If there isn't
> > an easy way to preserve the case yet still remove such
> > duplicates, I'll do that - it's not a big deal.
>
> Randy, you are the expert on win32 ;) I have no idea what
> method to use to get a consistent case on case-insenstive
> file systems. Really I think it's time to extend
> File::Spec to handle that and not solve this problem every
> time we need to read a filename.
This is an annoyance, for sure ... However, in a sense we
(Apache-Test) have some control over this problem. In
another section we're looking for 'Apache', and then in
TestRun.pm we also look for 'apache'. So both get reported
as being present. However, on Win32, looking for 'apache' is
somewhat misleading, as the default installation (either
binary or source) results in 'Apache'. What about the
following:
Index: lib/Apache/TestRun.pm
===
RCS file:
/home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
retrieving revision 1.138
diff -u -r1.138 TestRun.pm
--- lib/Apache/TestRun.pm 11 Jan 2004 15:25:12 - 1.138
+++ lib/Apache/TestRun.pm 13 Jan 2004 14:36:41 -
@@ -1343,11 +1343,13 @@
{
my %choices = ();
+my @tries = Apache::TestConfig::WIN32 ?
+qw(Apache httpd Apache2 httpd2) :
+qw(apache httpd apache2 httpd2);
for (grep defined $_,
map({ catfile $vars->{$_}, $vars->{target} } qw(sbindir bindir)),
$test_config->default_httpd, which($vars->{target}),
- $ENV{APACHE}, which('apache'), which('httpd'),
- $ENV{APACHE2}, which('apache2'), which('httpd2')) {
+ $ENV{APACHE}, $ENV{APACHE2}, map {which($_)} @tries) {
$choices{$_}++ if -e $_ && -x _;
}
my $optional = 0;
--
best regards,
randy
Re: sticky preferences in Apache-Test
>
> I think the patch below handles that fine for any mp2 builds.
I've done some more digging - this patch seems to be required.
--Geoff
>
> Index: lib/Apache/TestRun.pm
> ===
> RCS file:
> /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestRun.pm,v
> retrieving revision 1.135
> diff -u -r1.135 TestRun.pm
> --- lib/Apache/TestRun.pm 8 Jan 2004 04:54:06 - 1.135
> +++ lib/Apache/TestRun.pm 8 Jan 2004 21:07:01 -
> @@ -1291,6 +1291,11 @@
> sub custom_config_load {
> debug "trying to load custom config data";
>
> +if (Apache::TestConfig::IS_MOD_PERL_2_BUILD()) {
> +debug "modperl-2.0 build - ignore any custom config data";
> +return;
> +}
> +
> if (my $custom_config_path = custom_config_path()) {
> debug "loading custom config path '$custom_config_path'";
>
[Fwd: about bugreport of Apache::Test moduleB]
--- Begin Message --- Maybe it will be helpful, see the attachment, bugreport.txt To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: bug report about Apache::Test module Dear Stas Bekman I am not sure if you are the Author of Apache::Test module, maybe the information is helpful for your later update version. The Bug Symtom: // it is one of symtom in ToDo list of Apache::Test, " However if the problem happens during 'make test' for some reason Makefile doesn't abort on exit from test_clean target, no matter if I put exit -1, 0 or 1, and proceeds with run_tests target. probably, since __DIE__ will stop the server." The error happens during "make test", The Reason: I have changed to move and rebuild the distribution to '/tmp/' and repeat the 'make test' phase, but it still doen't work. Then I found the error is caused by "Can't locate Apache/TestRun.pm in @INC" (@INC contains: lib /opt/perl582/lib/5.8. 2/i686-linux /opt/perl582/lib/5.8.2 /opt/perl582/lib/site_perl/5.8.2/i686-linux /opt/perl582/lib/site_perl/5.8.2 /opt/perl582/lib/site_perl .). Because The TestRun.pm has not been installed by "make install", the code has to specify explicitly the path of TestRun.pm without using @INC. (TestRun.m is in the lib/Apache/ of Apache::Test installation directory.) For more information, I am running linux 9, but I reinstalled perl5.8.2 in /opt/perl582 and mod_perl1.29 + apache1.3 in /opt/apache13. --- End Message ---
Re: Perl test framework, TestConfig, and debugging A::T
On Fri, Jan 09, 2004 at 12:46:48PM -0800, Stas Bekman wrote: > Yes, -debug is for debugging the server, not the test suite, so 'perl -d > t/TEST' is correct. Though it seems that we don't reproduce the perl flags > when doing exec. So try to change t/TEST to add -d at the end of the first > line. Ahh, I'll try that the next time I need to get into deep debug mode. William -- Knowmad Services Inc. http://www.knowmad.com
Re: Perl test framework, TestConfig, and debugging A::T
On Thu, Jan 08, 2004 at 12:57:43PM -0800, Stas Bekman wrote: > It's really hard to guess what did you do. As suggested below if you could > create a sample package which reproduces the problem, upload it somewhere > and post the URL here, we could be much more helpful. You should be able to > create this sample package without having any perl modules, only the test > modules. OK, I've put together a package that is posted temporarily to my server[1] which duplicates the problems that I have reported. I have two modules: Apache::TestTest: basic modperl module following the format given at perl.apache.org except converting everything to mp1 Apache::TestCGIApp: a module that uses the CGI::Application framework which runs in an Apache::Registry environment. I don't think this module is necessary to replicate the problems but have included it simply to demonstrate how I am using Apache::Test in my environment. I'm sure there's some weird stuff in there but hopefully you can follow my logic. Please read the testnotes.txt file and the README for installation notes. Thanks, William [1] http://www.knowmad.com/~william/Apache-TestTest-0.01.tar.gz -- Knowmad Services Inc. http://www.knowmad.com
