On Tue, 2003-09-30 at 17:12, Stas Bekman wrote:
> > The major non-feature is that you can't have a coprocess; the parent
> > blocks while the child runs.
>
> You mean if you spawn a child from a process spawned by IPC::Run3?
When you spawn a child from the parent, the parent blocks. So in
u
Randy Kobes wrote:
On Tue, 30 Sep 2003, Steve Hay wrote:
Randy Kobes wrote:
[ ... ]
Here's a first stab at a patch to get t/SMOKE running on
Win32. I tried to localize the Win32 changes by putting
them in their own sub. The full functionality is probably
not all there - it still needs
Randy Kobes wrote:
On Tue, 30 Sep 2003, Stas Bekman wrote:
Barrie Slaymaker wrote:
On Sep 30 2003, Stas Bekman wrote:
Isn't IPC::Run3 based on IPC::Run? So if IPC::Run doesn't work...
No, it's smaller, faster, lighter ;)
It's "all new code", no select(). Uses File::Temp
Steve Hay wrote:
Randy Kobes wrote:
On Tue, 30 Sep 2003, Stas Bekman wrote:
Barrie Slaymaker wrote:
On Sep 30 2003, Stas Bekman wrote:
Isn't IPC::Run3 based on IPC::Run? So if IPC::Run doesn't work...
No, it's smaller, faster, lighter ;)
It's "all new code", no select(). Us
Barrie Slaymaker wrote:
On Tue, 2003-09-30 at 17:12, Stas Bekman wrote:
The major non-feature is that you can't have a coprocess; the parent
blocks while the child runs.
You mean if you spawn a child from a process spawned by IPC::Run3?
When you spawn a child from the parent, the parent blocks.
Steve Hay wrote:
So presumably t/SMOKE uses Apache-Test/lib rather than blib/lib?
All our tools try to use the live libs instead of blib, to make it easy to
develop. Imagine how error-prone would it be if one had to remember to run
'make' after a single change is done to a file in lib/ or Apache
Randy Kobes wrote:
On Tue, 30 Sep 2003, Stas Bekman wrote:
Barrie Slaymaker wrote:
On Sep 30 2003, Stas Bekman wrote:
Isn't IPC::Run3 based on IPC::Run? So if IPC::Run doesn't work...
No, it's smaller, faster, lighter ;)
It's "all new code", no select(). Uses File::Temp
temporary files to op
Yupp. It is probably better to stick close to the way httpd does things.
Besides, that VMS behaviour must be a real buggy one if it is the way
that snippet suggests :)
Cheers,
Ayhan
-Message d'origine-
De : Geoffrey Young [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 1 octobre 2003 00
On Wed, 1 Oct 2003, Stas Bekman wrote:
> Randy Kobes wrote:
[ ... ]
> > And that does seem to work! A diff appears below (not tested
> > on linux) - in this, I also added a change to TestServer.pm
> > to print out a message on Win32 when shutting down the
> > server, as that's expected when checki
Stas Bekman wrote:
Steve Hay wrote:
So presumably t/SMOKE uses Apache-Test/lib rather than blib/lib?
All our tools try to use the live libs instead of blib, to make it easy
to develop.
which doesn't work at all for third party XS modules, which is why we have
those extra statements in modper
Randy Kobes wrote:
On Wed, 1 Oct 2003, Stas Bekman wrote:
Randy Kobes wrote:
[ ... ]
And that does seem to work! A diff appears below (not tested
on linux) - in this, I also added a change to TestServer.pm
to print out a message on Win32 when shutting down the
server, as that's expected when che
Geoffrey Young wrote:
Stas Bekman wrote:
Steve Hay wrote:
So presumably t/SMOKE uses Apache-Test/lib rather than blib/lib?
All our tools try to use the live libs instead of blib, to make it
easy to develop.
which doesn't work at all for third party XS modules, which is why we
have those e
Patches are welcome.
BTW, my notebook has a slow HD and running 'make' in modperl-2.0, even
without any compilations takes a minute and even longer.
hey, no fair tossing out the 'patches welcome' mat just because you have a
slow workstation...
:)
--Geoff
-
On Wed, 2003-10-01 at 14:09, Stas Bekman wrote:
> And it doesn't seem to do the right thing. It aborts the child process, but
> leaves the parent running as if it didn't receive SIGINT, causing a false
> failure reports.
Not sure why; IPC::Run uses system() to spawn the child; is the system()
re
Geoffrey Young wrote:
Patches are welcome.
BTW, my notebook has a slow HD and running 'make' in modperl-2.0, even
without any compilations takes a minute and even longer.
hey, no fair tossing out the 'patches welcome' mat just because you have
a slow workstation...
:)
smiley's noted, i wante
Geoffrey Young wrote:
# Define the CRLF sequence. I can't use a simple "\r\n" because the
meaning
# of "\n" is different on different OS's (sometimes it generates CRLF,
sometimes LF
# and sometimes CR). The most popular VMS web server
# doesn't accept CRLF -- instead it wants a LR. EBCDIC machi
+1. also please update modperl-docs/src/docs/2.0/api/Apache/Const.pod.
of course.
Will you please suggest a patch against Randy's patch to use that constant?
it would probably be easier to patch that after it's accepted into core in
it's final form. that way Randy keeps ownership of the bulk of
On Wed, 1 Oct 2003, Geoffrey Young wrote:
>
> >
> > +1. also please update modperl-docs/src/docs/2.0/api/Apache/Const.pod.
>
> of course.
>
> >
> > Will you please suggest a patch against Randy's patch to use that constant?
>
> it would probably be easier to patch that after it's accepted into cor
added Apache::CRLF, Apache::CR, and Apache::LF to
Apache::Const's :platform group
I'll spruce up the test (as promised) and add the required docs tomorrow.
for now, at least randy can use the constants at his leisure...
--Geoff
---
Barrie Slaymaker wrote:
On Wed, 2003-10-01 at 14:09, Stas Bekman wrote:
And it doesn't seem to do the right thing. It aborts the child process, but
leaves the parent running as if it didn't receive SIGINT, causing a false
failure reports.
Not sure why; IPC::Run uses system() to spawn the child
ydnar wrote:
Useless warning in error_log:
[Mon Sep 29 16:43:15 2003] -e: Use of uninitialized value.
This occurs whenever a handler script calls ModPerl::Util::exit()
or simply exit(). There is no other available information.
Running Perl 5.8.0 and mod_perl 1.99.10, both fresh rebuilds from
s
[EMAIL PROTECTED] wrote:
1. Problem Description:
I have trouble getting iniformation from CGI-forms sent by HTTP/POST. To reproduce
the problem; use the testpackage I've written and included in section 5 of this
mail. I've also included what I've found relevant from my mod_perl/Apache-setup
in
Thanks for your
reply.Here's a short module that will throw the warning.Note, my
httpd.conf uses PerlSwitches -wT. Removing -w and using "usewarnings FATAL
=> 'all';" does *not* reproduce the problem.package
SHN::Exit;use strict;use ModPerl::Util;use
Apache::RequestRec;use Apache::RequestIO
ydnar wrote:
Thanks for your reply.
Here's a short module that will throw the warning.
Thanks.
Note, my httpd.conf uses PerlSwitches -wT. Removing -w and using "use
warnings FATAL => 'all';" does *not* reproduce the problem.
That's obvious.
package SHN::Exit;
use strict;
use ModPerl::Util;
use A
> ydnar wrote:
> > Thanks for your reply.
> >
> > Here's a short module that will throw the warning.
>
> Thanks.
>
> > Note, my httpd.conf uses PerlSwitches -wT. Removing -w and using "use
> > warnings FATAL => 'all';" does *not* reproduce the problem.
>
> That's obvious.
Obvious to whom?
> > pa
ydnar wrote:
Note, my httpd.conf uses PerlSwitches -wT. Removing -w and using "use
warnings FATAL => 'all';" does *not* reproduce the problem.
That's obvious.
Obvious to whom?
Sorry, if you turn the warnings off, you get no warnings ;)
Does it make any difference if you do:
- exit 0;
+ ModPer
On Wed, 1 Oct 2003, Geoffrey Young wrote:
> or, I could just commit it now and Randy can decide which
> route to go. I think I'll just do that...
Here's a revised set of tests, using Geoff's implementation
of Apache::CRLF. This also addresses a couple of earlier
comments of Stas - the files used
Randy Kobes wrote:
On Wed, 1 Oct 2003, Geoffrey Young wrote:
or, I could just commit it now and Randy can decide which
route to go. I think I'll just do that...
Here's a revised set of tests, using Geoff's implementation
of Apache::CRLF. This also addresses a couple of earlier
comments of Stas
On Thu, 2 Oct 2003, Randy Kobes wrote:
> Here's a revised set of tests, using Geoff's implementation
> of Apache::CRLF. This also addresses a couple of earlier
> comments of Stas - the files used for comparison are now
> assumed to be found as t/htdocs/perlio/http.pod and
> t/htdocs/perlio/http_cy
Randy Kobes wrote:
On Thu, 2 Oct 2003, Randy Kobes wrote:
Here's a revised set of tests, using Geoff's implementation
of Apache::CRLF. This also addresses a couple of earlier
comments of Stas - the files used for comparison are now
assumed to be found as t/htdocs/perlio/http.pod and
t/htdocs/perl
Randy Kobes wrote:
On Wed, 1 Oct 2003, Geoffrey Young wrote:
or, I could just commit it now and Randy can decide which
route to go. I think I'll just do that...
Here's a revised set of tests, using Geoff's implementation
of Apache::CRLF. This also addresses a couple of earlier
comments of Stas
31 matches
Mail list logo
