}
=== END PATCH ===
On Jun 4, 2009, at 7:30 PM, Erick Calder wrote:
sorry, I still own it. I've just been disconnected from the world
a long
time. it will take me a while to get back to you on this but I will
From: Tony Wildish
Date: Thu, 7 May 2009 10:58:12 +0200
To:
Subject:
sorry, I still own it. I've just been disconnected from the world a long
time. it will take me a while to get back to you on this but I will
> From: Tony Wildish
> Date: Thu, 7 May 2009 10:58:12 +0200
> To:
> Subject: Re: Bug in PoCo::Child when PID wraps round (fwd)
&g
Hi,
just checking one more time: is anyone looking after PoCo::Child, or is
it orphaned?
TIA,
Tony.
On Wed, 15 Apr 2009, Tony Wildish wrote:
> Hi,
>
> I sent this to the bug-poe-component-ch...@rt.cpan.org list some time ago
> but it looks like that list is dead. Is there
Hi,
I sent this to the bug-poe-component-ch...@rt.cpan.org list some time ago
but it looks like that list is dead. Is there someone here managing
PoCo::Child?
Cheers,
Tony.
-- Forwarded message --
Date: Tue, 24 Mar 2009 12:56:33 +0100 (CET)
From: Tony Wildish
To: bug-poe
uto - [EMAIL PROTECTED]
put() calls aren't buffered in filters. They are however buffered in
the driver, and they're flushed
On Dec 14, 2006, at 10:26, Mike Schroeder wrote:
We have a POE app that reads multiple input files, reformats them
and the posts them to various binaries wrap
Nicholas Perez wrote:
It really depends on how you are processing the records and sending
them upstream. Could it be your Filter is doing the buffering?
I'm just using the stock PoCo::Child, which uses POE::Filter::Line -- we
are just writing pipe-delimited lines -- nothing fancy.
On
naries wrapped with PoCo::Child that in turn
load the data into our underlying system. The problem we are running
into is that PoCo::Child seems to be buffering two or three records at a
time. Sometimes we have interdependencies between records going into
various loaders, so we need these to be unbu
We have a POE app that reads multiple input files, reformats them and
the posts them to various binaries wrapped with PoCo::Child that in turn
load the data into our underlying system. The problem we are running
into is that PoCo::Child seems to be buffering two or three records at a
time
with my apologies to everyone who has waited so long for this release,
version 1.39 of this module has just been posted to CPAN.
it fixes a number of issues, see the Changes file.
in the coming year I hope to have more time to devote to POE (at present I'm
working 60+ hrs/wk which leaves little t
the STDIN, I send a $c->quit(), (and checking the
process list the process is indeed gone), but something seems to be
hanging on -- POE won't wrap up and clean up after itself -- it just
hangs. I tried using PoCo::DebugShell, but PoCo::DebugShell and
PoCo::Child seem to fight over STDOUT:
> From: Mike Schroeder <[EMAIL PROTECTED]>
> Organization: DonorWare LLC
> Date: Tue, 14 Dec 2004 16:12:31 -0700
> To: <[EMAIL PROTECTED]>
> Subject: PoCo::Child
>
> The PoCo::Child examples all use "ls" as the child program.
Mike, for examples
The PoCo::Child examples all use "ls" as the child program. This is
fine for showing how to work with a child that wants some command line
arguments to generate STDOUT, but I need a solution that lets me write
to STDIN and respond to STDOUT. So I reworked the example to use "
D]
Subject: Re: PoCo::Child
On Thu, 2002-09-19 at 00:49, Erick Calder wrote:
> Rocco thought it'd be useful to have a component made out of
POE::Wheel::Run
> so as to eliminate having to create an interim session just to receive
> events from the wheel... so I've put one togethe
It didn't install for me:
ok 1 - use PoCo::Child
ok 2 - session created
ok 3 - read-only client started
ok 4 - got stdout
ok 5 - second instance
ok 6 - got stderr
ok 7 - done
ok 8 - hard callbacks
ok 9 - interactive client started
ok 10 - client write
ok 11 - quit tested
ok 12 - client rest
14 matches
Mail list logo
