Re: RFC: Persistent Object Client/Server Scheme

2003-02-11 Thread philip

On 11-Feb-2003 Rocco Caputo wrote:
 Would a server helper module like OOPersistServer be a
 candidate to be a genuine POE::Component::Server?
 
 The lack of response to this message seems to indicate no. :(

In my case, lack of response means I'm busy.  Object persistance is
something I've wrestled with often.  My latest stab was for JAAS (just
another application server).

I have some ideas about object persistance that I would like to share, but
lack of tuits has held me back.

-Philip



RE: POE::Wheel::Run ErrorEvent

2003-02-11 Thread Robert . Casey
 That output indicates ErrorEvent has been triggered twice.  The first
 time when the child process closes STDERR, and the second time when it
 closes STDOUT.  I added some extra output to the sample code:

Based upon your earlier comments, this is as I had expected.  What does
concern me however is that the dying of the executed program, which an
associated error return value, is not triggering an error event.

my $task = POE::Wheel::Run-new(
'Program'   =  'perl -e die',
'CloseEvent'=  'close',
'ErrorEvent'=  'error',
'StderrEvent'   =  'output',
'StdoutEvent'   =  'output',
'StderrFilter'  =  POE::Filter::Stream-new,
'StdoutFilter'  =  POE::Filter::Stream-new
);

This I would expect should trigger an error event - Or are my expectations
incorrect here?  Alternatively, what would be another way to obtain the
return value for a program executed through POE::Wheel::Run?

Regards,
Rob


Rob Casey
Implementation Analyst
Essential and Direct Mail Development
Hermes Precisa Australia (Victoria)
Phone : (03) 9217-5501
Email : [EMAIL PROTECTED]
 

-Original Message-
From: Rocco Caputo [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 12, 2003 12:10 AM
To: [EMAIL PROTECTED]
Subject: Re: POE::Wheel::Run ErrorEvent


On Tue, Feb 11, 2003 at 02:05:55PM +1100, [EMAIL PROTECTED] wrote:
  2. I am surprised that ErrorEvent is not triggered in that case.  Are
  you using POE 0.25?  If there is a problem in Wheel::Run, it would
  help greatly if you could submit a test case that reproduces it.
 
 I was running 0.24 on my system - I have updated this to 0.2501 from CVS
and
 the error persists.
 
 robin:/users/rc6286/workspace/dev/perl/pas  perl test.perl
 Output: Died at -e line 1.
 $VAR1 = 'read';
 $VAR2 = '0';
 $VAR3 = '';
 $VAR4 = 2;
 $VAR5 = 'STDERR';
 $VAR1 = 'read';
 $VAR2 = '0';
 $VAR3 = '';
 $VAR4 = 2;
 $VAR5 = 'STDOUT';

That output indicates ErrorEvent has been triggered twice.  The first
time when the child process closes STDERR, and the second time when it
closes STDOUT.  I added some extra output to the sample code:

[...]

'close'  =  sub { delete $_[ HEAP ]-{'_task'}; print closed\n;
},
'error'  =  sub { print error:\n,Dumper( @_[ ARG0 .. ARG4 ] ) },

Here's the new output, first using perl 5.005_03, and then using 5.6.1.

  2) eyrie:~/public_html/tmp% perl5.00503 robt-casey-errorevent.perl
  Output: Died at -e line 1.
  error:
  $VAR1 = 'read';
  $VAR2 = '0';
  $VAR3 = '';
  $VAR4 = 2;
  $VAR5 = 'STDOUT';
  error:
  $VAR1 = 'read';
  $VAR2 = '0';
  $VAR3 = '';
  $VAR4 = 2;
  $VAR5 = 'STDERR';
  closed

  2) eyrie:~/public_html/tmp% perl robt-casey-errorevent.perl
  Output: Died at -e line 1.
  error:
  $VAR1 = 'read';
  $VAR2 = '0';
  $VAR3 = '';
  $VAR4 = 2;
  $VAR5 = 'STDERR';
  error:
  $VAR1 = 'read';
  $VAR2 = '0';
  $VAR3 = '';
  $VAR4 = 2;
  $VAR5 = 'STDOUT';
  closed

-- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/



**
IMPORTANT
The contents of this e-mail and its attachments are confidential and intended
solely for the use of the individual or entity to whom they are
addressed.  If you received this e-mail in error, please notify
the HPA Postmaster, [EMAIL PROTECTED], then delete 
the e-mail.

This footnote also confirms that this e-mail message has been swept for
the presence of computer viruses by MimeSweeper.  Before opening or
using any attachments, check them for viruses and defects.

Our liability is limited to resupplying any affected attachments.

HPA collects personal information to provide and market our services.
For more information about use, disclosure and access see our Privacy
Policy at www.hpa.com.au
**




RE: RFC: Persistent Object Client/Server Scheme

2003-02-11 Thread Erick Calder
 In my case, lack of response means I'm busy

I'll second that motion.  I do have an interest in this idea and will reread
the original message before commenting but given that Philip mentions object
persistence I should just hit that I'm working at a schema layer, perhaps
similar to Java Entity Beans.  someday I foresee a nice mixture of this with
IKC to do replication stuff.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 11, 2003 12:06 AM
To: Rocco Caputo; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: RFC: Persistent Object Client/Server Scheme



On 11-Feb-2003 Rocco Caputo wrote:
 Would a server helper module like OOPersistServer be a
 candidate to be a genuine POE::Component::Server?

 The lack of response to this message seems to indicate no. :(

In my case, lack of response means I'm busy.  Object persistance is
something I've wrestled with often.  My latest stab was for JAAS (just
another application server).

I have some ideas about object persistance that I would like to share, but
lack of tuits has held me back.

-Philip