Need some help...

2009-06-13 Thread Rob Fugina
I've been away from the list for a while, but now I'm wondering if
everyone else hasn't, as well.  Is anybody still here?

I've been having some trouble writing a couple of modules with object
states recently -- usually I stick to inline states -- and I was
hoping someone here would be able to give me some advice.  Maybe
someone can start by explaining why in the attached program it seems
that the parameters aren't lined up properly with the constants
(OBJECT, SESSION, HEAP, etc...).  The result is a mess...

Thanks,
Rob


objtest.pl
Description: Perl program


Re: Need some help...

2009-06-13 Thread Rocco Caputo

Please turn on warnings.  You are using

  my ($kernel, $self, $heap) = $_[KERNEL, OBJECT, HEAP];

when an array slice is needed

  my ($kernel, $self, $heap) = @_[KERNEL, OBJECT, HEAP];

Note the difference between

1) poerbook:~% perl -e 'my ($a, $b, $c) = $x[0,1,2];'
(no output)

and with warnings on:

1) poerbook:~% perl -we 'my ($a, $b, $c) = $x[0,1,2];'
Multidimensional syntax $x[0,1,2] not supported at -e line 1.
Name "main::x" used only once: possible typo at -e line 1.

--
Rocco Caputo - rcap...@pobox.com


On Jun 13, 2009, at 20:20, Rob Fugina wrote:


I've been away from the list for a while, but now I'm wondering if
everyone else hasn't, as well.  Is anybody still here?

I've been having some trouble writing a couple of modules with object
states recently -- usually I stick to inline states -- and I was
hoping someone here would be able to give me some advice.  Maybe
someone can start by explaining why in the attached program it seems
that the parameters aren't lined up properly with the constants
(OBJECT, SESSION, HEAP, etc...).  The result is a mess...

Thanks,
Rob





Re: Need some help...

2009-06-13 Thread Rob Fugina
A nasty error no doubt due to my rapid attempt at whipping up an
example program.  I've checked my original code suffering from the
problem, and it doesn't suffer from the same problem.

In my other code, I'm still having problems finding the object
reference in the _start handler (or any other, but one thing at a
time...).  Here's the code for _start.

sub _start
{
my ($kernel, $self, $heap) = @_[KERNEL, OBJECT, HEAP];
$kernel->alias_set($heap->{alias}) if defined $heap->{alias};
print Dumper('in _start', $self, $heap);
$kernel->alias_set($self->address);
}

It's failing on the last line, because $self is undef.  The dump in
the line before it, however, shows the object showing up in HEAP's
position, otherwise structured and blessed as it should be.  I also
dump the session object from the main program right after it's
created, and it also looks fine.  Not that I'm familiar with POE
internals, but in particular, the dispatch table shows _start listed
with a reference to the object and its _start method, right where they
were in the sample program previously sent.

Here's the Session creation in case it's useful for verifying
anything...  Not much there yet.

POE::Session->create(
object_states => [
$self => [ qw( _start ) ],
],
heap => {
alias => $params{Alias},
description => $params{Description} || uc($params{Address}),
},
);

If you need to see more code and you're willing to help me further,
I'd be more than happy to share.  Thank you for your quick attention
so far!

Rob


Re: Need some help...

2009-06-13 Thread Rocco Caputo

Sorry, works for me:

% perl -Mstrict -MPOE -MData::Dumper -wle '
quote> my $self = bless { key => "value" };
quote>
quote> POE::Session->create(
quote>   object_states => [ $self => ["_start"] ],
quote>   heap => { alias => "Alias" }
quote> );
quote>
quote> sub _start {
quote>   my ($k, $s, $h) = @_[KERNEL, OBJECT, HEAP];
quote>   print Dumper("in _start", $s, $h);
quote> }
quote>
quote> POE::Kernel->run()'
$VAR1 = 'in _start';
$VAR2 = bless( {
 'key' => 'value'
   }, 'main' );
$VAR3 = {
  'alias' => 'Alias'
};

--  
Rocco Caputo - rcap...@pobox.com



On Jun 13, 2009, at 21:20, Rob Fugina wrote:


A nasty error no doubt due to my rapid attempt at whipping up an
example program.  I've checked my original code suffering from the
problem, and it doesn't suffer from the same problem.

In my other code, I'm still having problems finding the object
reference in the _start handler (or any other, but one thing at a
time...).  Here's the code for _start.

