Re: t/SMOKE on win32
Stas Bekman wrote:
Steve Hay wrote:
[...]
Any luck with either of the two following patches?
No :-(
I tried them each using a run3 call in TestSmoke.pm that uses a scalar:
my $log = '';
run3 $command, undef, \$log, \$log;
print $log;
and again using a temporary file:
my ($fh, $file) = tempfile(UNLINK => 1);
run3 $command, undef, $file, $file;
local $/;
my $log = <$fh>;
close $fh;
print $log;
both either way both patches still give the "Failed to dup STDOUT" message.
- Steve
Index: src/modules/perl/modperl_io.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_io.c,v
retrieving revision 1.14
diff -u -r1.14 modperl_io.c
--- src/modules/perl/modperl_io.c3 Oct 2003 17:45:23 -1.14
+++ src/modules/perl/modperl_io.c6 Oct 2003 19:12:11 -
@@ -173,6 +173,8 @@
Perl_croak(aTHX_ "Failed to restore STDIN: %_", get_sv("!",
TRUE));
}
+Perl_do_close(aTHX_ handle, FALSE);
+
IoFLUSH_off(handle); /* STDIN's $|=0 */
MP_TRACE_o(MP_FUNC, "end\n");
@@ -193,6 +195,8 @@
if (status == 0) {
Perl_croak(aTHX_ "Failed to restore STDOUT: %_", get_sv("!",
TRUE));
}
+
+Perl_do_close(aTHX_ handle, FALSE);
MP_TRACE_o(MP_FUNC, "end\n");
}
Index: src/modules/perl/modperl_io.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_io.c,v
retrieving revision 1.14
diff -u -r1.14 modperl_io.c
--- src/modules/perl/modperl_io.c3 Oct 2003 17:45:23 -1.14
+++ src/modules/perl/modperl_io.c6 Oct 2003 19:13:25 -
@@ -164,7 +164,7 @@
MP_TRACE_o(MP_FUNC, "start");
-/* Perl_do_close(aTHX_ handle_orig, FALSE); */
+Perl_do_close(aTHX_ handle_orig, FALSE);
/* open STDIN, "<&STDIN_SAVED" or die "Can't dup STDIN_SAVED:
$!"; */
status = Perl_do_open9(aTHX_ handle_orig, "<&", 2, FALSE, O_RDONLY,
@@ -173,6 +173,8 @@
Perl_croak(aTHX_ "Failed to restore STDIN: %_", get_sv("!",
TRUE));
}
+Perl_do_close(aTHX_ handle, FALSE);
+
IoFLUSH_off(handle); /* STDIN's $|=0 */
MP_TRACE_o(MP_FUNC, "end\n");
@@ -185,7 +187,7 @@
MP_TRACE_o(MP_FUNC, "start");
-/* Perl_do_close(aTHX_ handle_orig, FALSE); */
+Perl_do_close(aTHX_ handle_orig, FALSE);
/* open STDOUT, ">&STDOUT_SAVED" or die "Can't dup STDOUT_SAVED:
$!"; */
status = Perl_do_open9(aTHX_ handle_orig, ">&", 2, FALSE, O_WRONLY,
@@ -193,6 +195,8 @@
if (status == 0) {
Perl_croak(aTHX_ "Failed to restore STDOUT: %_", get_sv("!",
TRUE));
}
+
+Perl_do_close(aTHX_ handle, FALSE);
MP_TRACE_o(MP_FUNC, "end\n");
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/SMOKE on win32
Barrie Slaymaker wrote: On Oct 6 2003, Steve Hay wrote: Randy Kobes wrote: test1.pl passes a scalar to run3 test2.pl redirects STDOUT to a scalar and has run3 inherit it Does open STDOUT, '>', \$logout; create a real filehandle at the OS level, or does it use I/O layers to redirect the perl script's output to a scalar? If it's not a real filehandle, system(), and thus IPC::Run3::run3(), can't pass it down to the child. I suspect it's not a real OS filehandle - if I run a Perl script that opens a file and then goes to sleep then when I look at the perl.exe process in Process Explorer (from www.sysinternals.com) I can see the filehandle that it is using. By contrast, if the Perl script "opens" a scalar as above then Process Explorer doesn't show any new OS handle. So that probably explains why test2 doesn't work. test3.pl redirects STDOUT to a scalar and passes that scalar to run3 This works on linux, will test on Win32, rewriting the crucial line to: run3 [ $^X, "-leprint'hi'"], undef, \$logout, undef; I've tried that, i.e. the test3 script is now: = use strict; use warnings; use IPC::Run3; my $savout; open $savout, '>&STDOUT' or die "Can't dup STDOUT: $!\n"; close STDOUT or die "Can't close original STDOUT: $!\n"; my $logout = ''; open STDOUT, '>', \$logout or die "Can't redirect STDOUT: $!\n" run3 [$^X, "-leprint'hi'"], undef, \$logout, undef; close STDOUT or die "Can't close redirected STDOUT: $!\n"; open STDOUT, '>&', $savout or die "Can't restore STDOUT: $!\n"; close $savout or die "Can't close saved STDOUT: $!\n"; print "Captured '$logout' from STDOUT\n"; print "Done\n"; = but it still doesn't work on my WinXP machine. - Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MP2] problem with command line args to perl Makefile.PL (includes patch)
On Monday, October 6, 2003, at 11:43 AM, Stas Bekman wrote:
Andrew Wyllie wrote:
(I'm resending this as I did not see it go through the first time)
I was running into a problem trying to build MP2 with a name other
than mod_perl.so. After poking around for a while I found that the
MP_LIBNAME arg on the command line was not replacing the default
value of mod_perl.so, but just appending it. So if I specify
something
like:
perl Makefile.pl MP_LIBNAME=mod_perl-2.0_cvs
I get back something like:
mod_perl dso library will be built as mod_perl
mod_perl_1.99.10.so
mod_perl static library will be built as mod_perl
mod_perl_1.99.10.a
Anyway, I patched lib/ModPerl/BuildOptions.pm so that you can tell
the script
whether you want to append the command line arg or replace it. The
patch is
included here, but someone should check to make sure that the options
I have
selected as appendable/replaceable are in fact such.
Looks like your choice is good. And thanks for the patch, Andrew. Do
you mind to cleanup up the patch to conform with our style guide (no
tabs, indent 4, and a few other small bits):
http://perl.apache.org/docs/2.0/devel/core/
coding_style.html#Coding_Style_Guide
If not, I'll do that a bit later and commit it
Ok, here it is again with no tabs and 4 space indents (and a couple of
other tweaks.
Is there any preferred way of send the patch - like as an attachment?
I just cut and
pasted it below.
Thanks
Andrew
Index: lib/ModPerl/BuildOptions.pm
===
RCS file: /home/cvspublic/modperl-2.0/lib/ModPerl/BuildOptions.pm,v
retrieving revision 1.21
diff -u -r1.21 BuildOptions.pm
--- lib/ModPerl/BuildOptions.pm 13 Aug 2003 22:54:10 - 1.21
+++ lib/ModPerl/BuildOptions.pm 7 Oct 2003 17:45:55 -
@@ -83,10 +83,15 @@
}
}
-if ($self->{$key}) {
-$self->{$key} .= ' ';
+if ( $table->{$key}->{'append'} ){
+if ($self->{$key}) {
+$self->{$key} .= ' ';
+}
+$self->{$key} .= $val;
+
+} else {
+$self->{$key} = $val;
}
-$self->{$key} .= $val;
print " $key = $val\n" if $opts & VERBOSE;
}
@@ -137,7 +142,7 @@
sub usage {
my $table = table();
-my @opts = map { "$_ - $table->{$_}" } sort keys %$table;
+my @opts = map { "$_ - $table->{$_}->{'val'}" } sort keys %$table;
join "\n", @opts;
}
@@ -151,8 +156,8 @@
s/^\s+//; s/\s+$//;
next if /^\#/ || /^$/;
last if /^__END__/;
-my($key, $val) = split /\s+/, $_, 2;
-$table{'MP_' . $key} = $val;
+my ($key, $append, $val) = split( /\s+/, $_, 3 );
+$table{'MP_' . $key} = {append => $append, val => $val};
}
return \%table;
@@ -166,24 +171,32 @@
1;
+# data format:
+# keyappend description
+# where:
+# key:is the option name
+# append: is whether we want to replace a default option (0)
+# or append the arg to the option (1)
+# desc: descripttion for this option
+
__DATA__
-USE_GTOP Link with libgtop and enable libgtop reporting
-DEBUG Turning on debugging (-g -lperld) and tracing
-MAINTAINER Maintainer mode: DEBUG=1 -DAP_DEBUG -Wall ...
-CCOPTS Add to compiler flags
-TRACE Turn on tracing
-USE_DSO Build mod_perl as a dso
-USE_STATIC Build mod_perl static
-INST_APACHE2 Install *.pm relative to Apache2/ directory
-PROMPT_DEFAULT Accept default value for all would-be prompts
-OPTIONS_FILE Read options from given file
-STATIC_EXTS Build Apache::*.xs as static extensions
-APXSPath to apxs
-AP_PREFIX Apache installation or source tree prefix
-APR_CONFIG Path to apr-config
-XS_GLUE_DIR Directories containing extension glue
-INCLUDE_DIR Add directories to search for header files
-GENERATE_XS Generate XS code based on httpd version
-LIBNAME Name of the modperl dso library (default is mod_perl)
-COMPAT_1X Compile-time mod_perl 1.0 backcompat (default is on)
+USE_GTOP 0Link with libgtop and enable libgtop reporting
+DEBUG 0Turning on debugging (-g -lperld) and tracing
+MAINTAINER 0Maintainer mode: DEBUG=1 -DAP_DEBUG -Wall ...
+CCOPTS 1Add to compiler flags
+TRACE 0Turn on tracing
+USE_DSO0Build mod_perl as a dso
+USE_STATIC 0Build mod_perl static
+INST_APACHE2 0Install *.pm relative to Apache2/ directory
+PROMPT_DEFAULT 0Accept default value for all would-be prompts
+OPTIONS_FILE 0Read options from given file
+STATIC_EXTS0Build Apache::*.xs as static extensions
+APXS 0Path to apxs
+AP_PREFIX 0Apache installation or source tree prefix
+APR_CONFIG 0Path to apr-config
+XS_GLUE_DIR1Directories containing extension glue
+INCLUDE_DIR1Add directories to search for h
Re: [MP2] problem with command line args to perl Makefile.PL (includes patch)
Andrew Wyllie wrote: Ok, here it is again with no tabs and 4 space indents (and a couple of other tweaks. Thanks Andrew, I did a few more tweaks and committed it. Is there any preferred way of send the patch - like as an attachment? I just cut and pasted it below. Normally we prefer it inlined so it's easier to review and comment on specific parts of the patch. Only when the patch includes tabs (which is only the case with patches to code that generate Makefiles) inlining and attaching is needed, so that tabs won't be lost during copy-n-paste rendering the patch broken. __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/src/modules/perl modperl_callback.c
this was committed separately, as it's not really part of the
PerlDefaultPortHandler implementation.
open for discussion, though, is whether we want to keep or remove this kind
of logic from modperl_callback.
as I think about it more, I'm kinda against second-guessing handlers here -
we ought to assume they return what they mean to return. this will be
especially true in protocol handlers, where in order to return status codes
over 600 (which the protocol may very well have) we would need to duplicate
Perl callback logic.
as the test suite passes, and I can't think of a good reason why returning 2
or 914 from a handler ought to really mean OK, I think it is safe to remove
it without causing too much trouble. if somebody complains, we can evaluate
whether what they are doing is legitimate, or whether the EU needs to change
their approach.
in fact, I'm actually in favor of removing HTTP_OK logic too in order to
make things completely protocol-independent (and reusable for all Perl
callbacks) - people shouldn't be returning HTTP_OK from their handler and
thinking it is equivalent to OK.
--Geoff
[EMAIL PROTECTED] wrote:
geoff 2003/10/07 12:16:13
Modified:src/modules/perl modperl_callback.c
Log:
alter modperl_callback so that return values are propagated
to Apache just as they were returned from the Perl callback -
no second-guessing the status the callback wanted to return.
Revision ChangesPath
1.61 +2 -3 modperl-2.0/src/modules/perl/modperl_callback.c
Index: modperl_callback.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_callback.c,v
retrieving revision 1.60
retrieving revision 1.61
diff -u -r1.60 -r1.61
--- modperl_callback.c 2 Oct 2003 17:45:52 - 1.60
+++ modperl_callback.c 7 Oct 2003 19:16:13 - 1.61
@@ -82,9 +82,8 @@
/* ModPerl::Util::exit doesn't return an integer value */
status = OK;
}
-/* assume OK for non-http status codes and for 200 (HTTP_OK) */
-if (((status > 0) && (status < 100)) ||
-(status == 200) || (status > 600)) {
+/* assume OK for 200 (HTTP_OK) */
+if ((status == 200)) {
status = OK;
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/src/modules/perl modperl_callback.c
Geoffrey Young wrote:
this was committed separately, as it's not really part of the
PerlDefaultPortHandler implementation.
open for discussion, though, is whether we want to keep or remove this
kind of logic from modperl_callback.
as I think about it more, I'm kinda against second-guessing handlers
here - we ought to assume they return what they mean to return. this
will be especially true in protocol handlers, where in order to return
status codes over 600 (which the protocol may very well have) we would
need to duplicate Perl callback logic.
as the test suite passes, and I can't think of a good reason why
returning 2 or 914 from a handler ought to really mean OK, I think it is
safe to remove it without causing too much trouble. if somebody
complains, we can evaluate whether what they are doing is legitimate, or
whether the EU needs to change their approach.
in fact, I'm actually in favor of removing HTTP_OK logic too in order to
make things completely protocol-independent (and reusable for all Perl
callbacks) - people shouldn't be returning HTTP_OK from their handler
and thinking it is equivalent to OK.
+1 on removing second guessing for the generic callback.
However we could have special handling for return codes based on the callback
type, so if it's one of the HTTP callbacks we may want to do some special
handling. Granted any guessing proves to bite us somewhere in the long run,
the only reason for not removing it would be breaking someone's mp1 code. But
I guess that's fine as we move to mp2, as long as it's easy to fix for them.
As I pointed out in private email, this is definitely not something we want to
leave exposed:
+sub handler {
+my $r = shift;
+
+my $port = $r->args || Apache::OK;
+
+return int $port;
+}
so the callback mechanism could do the fixing of the return value knowing that
it's a default port callback, without introducing potential errors and
confusion in user's code.
__
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: modperl-2.0/src/modules/perl modperl_callback.c
Stas Bekman wrote:
Geoffrey Young wrote:
this was committed separately, as it's not really part of the
PerlDefaultPortHandler implementation.
open for discussion, though, is whether we want to keep or remove this
kind of logic from modperl_callback.
as I think about it more, I'm kinda against second-guessing handlers
here - we ought to assume they return what they mean to return. this
will be especially true in protocol handlers, where in order to return
status codes over 600 (which the protocol may very well have) we would
need to duplicate Perl callback logic.
as the test suite passes, and I can't think of a good reason why
returning 2 or 914 from a handler ought to really mean OK, I think it
is safe to remove it without causing too much trouble. if somebody
complains, we can evaluate whether what they are doing is legitimate,
or whether the EU needs to change their approach.
in fact, I'm actually in favor of removing HTTP_OK logic too in order
to make things completely protocol-independent (and reusable for all
Perl callbacks) - people shouldn't be returning HTTP_OK from their
handler and thinking it is equivalent to OK.
+1 on removing second guessing for the generic callback.
ok, I'll take it out.
However we could have special handling for return codes based on the
callback type, so if it's one of the HTTP callbacks we may want to do
some special handling. Granted any guessing proves to bite us somewhere
in the long run, the only reason for not removing it would be breaking
someone's mp1 code. But I guess that's fine as we move to mp2, as long
as it's easy to fix for them.
I'd rather not do any guessing. if it comes up, we can examine the issue
and decide who is at fault (the EU or the codebase).
As I pointed out in private email, this is definitely not something we
want to leave exposed:
+sub handler {
+my $r = shift;
+
+my $port = $r->args || Apache::OK;
+
+return int $port;
+}
so the callback mechanism could do the fixing of the return value
knowing that it's a default port callback, without introducing potential
errors and confusion in user's code.
the issue here isn't related to the new hook, but rather my use of setting
the return status based on $r->args - I think $port was getting assigned the
PV value and mod_perl isn't getting the associated IV. int() was just my
workaround.
but yes, it's somewhat of a real issue (though apparently not, if nobody has
reported it yet).
I'll do some investigation and see it I can't fix it for everyone.
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem building mp1 on Win32
On Mon, 6 Oct 2003, Steve Hay wrote: > Hi, > > During the course of testing mp1.29-rc1 I ran into a strange problem, > probably Windows-specific, which I've seen before but never got to the > bottom of. > > I have Apache 1.3.28 installed in C:\apache and Perl 5.8.1 in C:\perl5. > The latter has all the paths in it's Config.pm pointing to C:\perl5 > subdirs, and I have C:\perl5\bin on the PATH (and no other Perl > directories on the PATH). > > I then extract the mp1 source archive into C:\Temp and run: > > perl Makefile.PL APACHE_SRC=C:/apache EAPI > nmake > nmake test > > Normally this works fine, but occasionally I get errors from "nmake". > Under mp1.28 I sometimes get this at the start of the "msdev" command > run by "nmake": > > Compiling... > Apache.c > Apache.xs(1966) : error C2115: '=' : incompatible types > [...] > Error executing cl.exe. > mod_perl.so - 1 error(s), 1 warning(s) > NMAKE : fatal error U1077: 'msdev' : return code '0x1' Hi Steve, This error is from an incompatibility with LARGEFILES support - on about line 1966 of Apache.xs, there's a statcache = r->finfo which is trying to relate two different things with LARGEFILES support on Win32. This is fixed in the cvs. > while under mp1.29-rc1 I got this at the end of the "msdev" command: > > Linking... >Creating library Release/mod_perl.lib and object Release/mod_perl.exp > perl_util.obj : error LNK2001: unresolved external symbol > _Perl_croak_nocontext > [...] > Release/mod_perl.so : fatal error LNK1120: 42 unresolved externals > Error executing link.exe. > mod_perl.so - 180 error(s), 1 warning(s) > NMAKE : fatal error U1077: 'msdev' : return code '0xb4' > > I've finally tracked down what triggers this behaviour (it's the same > trigger in each case), but I can't explain why. If I have another Perl > build installed in C:\perl then I get the above errors; if I haven't > then I don't! > > I suspect that problem is also related to the fact that the other Perl > build that I sometimes have in C:\perl is a threaded Perl (a la > ActivePerl) whereas the one in C:\perl5 is non-threaded, hence the error > regarding "Perl_croak_nocontext" when the wrong Perl setup gets picked > up. (Basically, I prefer the non-threaded Perl for my production work > with mp1, but I also have a threaded Perl kicking around for mp2 testing.) > > Presumably something from the C:\perl installation is being used (in > preference to the C:\perl5 installation that should be being used) if it > is present. Why does this happen? All I have to do is move C:\perl out > of the way (say, to C:\perl.mp2) and it all works fine again. > > Also, why is there a difference between 1.28 and 1.29-rc1 in the way in > which it breaks? Is that related to this change in the ChangeLog?: > > For Win32, keep drive letters in mod_perl.dsp to fix bug, reported > by DH <[EMAIL PROTECTED]>, when compiling mod_perl in > cases where Apache and Perl are on different drives [Randy Kobes]. > > It's not an urgent problem for me since I have a workaround, but mp's > build process really shouldn't be picking up the "wrong" Perl. All the > other CPAN modules I'm using (150+ !) build fine with the other Perl > sitting in C:\perl, so why shouldn't mod_perl? It's something that should be fixed ... It sounds like there's something askew in src\modules\win32\mod_perl.dsp; could you send me (privately) this file, and also src\modules\win32\mod_perl.dsp.orig? Thanks. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
modperl_default_port_handler commit broke mp2's build
Man, you should at least give us a chance to test patches if you post them for review and not rushing to commit them. mp2 now can't be even built. Your patch has several problems. First of all the prototype is wrong, it should be: apr_port_t modperl_default_port_handler(const request_rec *r) since the declaration is: include/http_protocol.h:AP_DECLARE_HOOK(apr_port_t,default_port,(const request_rec *r)) without the const, the build warns and dies. But once you put the const in we have another warning, since (apr_port_t)modperl_callback_per_srv(MP_DEFAULT_PORT_HANDLER, rr, MP_HOOK_RUN_FIRST); discards 'const'. which is not trivial to fix, so I stopped there, removed your change and finished building the project. I don't understand how did it built for you. You aren't running in the maintainer mode, which turns all the compilation warnings into errors? Besides, while looking why this thing is broken, I saw that this is an HTTP hook and has little to do with protocols, since its defined in include/http_protocol.h. So it definitely doesn't belong to the protocols documentation, but should be put together with other HTTP hooks. Also I still fail to see its usability. Both http and ssl already specify the default ports 80 and 443, what other default ports do we have in the HTTP protocol? __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: modperl_default_port_handler commit broke mp2's build
Stas Bekman wrote: Man, you should at least give us a chance to test patches if you post them for review and not rushing to commit them. mp2 now can't be even built. Mea Culpa, it can't be built only with: MP_CCOPTS='-Werror' which you probably don't use. That's the same pragma for C as: use warnings FATAL => 'all'; for Perl, turning all warnings into fatal errors. Any objections if we add this flag along with Wall when MP_MAINTAINER=1 to avoid this kind of problems in the future? __ 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
