Problem with MPD client but probably POE user error

2014-02-04 Thread John

Hello,

I am working with POE::Component::Client::MPD for the first time and 
attempting to get the example provided working.  I have modified it 
along the way but results have been the same (code is below).


The MPD (Music Player Daemon) logging shows the client connect and 
disconnect (when I control-c).  However, none of the events I send get 
to the daemon (also running on localhost with default port).  I added 
print statements at pretty much all the entry points for events within 
MPD.pm and none of them get hit.  Therefore maybe this is not a problem 
with MPD.pm but my usage of POE.


Also note that I can use the command line client that comes with MPD to 
interact with the daemon and that works as expected as well as it 
generates logging information.


Which direction should I go in to track it down?

Thanks,

John

#!/usr/bin/env/perl 

# 



use warnings;
use strict;

use FindBin qw{ $Bin };
use lib "$Bin/../lib";

use POE;
use POE::Component::Client::MPD;

POE::Component::Client::MPD->spawn( {
alias  => 'mpd',
} );

POE::Session->create(
inline_states => {
_start => \&start,
_stop  => sub { print "bye-bye\n"; },
mpd_result => \&result,
mpd_error => \&error,
status_msgs_to => \&clutter,
}
);
POE::Kernel->run;
exit;


sub start {
my $k = $_[KERNEL];
$k->alias_set('client'); # increment refcount 


print "hello there\n";
$k->post( 'mpd' => 'current' );
$k->post( 'mpd', 'coll:all_files' );
print "done with start\n";

}

sub result {
print "yeah!\n";
}

sub error {
print "got an error\n";
}

sub clutter {
print "got some clutter!\n";

}


Re: Problem with MPD client but probably POE user error

2014-02-04 Thread Rocco Caputo
Hi, John.

I don't see anything obviously wrong in the code you provided.  I don't have 
MPD, and I'm not familiar with the module you're using, but I can offer some 
general POE advice.

POE has some debugging switches, documented in POE::Kernel.  I recommend at 
least enabling: ASSERT_EVENTS, ASSERT_USAGE, and ASSERT_RETVALS.  You can do 
this in your shell:

export POE_ASSERT_EVENTS=1
export POE_ASSERT_USAGE=1
export POE_ASSERT_RETVALS=1

Or to turn them all on (and a bit more) in one fell swoop:

export POE_ASSERT_DEFAULT=1

Then run your program.  Hopefully POE will warn you about something relevant.

-- 
Rocco Caputo 

On Feb 4, 2014, at 07:56, John  wrote:
> 
> none of the events I send get 
> to the daemon (also running on localhost with default port).

> maybe this is not a problem 
> with MPD.pm but my usage of POE.
> 
> I can use the command line client that comes with MPD to 
> interact with the daemon and that works as expected as well as it 
> generates logging information.



Re: Problem with MPD client but probably POE user error

2014-02-04 Thread John

Thanks!

I updated modules to latest and changed the program since I sent the 
original email.  Below is output with ASSERT set.


No problem if nothing leaps out as I am still working it.


With POE_ASSERT_DEFAULT=1:

hello there
bye-bye
=== 2437 === Please address any warnings or errors above this message,
=== 2437 === and try again.  If there are no previous messages, or they
=== 2437 === are from within POE, then please mail them along with the
=== 2437 === following information to bug-...@rt.cpan.org:
---
 Cannot resolve ``mpd'' into a session reference
-
 at ./client.pl line 36.
main::start(undef, POE::Session=ARRAY(0x2b3b188), 
POE::Kernel=ARRAY(0x15801a0), HASH(0x11e4590), "
_start", POE::Kernel=ARRAY(0x15801a0), undef, 
"/usr/lib64/perl5/site_perl/5.12.4/POE/Kernel.pm", 1479, ...

) called at /usr/lib64/perl5/site_perl/5.12.4/POE/Session.pm line 464
POE::Session::_invoke_state(POE::Session=ARRAY(0x2b3b188), 
POE::Kernel=ARRAY(0x15801a0), "_start",
 ARRAY(0x167b968), "/usr/lib64/perl5/site_perl/5.12.4/POE/Kernel.pm", 
1479, undef) called at /usr/lib64/pe

rl5/site_perl/5.12.4/POE/Kernel.pm line 1067
eval {...} called at 
/usr/lib64/perl5/site_perl/5.12.4/POE/Kernel.pm line 1066
POE::Kernel::_dispatch_event(POE::Kernel=ARRAY(0x15801a0), 
POE::Session=ARRAY(0x2b3b188), POE::Ses
sion=ARRAY(0x2b3b188), "_start", 4, ARRAY(0x167b968), 
"/usr/lib64/perl5/site_perl/5.12.4/POE/Kernel.pm", 1
479, undef, ...) called at 
/usr/lib64/perl5/site_perl/5.12.4/POE/Kernel.pm line 1476
POE::Kernel::session_alloc(POE::Kernel=ARRAY(0x15801a0), 
POE::Session=ARRAY(0x2b3b188)) called at