sub _start
{
   my ($kernel, $self, $heap) = @_[KERNEL, OBJECT, HEAP];
   $kernel->alias_set($heap->{alias}) if defined $heap->{alias};
   print Dumper('in _start', $self, $heap);
   $kernel->alias_set($self->address);
}

It's failing on the last line, because $self is undef.  The dump in
the line before it, however, shows the object showing up in HEAP's
position, otherwise structured and blessed as it should be.  I also
dump the session object from the main program right after it's
created, and it also looks fine.  Not that I'm familiar with POE
internals, but in particular, the dispatch table shows _start listed
with a reference to the object and its _start method, right where they
were in the sample program previously sent.

Here's the Session creation in case it's useful for verifying
anything...  Not much there yet.

   POE::Session->create(
   object_states => [
   $self => [ qw( _start ) ],
   ],
   heap => {
   alias => $params{Alias},
   description => $params{Description} ||  
uc($params{Address}),

   },
   );

If you need to see more code and you're willing to help me further,
I'd be more than happy to share.  Thank you for your quick attention
so far!

Rob




Re: Need some help...

2009-06-13 Thread Rob Fugina
I'm attaching my actual module, minus the path (for your convenience),
and a test script that demonstrates the error.  It doesn't suffer from
the original array slice problem.  I've done this before (object
states, that is), but they were fragile even then -- or they are now,
anyway.  I'm sure there's something simple or stupid I'm missing...

Rob


objtest2.pl
Description: Perl program


Controller.pm
Description: Perl program


Re: Need some help...

2009-06-13 Thread Phil Whelan
Hi Rob,

I think you have the POE::Sesssion->create syntax slightly wrong.

This is from the docs

  POE::Session->create(
object_states => [
  $object_1 => { event_1a => "method_1a" },
  $object_2 => { event_2a => "method_2a" },
],
inline_states => {
  event_3 => \&piece_of_code,
},
  );

You have

