Randy Kobes wrote:
On Fri, 3 Oct 2003, Randy Kobes wrote:
I've tried testing this, and haven't come across a problem
yet, but this wasn't very extensive, as it's late ...
(Stas, I've kept in the "print $log" statements just
for debugging purposes).
I forgot - similar to an earlier fix for modpe
On Fri, 3 Oct 2003, Randy Kobes wrote:
> I've tried testing this, and haven't come across a problem
> yet, but this wasn't very extensive, as it's late ...
> (Stas, I've kept in the "print $log" statements just
> for debugging purposes).
I forgot - similar to an earlier fix for modperl_io.c,
I in
On Thu, 2 Oct 2003, Stas Bekman wrote:
> Steve Hay wrote:
>
> > BTW, Why is it ">&STDIN"? I would have thought "<&STDIN" makes more
> > sense. Anyway, I tried rebuilding everything with "<&STDIN" and it made
> > no difference - testsuite OK, smoke NOT OK.
>
> Another good catch, I've committed t
Steve Hay wrote:
BTW, Why is it ">&STDIN"? I would have thought "<&STDIN" makes more
sense. Anyway, I tried rebuilding everything with "<&STDIN" and it made
no difference - testsuite OK, smoke NOT OK.
Another good catch, I've committed the fix. Thank you, Steve.
Can you reproduce this problem
Geoffrey Young wrote:
But we could internally shortcut map_to_storage if transhandler has
returned OK, no? Do we really need yet another hook?
I'm kinda against any kind of magic here. apache separates the hooks,
probably for a good reason (even if we can't see it at the moment).
Would it sti
But we
could internally shortcut map_to_storage if transhandler has returned
OK, no? Do we really need yet another hook?
I'm kinda against any kind of magic here. apache separates the hooks,
probably for a good reason (even if we can't see it at the moment).
Would it still be an added value if
Geoffrey Young wrote:
well, from the sounds of Bill's email, map_to_storage is going to run
even if you return OK from a PerlTransHandler, and it's
map_to_storage that consumes the overhead of stat'ing the filesystem
for static files.
but I could be misunderstanding - I haven't looked at the c
well, from the sounds of Bill's email, map_to_storage is going to run
even if you return OK from a PerlTransHandler, and it's map_to_storage
that consumes the overhead of stat'ing the filesystem for static files.
but I could be misunderstanding - I haven't looked at the code yet.
I think not.
Geoffrey Young wrote:
Stas Bekman wrote:
Geoffrey Young wrote:
this is kinda cool, and would eliminate some of the issues mod_perl
had with the core translate handler in 1.3 (namely that it runs no
matter what, wasting processing for mod_perl-only back-ends)
any reason why we don't have a Pe
Stas Bekman wrote:
Geoffrey Young wrote:
this is kinda cool, and would eliminate some of the issues mod_perl
had with the core translate handler in 1.3 (namely that it runs no
matter what, wasting processing for mod_perl-only back-ends)
any reason why we don't have a PerlMapToStorageHandler?
Geoffrey Young wrote:
this is kinda cool, and would eliminate some of the issues mod_perl had
with the core translate handler in 1.3 (namely that it runs no matter
what, wasting processing for mod_perl-only back-ends)
any reason why we don't have a PerlMapToStorageHandler?
What's wrong with doin
Patch worked. Much thanks.
y
- Original Message -
From: "Stas Bekman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "ydnar" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, October 02, 2003 1:48 AM
Subject: Re: [mp2] useless warning on ModPerl::Util::exit()
> Stas Bekman wrot
> snip<
> Perfect, I'm now able to reproduce your problem. Please stay tuned for the
fix.
Thanks. :)
y
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
this is kinda cool, and would eliminate some of the issues mod_perl had with
the core translate handler in 1.3 (namely that it runs no matter what,
wasting processing for mod_perl-only back-ends)
any reason why we don't have a PerlMapToStorageHandler?
I saw run_map_to_storage in Apache::HookRun
Stas Bekman wrote:
Steve Hay wrote:
[...]
This version gets SMOKE running, but it doesn't seem to be able to
keep running.
I have a 1.99_10 build tree in which "nmake test" runs with all
tests successful every time, but when I try "perl t/SMOKE" with
your patch below, I find that one of the te
Steve Hay wrote:
[...]
This version gets SMOKE running, but it doesn't seem to be able to
keep running.
I have a 1.99_10 build tree in which "nmake test" runs with all tests
successful every time, but when I try "perl t/SMOKE" with your patch
below, I find that one of the tests has an error and
Stas Bekman wrote:
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 ;)
So may be we cou
Stas Bekman wrote:
Stas Bekman wrote:
It does not occur when running the t/TEST script. I was not able to
modify
t/response/TestModperl/exit.pm to reproduce either. Hence the example
handler as you requested.
Perfect, I'm now able to reproduce your problem. Please stay tuned for
the fix.
I h
Randy Kobes wrote:
One more issue with IPC/Run3. Since it's not in the core, we have to
optionally require it and die in run_test if it's not available. However
leaving it as 'require IPC::Run3' results in:
Can't locate IPC/Run3.pm in @INC (@INC contains: lib Apache-Test/lib
/home/stas/perl/5.
Stas Bekman wrote:
It does not occur when running the t/TEST script. I was not able to
modify
t/response/TestModperl/exit.pm to reproduce either. Hence the example
handler as you requested.
Perfect, I'm now able to reproduce your problem. Please stay tuned for
the fix.
I haven't figured out wh
20 matches
Mail list logo