/usr/lib64/perl5/site_perl/5.12.4/POE/Session.pm line 192
POE::Session::try_alloc(POE::Session=ARRAY(0x2b3b188)) called 
at /usr/lib64/perl5/site_perl/5.12.4

/POE/Session.pm line 373
POE::Session::create("POE::Session", "inline_states", 
HASH(0x11bffd8)) called at ./client.pl line

24




On 02/04/14 10:24, Rocco Caputo wrote:

Hi, John.

I don't see anything obviously wrong in the code you provided.  I don't have 
MPD, and I'm not familiar with the module you're using, but I can offer some 
general POE advice.

POE has some debugging switches, documented in POE::Kernel.  I recommend at 
least enabling: ASSERT_EVENTS, ASSERT_USAGE, and ASSERT_RETVALS.  You can do 
this in your shell:

export POE_ASSERT_EVENTS=1
export POE_ASSERT_USAGE=1
export POE_ASSERT_RETVALS=1

Or to turn them all on (and a bit more) in one fell swoop:

export POE_ASSERT_DEFAULT=1

Then run your program.  Hopefully POE will warn you about something relevant.





Re: Problem with MPD client but probably POE user error

2014-02-05 Thread John

On 02/05/14 10:36, Nick Perez wrote:

It has probably failed to connect to mpd. I would make sure you define
status_msg_to and see that you are actually getting this connected
event. Also make sure mpd is actually listening where you think it is.
For example it could be listening on IPv6 localhost.


Thanks...in the code I provided in the original email I think I 
addressed these points.  Summarizing, when running mpd in the foreground 
with verbose logging on I can see the the connect from the client and 
the disconnect when I control-c out of the client.  The event 
"status_msg_to is defined and nothing is sent it.


In the assert output here is the error:  Cannot resolve ``mpd'' into 
a session reference.


Digging through the Kernel.pm code, it seems POE is trying to resolve 
'mpd' to a session reference through various methods but it cannot.  So 
I added Dumper output before the attempt to do the post to 'mpd'.  Based 
on my review it does seem like session exists and has correct alias:



$VAR1 = bless( [
 {
   '1' => [
bless( [
 {
   'alias' => 'mpd'
 },
 {
   'default' => 1
 },
 {
   '_parent' => [
  bless( {

'session_id' => 1,
   'heap' 
=> $VAR1->[0]{'1'}[0][0]
 }, 
'POE::Component::Client::MPD' ),

  'PARENT'
],
   'mpd_error' => [

$VAR1->[0]{'1'}[0][2]{'_parent'}[0],
'mpd_error'
  ],
   'mpd_disconnected' => [

$VAR1->[0]{'1'}[0][2]{'_parent'}[0],

'mpd_disconnected'
 ],

[snip]

So, based on what I see this doesn't make much sense.  Next step for me 
based on my level of knowledge is to start hacking these to gain some 
insight.  If anyone has better direction please let me know.


John




[SOLVEDish] Re: Problem with MPD client but probably POE user error

2014-02-06 Thread John



So, based on what I see this doesn't make much sense.  Next step for me
based on my level of knowledge is to start hacking these to gain some
insight.  If anyone has better direction please let me know.


I added some print statements in POE's Aliases.pm in the sub 
_data_alias_resolve to see what aliases POE thought existed at any point 
in time.  It turns out that at the time _start is executed the mpd alias 
was not registered yet!  I figure it is timing and not location.


Anyway, for debugging purposes I added a delayed event and that worked!

I will work with it to get a better understanding if it is timing or 
just having it in _start but it seems I should be good not rushing things.


John


Re: [SOLVEDish] Problem with MPD client but probably POE user error

2014-02-06 Thread Rocco Caputo
On Feb 5, 2014, at 16:27, John  wrote:

> I added some print statements in POE's Aliases.pm in the sub 
> _data_alias_resolve to see what aliases POE thought existed at any point 
> in time.  It turns out that at the time _start is executed the mpd alias 
> was not registered yet!  I figure it is timing and not location.
> 
> Anyway, for debugging purposes I added a delayed event and that worked!
> 
> I will work with it to get a better understanding if it is timing or 
> just having it in _start but it seems I should be good not rushing things.

I didn't notice this problem because I expected POE::Component::MPD to set its 
own alias in its own _start routine.

_start is called before POE::Session->create() returns.  The predictable timing 
can be used to avoid problems like this.

-- 
Rocco Caputo