>POE::Session->create(
>object_states => [
>$self => [ qw( _start ) ],
>],

Which should be

POE::Session->create(
object_states => [
$self => [ qw( _start _start ) ],
],

Though maybe this reads better...

POE::Session->create(
object_states => [
$self => [
_start => "_start",
   ],
],

Hope that helps.

Cheers,
Phil

-- 
Mobile: +1  778-233-4935
Website: http://philw.co.uk
Skype: philwhelan76
Twitter: philwhln
Email : phil...@gmail.com
iChat: philw...@mac.com


Re: Need some help...

2009-06-14 Thread Olivier Mengué
2009/6/14 Phil Whelan 

> Which should be
>
> POE::Session->create(
>object_states => [
> $self => [ qw( _start _start ) ],
>],
>

I'm using this style if my methods have the same name as my events :

POE::Session->create(
   object_states => [
   $self => [ map { ($_, $_) } qw( _start other ) ],
   ],

But I prefer to distinguish event handlers by prefixing them with "_event_",
so I'm using this :

POE::Session->create(
   object_states => [
   $self => [
(map { ("_event$_", $_) } qw( _start _stop )),
(map { ("_event_$_", $_) } qw( tick tock )) ],
   ],


Re: Need some help...

2009-06-15 Thread Doug Greer
Hey all,

I'm just starting to learn POE, so I tried running the attached code and got
this warning:
Constant subroutine Controller::OBJECT redefined at
/usr/local/lib/perl5/site_perl/5.8.8/i686-linux/Params/Validate.pm line 5

It looks to me that the OBJECT constant is from POE is being interfered with
by the OBJECT constant from Params::Validate.  After removing the validate
method, the code seems to run OK.

Output from the code:

Dump params: $VAR1 = {
  'Alias' => 'lamp',
  'Address' => 'aa.aa.aa',
  'Description' => 'Lamp'
};


$VAR1 = 'new object';
$VAR2 = bless( {
 'address' => 'AA.AA.AA'
   }, 'Controller' );
$VAR1 = 'in _start, want object, heap';
$VAR2 = bless( {
 'address' => 'AA.AA.AA'
   }, 'Controller' );
$VAR3 = {
  'description' => 'Lamp',
  'alias' => 'lamp'
};
$VAR1 = 'dump of session';
$VAR2 = bless( [
 {
   'description' => 'Lamp',
   'alias' => 'lamp'
 },
 {},
 {
   '_start' => [
 bless( {
  'address' => 'AA.AA.AA'
}, 'Controller' ),
 '_start'
   ]
 }
   ], 'POE::Session' );



Sincerely,
Doug Greer



On Sat, Jun 13, 2009 at 8:47 PM, Rob Fugina  wrote:

> I'm attaching my actual module, minus the path (for your convenience),
> and a test script that demonstrates the error.  It doesn't suffer from
> the original array slice problem.  I've done this before (object
> states, that is), but they were fragile even then -- or they are now,
> anyway.  I'm sure there's something simple or stupid I'm missing...
>
> Rob
>


test_controller.pl
Description: Binary data


Controller.pm
Description: Binary data


Re: Need some help...

2009-06-16 Thread Phil Whelan
Hi Doug,

> It looks to me that the OBJECT constant is from POE is being interfered with
> by the OBJECT constant from Params::Validate.  After removing the validate
> method, the code seems to run OK.

I think you need one of these...

use POE::Session;

I usually find the POE constants are not imported unless I use this.

Cheers,
Phil

On Mon, Jun 15, 2009 at 9:28 AM, Doug Greer wrote:
> Hey all,
>
> I'm just starting to learn POE, so I tried running the attached code and got
> this warning:
> Constant subroutine Controller::OBJECT redefined at
> /usr/local/lib/perl5/site_perl/5.8.8/i686-linux/Params/Validate.pm line 5
>
> It looks to me that the OBJECT constant is from POE is being interfered with
> by the OBJECT constant from Params::Validate.  After removing the validate
> method, the code seems to run OK.
>
> Output from the code:
>
> Dump params: $VAR1 = {
>   'Alias' => 'lamp',
>   'Address' => 'aa.aa.aa',
>   'Description' => 'Lamp'
>     };
>
>
> $VAR1 = 'new object';
> $VAR2 = bless( {
>  'address' => 'AA.AA.AA'
>    }, 'Controller' );
> $VAR1 = 'in _start, want object, heap';
> $VAR2 = bless( {
>  'address' => 'AA.AA.AA'
>    }, 'Controller' );
> $VAR3 = {
>   'description' => 'Lamp',
>   'alias' => 'lamp'
>     };
> $VAR1 = 'dump of session';
> $VAR2 = bless( [
>  {
>    'description' => 'Lamp',
>    'alias' => 'lamp'
>  },
>  {},
>  {
>    '_start' => [
>  bless( {
>   'address' => 'AA.AA.AA'
>     }, 'Controller' ),
>  '_start'
>    ]
>  }
>    ], 'POE::Session' );
>
>
>
> Sincerely,
> Doug Greer
>
>
>
> On Sat, Jun 13, 2009 at 8:47 PM, Rob Fugina  wrote:
>>
>> I'm attaching my actual module, minus the path (for your convenience),
>> and a test script that demonstrates the error.  It doesn't suffer from
>> the original array slice problem.  I've done this before (object
>> states, that is), but they were fragile even then -- or they are now,
>> anyway.  I'm sure there's something simple or stupid I'm missing...
>>
>> Rob
>
>



-- 
Mobile: +1  778-233-4935
Website: http://philw.co.uk
Skype: philwhelan76
Twitter: philwhln
Email : phil...@gmail.com
iChat: philw...@mac.com


Re: Need some help...

2009-06-16 Thread Rob Fugina
On Tue, Jun 16, 2009 at 10:19, Phil Whelan wrote:
> Hi Doug,
>
>> It looks to me that the OBJECT constant is from POE is being interfered with
>> by the OBJECT constant from Params::Validate.  After removing the validate
>> method, the code seems to run OK.
>
> I think you need one of these...
>
>    use POE::Session;
>
> I usually find the POE constants are not imported unless I use this.

To all -- First, thank you for the assistance.  It is greatly appreciated.

Second, the problem really did turn out to be Params::Validate's
exported symbols interfering with POE's (or POE::Session's) exported
symbols.  My solution was to be selective about what is exported from
Params::Validate (I had been using :types, now I export specific
symbols as needed), and *not* to export OBJECT, instead using
Params::Validate::OBJECT.

Thanks again,
Rob


I need some help with POE::Wheel::Run on Windows

2009-10-01 Thread Rocco Caputo
First, thanks to Andrew Feren, POE::Wheel::Run::Win32 has been merged  
into POE::Wheel::Run.


Andrew has also reported a memory leak POE::Wheel::Run under Windows: 
https://rt.cpan.org/Ticket/Display.html?id=50068

My problem is that I don't know Win32 APIs well enough to say whether  
his patch does any harm.  He's bypassing  
Win32::Console::_SetStdHandle() calls that set STDIN, STDOUT and  
STDERR to the pipes that communicate with the parent process.  It  
seems like reasonable code, but I don't know any better.


Any help would be appreciated.

Thank you.

--
Rocco Caputo - rcap...@pobox.com


Re: I need some help with POE::Wheel::Run on Windows

2009-10-02 Thread Andrew Feren

Hi all,

If it helps anyone the original discussion about adding the 
Win32::Console::_SetStdHandle() and related changes can be found here 
.  
It seems pretty clear that a lot effort went into trying to get the 
original patch right.


I'd really love understand why this code is needed (on not).  So far all 
of my tests have performed identically (other than the leak) with or 
without the _SetStdHandle() calls.


-Andrew

Rocco Caputo wrote:
First, thanks to Andrew Feren, POE::Wheel::Run::Win32 has been merged 
into POE::Wheel::Run.


Andrew has also reported a memory leak POE::Wheel::Run under Windows: 
https://rt.cpan.org/Ticket/Display.html?id=50068


My problem is that I don't know Win32 APIs well enough to say whether 
his patch does any harm.  He's bypassing 
Win32::Console::_SetStdHandle() calls that set STDIN, STDOUT and 
STDERR to the pipes that communicate with the parent process.  It 
seems like reasonable code, but I don't know any better.


Any help would be appreciated.

Thank you.



Re: I need some help with POE::Wheel::Run on Windows

2009-10-02 Thread Olivier Mengué
2009/10/2 Rocco Caputo 

> First, thanks to Andrew Feren, POE::Wheel::Run::Win32 has been merged into
> POE::Wheel::Run.
>
>
Great news !

I'm using POE::Wheel::Run::Win32 with my patch for bug #43995
https://rt.cpan.org/Ticket/Display.html?id=43995

Looks like you applied the patch. Fine!



> Andrew has also reported a memory leak POE::Wheel::Run under Windows:
> https://rt.cpan.org/Ticket/Display.html?id=50068
>
>
My problem is that I don't know Win32 APIs well enough to say whether his
> patch does any harm.  He's bypassing Win32::Console::_SetStdHandle() calls
> that set STDIN, STDOUT and STDERR to the pipes that communicate with the
> parent process.  It seems like reasonable code, but I don't know any better.
>

This part of the code is the most obscure to me and I've still not figured
out why it is required. The comments in the code are not enough for me to
understand.


> Any help would be appreciated.
>

Win32::Job->spawn() has options : stdin, stdout; stderr. Maybe a path to
explore?

Olivier.
http://search.cpan.org/~dolmen/ 


Re: I need some help with POE::Wheel::Run on Windows

2009-10-02 Thread Rocco Caputo

Thanks for pointing that out.  I had forgotten the backstory on it.

It strongly implies that the I/O redirection must be done BEFORE the  
fork() call on Windows, as it seems that fork() communicates stdio to  
exec() inside Perl.  Time for test cases...


--
Rocco Caputo - rcap...@pobox.com


On Oct 2, 2009, at 09:12, Andrew Feren wrote:


Hi all,

If it helps anyone the original discussion about adding the  
Win32::Console::_SetStdHandle() and related changes can be found  
here.  It seems pretty clear that a lot effort went into trying to  
get the original patch right.


I'd really love understand why this code is needed (on not).  So far  
all of my tests have performed identically (other than the leak)  
with or without the _SetStdHandle() calls.


-Andrew

Rocco Caputo wrote:


First, thanks to Andrew Feren, POE::Wheel::Run::Win32 has been  
merged into POE::Wheel::Run.


Andrew has also reported a memory leak POE::Wheel::Run under  
Windows: https://rt.cpan.org/Ticket/Display.html?id=50068


My problem is that I don't know Win32 APIs well enough to say  
whether his patch does any harm.  He's bypassing  
Win32::Console::_SetStdHandle() calls that set STDIN, STDOUT and  
STDERR to the pipes that communicate with the parent process.  It  
seems like reasonable code, but I don't know any better.


Any help would be appreciated.

Thank you.