POE::Component::Logger roadmap

2010-10-26 Thread Olivier Mengué
Hi POE fans,

POE::Component::Logger provides a session that uses the Log::Dispatch
framework for centralized logging. Once it is spawn, you can simply log
with:

Logger->log('message');
or
Logger->log({ level => debug, message => 'message');


This module was originally written by Matt Sergeant 8 years old. It has a
few
issues that I'm currently fixing as Matt promoted me to co-maintainer.

The code in development is hosted on GitHub:
  http://github.com/dolmen/POE-Component-Logger


I've already published 2 developer releases:
- 1.00_01 a few days ago: added a test suite
- 1.00_02 a few hours ago: more tests, and a major optimization

If you are already a PoCo::Logger user you are invited to test 1.00_02 now.

The next planned release in the next days will be:
- 1.01: same as 1.00_02, but a public release
- 1.10: major internal refactoring to fix RT#62397, a race condition
problem that occurs when logging at $DefaultLevel and $DefaultLevel
(may be there will be a 1.09_01 before if I get some feedback)
- 1.50: add a proper 'shutdown' state (old RT#4062): there was
no proper way before. As a workaround some users were posting
a '_stop' message to the session to tell it to terminate.
This is dirty and this will be deprecated in that release: a message
will be sent to the log at the 'notice' level to alert about the new
API.

I would appreciate your feedback about this plan.

I would also appreciate if you tell me if you are a PoCo::Logger user, and
in
particular if you have a CPAN distribution that uses it: that could help me
to understand how P:C:L is actually used for writing the right regression
tests.

Olivier Mengué, POE::Component::Logger co-maint.


Re: Easy way to daemonize a POE script?

2010-03-10 Thread Olivier Mengué
2010/3/10 Winfried Neessen 

>
> Now I'd like to run it independently, so my question is, is there an
> easy way for me to run a POE
>
> script daemonized (w/o having to use Unix backgrounding/forking)?
>

You'll of course have to use that. But use CPAN packages.

I've used Proc::Daemon successfully with a POE application. But I recommend
to deamonize before starting the POE loop.

Olivier.


Re: unexpected _child(lose) for a detached session from _start

2009-11-20 Thread Olivier Mengué
2009/11/20 Rocco Caputo 

> Agreed, a _child(lose) before the _child(create) is bad.
>

This a case of _child(lose) without any _child(create) ever (neither before
or after).


> It should either be a _child(create)/_child(lose) pair, or nothing in this
> case.

 I'm tempted to go with "nothing" since it would be hard to fix the
> create/lose timing.


I'm tempted to go with "nothing", as the session is declared detached.


> Also the new(detached => 1) seems good, but I admit I haven't given it much
> though yet.  Sometimes I change my mind after thinking about things too
> hard.
>
> If you haven't already, please submit this to bug-...@rt.cpan.org.  I'm
> liable to forget about POE bugs, patches, tests, etc. if they're not in
> POE's bug tracker.
>

See bug #51772.


> Thank you again for all your help.


POE is helping me much, so thanks to you. It helped me to build my
application during the last 9 months. However, debugging is painful and I'm
still tracking a particular bug in my code for 3 weeks now. I just
discovered POE::API::Peek and it looks like it is the toolbox I was looking
for for months.

Olivier.


unexpected _child(lose) for a detached session from _start

2009-11-19 Thread Olivier Mengué
Hi POE fellows,

I'm in the process of rewriting the backend of my POE::Component::Schedule
to make the backend session independent of others session in the system. The
point is that session is just backend stuff, so it should not fire _child
events to the session from which the API may have been called. Also, the
schedule session is a singleton that may be used by multiple session, so it
has no reason for being attached to a particular session.
To achieve that, I'm calling POE::Kernel->detach_myself in the _start
handler of the session. POE does'nt fire _child(create) as I expected.
However I also found out that POE still fires _child(lose).

My opinion is that POE should not fire a _child(lose) event if the session
is detached from its parent in the _start handler as a 'lose' without
'create'/'gain' is inconsistent.
Also it would be better if 'detach => 1' was an argument to
POE::Session->create(): it would make the 'not attached' particularity of
this session more explicit for people reading the code.

Here is a test case that shows the current flawed behavior (tested with POE
1.006, POE 1.280):

use strict;
use warnings;

use Test::More tests => 7;
use POE;

my $_child_fired = 0;

POE::Session->create(
inline_states => {
_start => sub {
$_[KERNEL]->alias_set('First');
pass "_start First";
POE::Session->create(
inline_states => {
_start => sub {
$_[KERNEL]->alias_set('Second');
pass "_start Second";
},
},
);
POE::Session->create(
inline_states => {
_start => sub {
$_[KERNEL]->alias_set('Detached');
pass "_start Detached";
diag "Detaching session 'Detached' from its parent";
$_[KERNEL]->detach_myself;
},
},
);
},
_child => sub {
$_child_fired++;
ok($_[KERNEL]->alias_list($_[ARG1]) ne 'Detached',
"$_[STATE]($_[ARG0]) fired for "
  .$_[KERNEL]->alias_list($_[ARG1]->ID));
},
},
);

POE::Kernel->run();

pass "_child not fired for session detached in _start" unless $_child_fired
!= 2;
pass "Stopped";


Olivier Mengué
http://o.mengue.free.fr/


Debugging not stopping sessions

2009-11-16 Thread Olivier Mengué
Hi,

I'm using POE::Wheel::Run::Win32 0.16 with POE 1.006 on ActivePerl 5.10
(1003).

My POE-based program has a main session which launchs sessions which use a
P::W::R::Win32 to run an external process.
The process are running OK, the output is returned OK, the sig_child is
fired as expected.
Also, the wheel is released and destroyed.

But the problem I have is that the session around the wheel is never
released. This is a problem because I don't want to stop my main session
before all child programs are stopped.

So I wonder what is keeping the session alive.
I've not been able to reproduce the problem with a simple test case

The ASSERT flags I tried are unusable due to the amount of data they print.
I tried to track the session refcount, but it seems to be quite low.

So here is my question: what can I use to track what is keeping the session
alive ? How can I inspect the session (even using private APIs) and the
kernel ?

Olivier.


Bug #50907 blocks ActiveState auto-packaging of POE since May

2009-11-16 Thread Olivier Mengué
Could someone have a look at bug #50907 ?
"t/30_loops/select/connect_errors.t failure on Win32 (blocks ActiveState PPM
auto-packaging)"
http://rt.cpan.org/Public/Bug/Display.html?id=50907


Re: Git

2009-10-26 Thread Olivier Mengué
2009/10/25 Joel Bernstein 

>
> On 25 Oct 2009, at 19:19, Guy Hulbert wrote:
>
>  On Sun, 2009-25-10 at 11:23 -0600, chris fedde wrote:
>>
>>> you might also consider hanging out on irc.perl.org#poe.  Most of the
>>> active developers frequent that channel.
>>>
>>
>> Thanks for letting me know.  I have enough bad habits already that I
>> have not yet had time to master irc ... but if lurking here is fruitless
>> then perhaps I'll have to consider it.
>>
>
> It's not a given. #poe isn't really a chat channel, although some goes on.
> I can understand avoiding IRC as it has the potential to be a distracting
> time-sink but (for me, anyway) it's a much more gratifying and interactive
> way to get in contact with developers (both of POE, and people using POE)
> than the list. You'll find that the learning curve is trivial, and the
> rewards considerable.


And if your reason to not want to try IRC is because you have to install
software, just use this web gateway:
http://widget.mibbit.com/?server=irc.perl.org&channel=%23poe&noServerTab=true&noServerNotices=true&noServerMotd=true&autoConnect=true

Olivier.


Re: Git

2009-10-25 Thread Olivier Mengué
2009/10/25 Rocco Caputo 

> Hello, Guy.  Do you have experience recovering a git clone from years of
> historical mistakes in other version control systems?  I could really use
> that right now.
>
>

> Currently the big hurdle moving to git is repairing damage caused by years
> of newbie mistakes in RCS, CVS, and especially Subversion.  While the
> current repository looks like a standard Subversion layout, it's not so
> historically.  git-svn clone does its best, but the results are a mess.
>

You should ask Philippe Bruhat (BooK), an other french Perl developer and a
friend. At the latest OSDC.fr he has shown me his work on rewriting the
history of a Git repository to rewrite an other one.
He wrote Perl tools for that task :
http://search.cpan.org/dist/Git-FastExport/
It appears he has extensively studied the problems of how an history is
"right" and he wrote an extensive test suite for git-stitch-repo.


Olivier.


Fwd: Which editor(s) or IDE(s) are you using for Perl development?

2009-10-22 Thread Olivier Mengué
Hi,

Gabor Szabo, the Padre team leader, has started a poll about editors/IDE.
See his message below.

Olivier.

-- Forwarded message --
From: Gabor Szabo
Date: 2009/10/21
Subject: Which editor(s) or IDE(s) are you using for Perl development?


Hi,

I am running a poll with the above question.
I'd appreciate if you took 5 seconds and answered it.

http://bit.ly/2V8Ltz

regards
  Gabor
  http://szabgab.com/blog.html


Re: POE::Wheel::Run::Win32 and Win32::Daemon

2009-10-19 Thread Olivier Mengué
2009/10/13 Andrew Feren 

>  I'm not really sure, but I'd guess that the Daemon module isn't
> copying/cloning something that it should.  As a result
> Win32::Daemon::StopService(); is getting called unexpectedly in a DESTROY or
> END block when the child exits.
>

That is probably the reason as there is effectively an END block. Maybe
checking $$ before calling StopServicewould fix the problem. I'll try this.


Re: Communication between a Session and TCP Client Component

2009-10-12 Thread Olivier Mengué
2009/10/11 Dave Schwartz 

> Hi,
>
> Excuse me for spamming a long mail. Stumbled upon POE and want to use
> it for my latest project.
>
>
Don't worry. All messages on this list are usually quite long.


> Is there something obviously wrong here when the user tries to give an
> offset other than 0 or the way I am trying to send data to the server.
> Any advice would be a great help.
>
>
The problem is that you try to send messages to the server before the
connection occured.

Try to modify your program like this:
- create the $server in the _start event of the main session, and store the
id in $_[HEAP]
- make the Connected event send an event 'Connected' to the main session
- create the watcher on the Connected event in the main session

Olivier.


Re: POE::Wheel::Run::Win32 and Win32::Daemon

2009-10-12 Thread Olivier Mengué
2009/10/9 Andreas Altergott 

> Hi,
>

Hi Andreas


> this will be especially interesting for dolman :-)
>

dolmen !


> as already described in previous emails there is a big problem when
> using POE::Wheel::Run::Win32 with Win32::Daemon as a windows service.
> Your service will get a termination request from windows, as soon as any
> child process terminates.
>

Here is the bug I submitted in the POE::Component::Daemon::Win32 queue, for
reference:
https://rt.cpan.org/Ticket/Display.html?id=50020


> This happens because POE::Wheel::Run::Win32 is using the fork() method.

 I do not know how exactly ActiveStates Perl handles the fork() method,
> but it does it different than the system() method.  The system() method
> also creates a child process, but it waits for the child until it
> terminates.  This does not initiate a termination request to the
> service.  Although both do create sub processes.
>
> Speaking in windows terminology one has to say threads instead of
> processes.  So system() is using fork() according to the perldocs.  And
> fork() tries to do a real fork() if it is available.  On windows it is
> not.  So it has to create a thread.  I don't know how it does terminate
> a thread though.  It must be different when you use system(), else it
> wouldn't terminate your service.
>
>
This description is incomplete.
POE::Wheel::Run{,::Win32} on Win32 creates an external process using
Win32::Job and uses the thead created with fork() to monitor the job
(->watch) and report its status.

Win32::Job->watch() does polling (which is awkward when you live in the POE
world) to monitor the subprocess.



> Luckily, using threads is not a blocking process.  It means that your
> POE program can continue working, while the thread is also doing it's
> work.  The only drawback is, that your programs will be windows
> specific.  You can not do a 'use threads;' inside of eval, require or
> any other trick to make it system independent.
>
>  o http://perldoc.perl.org/threads.html
>
> The fast solution is to use threads instead of POE::Wheel::Run::Win32.
>

I think that POE::Wheel::Run{,::Win32} already does this.


>
> use threads;
>
> my $thr = 0;
>
> sub thread {
>return(system("C:/Progs/any.exe"));
> }
>
> ...
>
># inside a POE subroutine that's getting called over and over again
>unless ($thr) {
>print("creating thread\n");
>$thr = threads->create('thread');
>}
>
>if ($thr->is_joinable()) {
>print("thread returned " . $thr->join() . "\n");
>$thr = 0;
>}
>
> ...
>
> I've been reading in some previous mails, that POE::Wheel::Run and
> POE::Wheel::Run::Win32 have been merged.  This is nice to hear :-)
> But in this case it complicates things.  Because now POE::Wheel::Run is
> system independent by using fork().


If you look at the code you'll see that the code path on Win32 is quite
different.
So "merged" does not means "does the same".

Also, the aim of the merge is to make your code system independent (of
course this is not the case when using Win32::Daemon too).

 As described this is not possible
> with Win32::Daemon.  So either it should be noted somewhere, that
> POE::Wheel::Run is not usable from a windows service, or it should be
> split again :-p into POE::Wheel::Run::Win32 using threads instead of
> fork(). ;-)
>


> Maybe this issue is easier to fix, by attacking fork() itself.
> Well, you do not strictly need POE::Wheel::Run, if you do use threads.
> They are not blocking anyway, by doing the test is_joinable().
>
> I'm not sure if this concerns only Win32::Daemon or if it is a global
> windows service problem with Perl using fork().
>

I think that the problem is in Win32::Daemon, for which we don't have the
source (his author, Dave Roth seems to have disappeared without publishing
the source for its latest binary release). See the bug where I have posted a
simple test case that does not involves neither POE,
POE::Wheel::Run{,::Win32}, Win32::Job or POE::Component::Daemon::Win32.


I managed to workarounk the bug by separating the program in two process:
- a service wrapper that uses Win32::Daemon, open a server socket and
launches the real service as a subprocess. When it receive a command from
the service manager it forward it to the child as a message on the socket.
- the real service : connects to the service wrapper socket when it starts
and monitors it with a POE::Component::Client::TCP
I wanted to use Win32 pipes instead of Internet sockets, but I've found
nothing to monitor them with POE (there is no select() on file/pipe handles
in the Win32 world).
Anyway this works because there is exactly only one process launched from
the wrapper, and when the child exits, we want the service to stop which
matches the state change that Win32::Daemon sends.
However this is a really ugly and we will still need one day a fixed
Win32::Daemon.

Olivier Mengué (dolmen).


Re: Upcoming POE Changes

2009-10-12 Thread Olivier Mengué
2009/10/9 Rocco Caputo 

> [This is a repost of 
> http://use.perl.org/~rcaputo/journal/39736
> ]
>
> I've also released Version 1.269_002 to the CPAN for developers who are
> more comfortable with that. Remember: CPAN shells don't install developer
> releases by default.
>

For those that may not be familiar with the CPAN shell features, developer
releases can be installed with the CPAN shell:

cpan> install RCAPUTO/POE-1.269_002.tar.gzMore to Come

>
> There will be more improvements in the future, but that's all for now. Stay
> tuned, and please report any problems you encounter early and often. Thanks!
>
>
I tried 1.269_002 with my test suite for POE::Component::Schedule.
In my test 12-session-ref.t I got this warning:
t\12-session-ref-1.t .. 4/6 Use of uninitialized value $sid in hash element
at C:/STRAWB~1/perl/site/lib/POE/Resource/SIDs.pm line 80.

Olivier.


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: running POE as a windows service

2009-09-30 Thread Olivier Mengué
2009/9/29 Andreas Altergott 

> Hi,
>
> I was trying to find a solution how to run POE applications as a Windows
> service.  I've found two solutions so far, but I am not quite satisfied
> with them.
>

I'm also writing a Win32 service with POE for a few months now. You may have
seen my recent posts on PerlMonks.org.

 o Using Win32::Daemon with POE::Component::Daemon::Win32
>
>   This would be perfect, but Win32::Daemon is not available as a PPM
>   for Perl 5.10.
>
>   POE::Component::Daemon::Win32 is not available as a PPM at all.
>
>   Win32::Daemon for Perl 5.10 is still beta and it seems this project
>   is stalled.  There's no source available to further develop this, is
>   there?
>   
>
>
It is worse: I tried to contact Dave Roth get access to the missing source
and to takeover the maintainership, but he doesn't responds to e-mail and
I've seen no news from his on the net since 2008.

I've managed to build a PPM from the latest binary available (20080324) and
was hoping to build my application on it, even with the risk of not having
the source in case of bug.

However I discovered last week a major Win32::Daemon bug for my application:
an incompatibility with the fork() implementation. See
https://rt.cpan.org/Ticket/Display.html?id=50020

Since yesterday I'm trying to workaround this bug by isolating the service
management part in a separate process that launch my main service code using
Win32::Job. My prototype of this service wrapper is working but I've now to
implement IPC to send events from the wrapper to my POE session in the
wrapped process. I'll post my questions about this in a separate thread.

 o Using instsrv and srvany from Windows.
>
>   This tools do not interact with POE.  They simply kill the service
>   without giving it a chance to stop.
>

That's why I'm not using it.

Olivier.


Re: session not stopping

2009-09-30 Thread Olivier Mengué
2009/9/30 Andreas Altergott 

> It simply does not shut down, although there are no more jobs running
> from my point of view.  I don't understand yet though, how I can check,
> if there is indeed something still keeping it alive.
>
> (replying to the list this time. Grrr)

Do you send the 'shutdown' event to the
POE::Compononent::Win32::ChangeNotify session in your SIGINT handler?


Re: run an interactive command using POE::Wheel?

2009-09-28 Thread Olivier Mengué
> *POE::Kernel::USE_SIGCHLD = sub (){1};

If you want this line to be effective, you have to put it ABOVE the "use
POE" line.
And it is better written that way:
sub POE::Kernel::USE_SIGCHLD { 1 }
The way you wrote it would be less efficient as I expect the function would
not be inlined as a constant.


> Below is my code. If I input CTRL-C when the script asking for a username
or
> password, the script dose not exit even if I use $SIG{CHLD}='IGNORE'. By
'ps
> -ef', I can see that the get_name.pl is in the state of  "zombie" and
> waiting for the parent process to reap.

CTRL+C gives SIGBREAK, not SIGCHLD.
You are correctly handling SIGCHLD in on_child_signal, except, as Nick
pointed:
   $_[KERNEL]->sig_child($pid, 'got_child_signal');

You should add a SIGBREAK handler in on_start:
 $poe_kernel->sig(BREAK => 'on_sig_term');
 $poe_kernel->sig(TERM => 'on_sig_term');

sub on_sig_term
{
  if (exists $_[HEAP]->{job}) {
$_[HEAP]->{job}->kill();
delete $_[HEAP]->{job};
  }
  delete $_[HEAP]->{stdin};
  $poe_kernel->sig_handled();
}

Olivier.


Re: run an interactive command using POE::Wheel?

2009-09-26 Thread Olivier Mengué
2009/9/24 Andreas Altergott 

> Please let me (us on the mailing list ;-) ) know if you do.
>

It would be easier if the mailing list admin would reconfigure the list so
we get poe@perl.org as the recipient when we choose "Reply".
More than once I made the mistake of replying only to the post author.

Olivier.


Re: run an interactive command using POE::Wheel?

2009-09-26 Thread Olivier Mengué
2009/9/25 woosley. xu. 

> besides, if you write the interactive code like this:
>
>my $user = ;
>chomp $user;
>$_[HEAP]->{job}->put("$user");
>my $pass = ;
>chomp $pass;
>$_[HEAP]->{job}->put("$pass");
>
> It won't pop up all the message from the child process until you finished
> all your input. Maybe this is not the right way to do it, I am wondering
> which is the way.
>
> You should do user input in the POE way too: by watching events coming from
STDIN.
Maybe POE::Wheel::ReadLine is what you need.

Olivier.


Re: POE debugging without STDOUT/STDERR ?

2009-09-22 Thread Olivier Mengué
Le 22 septembre 2009 11:42, Olivier Mengué  a
écrit :

> How can I use POE's debugging features without access to STDOUT/STDERR?
>

This was obvious:

close STDOUT;
close STDERR;
open STDOUT, '>>:utf8', "${log_file}.out";
print STDOUT "--\n";
open STDERR, '>>:utf8', "${log_file}.err";
print STDERR "--\n";


POE debugging without STDOUT/STDERR ?

2009-09-22 Thread Olivier Mengué
Hi,

I'm building a Windows service with POE (using
POE::Component::Daemon::Win32). In a service I have no access to
STDOUT/STDERR. The only output I have is my log file (Log::Dispatch::File).

How can I use POE's debugging features without access to STDOUT/STDERR?
I would like to find why a event does not seem to be dispatched.
Is it possible to get a POE state image (sessions, and list of events in the
queue of each session) as a string?

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


Re: POE::Test::Loops 1.020, and upcoming POE releases

2009-07-24 Thread Olivier Mengué
2009/7/24 Rocco Caputo 

> POE::Test::Loops 1.020 has been released.
>

I'm concerned about bug 45158 [1] which is blocking a clean install of POE
on HP-UX.
To summarize, the test POE/Test/Loops/sbk_signal_init.pm is reliyng on the
assumption that sleep() can work while an alarm() is set, which the Perl
documentation clearly warns against, and is effectively not working on
HP-UX.

Also, why did the version number bump from 1.005 to 1.020 ?

[1] http://rt.cpan.org/Ticket/Display.html?id=45158

--
Olivier Mengué
http://search.cpan.org/~dolmen/


Re: POE::Component::Server::TCP bug fixes, possibly incompatible

2009-07-21 Thread Olivier Mengué
Euh, well, I was meaning option A.

But either A or C is good for me.
Option B is too awkward as a bad API would stay forever and would bite any
new Server::TCP user.


Le 21 juillet 2009 12:37, Olivier Mengué  a écrit
:

>
>
> 2009/7/16 Chris 'BinGOs' Williams 
>
>> Anyways, I see three options:
>>
>> a). Make the functionality match the documentation;
>>
>> b). Make the documentation match the functionality;
>>
>> c). Do what dngor suggests and flatten ClientArgs, forget the socket
>>and document as such.
>>
>> Cheers,
>>
>
> As a POE::Component::Server::TCP user (useful to quickly write tests for
> client components), I prefer option C as I complained about 2 months ago :
> http://www.mail-archive.com/poe@perl.org/msg04260.html
>
> Olivier Mengué.
>


Re: POE::Component::Server::TCP bug fixes, possibly incompatible

2009-07-21 Thread Olivier Mengué
2009/7/16 Chris 'BinGOs' Williams 

> Anyways, I see three options:
>
> a). Make the functionality match the documentation;
>
> b). Make the documentation match the functionality;
>
> c). Do what dngor suggests and flatten ClientArgs, forget the socket
>and document as such.
>
> Cheers,
>

As a POE::Component::Server::TCP user (useful to quickly write tests for
client components), I prefer option C as I complained about 2 months ago :
http://www.mail-archive.com/poe@perl.org/msg04260.html

Olivier Mengué.


Re: POE site not displayed correctly under IE7

2009-06-27 Thread Olivier Mengué
It looks like the wiki login does not work correctly.
The login page and the signup/preferences pages says I'm logged in (user
name : Dolmen, user id : 1062), but the other pages don't. When I try to
login, it says the password I defined from the preferences page is invalid.


2009/6/26 Rocco Caputo 

> Thanks for the pointers.  I've updated the templates & header generation
> code to pass validator.w3.org for the front page.  It's a wiki without a
> test suite, so I can't guarantee every page will validate.  In fact, I
> strongly suspect that many pages will fail.  Feel free to patch pages with
> bad content.  There's a login/signup link at the bottom, and it'll enable an
> edit link when you do.
>
> I know some of the cookbook examples are too wide for the content column.
>  I'm going to try to make the content column stretch to accommodate wide
> content.
>
> --
> Rocco Caputo - rcap...@pobox.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 )) ],
   ],


[Announce] POE::Component::Schedule

2009-06-05 Thread Olivier Mengué
Hi,

I just published POE::Component::Schedule, a component that generate alarms
from DateTime::Set objects.
This module is a friendly fork of POE::Component::Cron by Chris Fedde, that
has less dependencies as the cron specific bits are removed.

See https://rt.cpan.org/Ticket/Display.html?id=2 for the history

Olivier Mengué (DOLMEN).


Re: Component::Server::TCP: how to get access to the server's HEAP from a client handler?

2009-05-26 Thread Olivier Mengué
Le 26 mai 2009 16:46, Mark Morgan  a écrit :

> From the P:C:S:TCP docs, it looks like you should be able to do this
> by passing a reference to it via ClientArgs constructor argument.
> You may need to end up weakening it in client, to allow the server
> sessions and anything else the client heap is referring to to be
> reaped.
>
> Mark.
>

I have found a solution using ClientArgs.
However it is currently broken, at least it doesn't work as the
documentation says.

See my code below. I've shown with JSON what I get in ClientConnected args :
- socket is missing
- ARG0 is the given ClientArgs. It would me more useful to get Args
flattened in ARG0..$#_
The documentation for this code has still many TODOs and no one is
complaining on RT so probably not many use it.
http://search.cpan.org/~rcaputo/POE-1.005/lib/POE/Component/Server/TCP.pm#Default_Child_Connection_Sessions

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

#!/usr/bin/perl

use strict;
use warnings;
use Test::More tests => 8;

use JSON 'to_json';

use POE qw(Component::Server::TCP Component::Client::TCP);


my $host = 'localhost';
my $port = 12344;


POE::Component::Server::TCP->new(
  Alias => "server",
  Address   => $host,
  Port  => $port,
  ClientArgs=> [ {} ],
  Started   => sub {
pass "[Server] Started #".$_[SESSION]->ID;
my $server_data = $_[HEAP]->{server_data} = $_[ARG0]; # The hash given
in Args
$server_data->{test} = 42;
  },
  ClientConnected => sub {
# According to the documentation ARG0 is the socket, ARG1 is ClientArgs
# But the doc doesn't match the code :(
# We get ClientArgs in ARG0, but it would be more consistent to get it
flattened
diag(to_json([ @_[ARG0..$#_] ]));
my $server_data = $_[HEAP]->{server_data} = $_[ARG0]->[0]; # The hash
given in Args
pass "[Server] ClientConnected #".$_[SESSION]->ID;
is($server_data->{test}, 42, "Server HEAP access");
  },
  ClientInput => sub {
pass "[Server] ClientInput #".$_[SESSION]->ID;
diag($_[ARG0]);
my $server_data = $_[HEAP]->{server_data};
is($server_data->{test}, 42, "Server HEAP access");
  },
  ClientDisconnected => sub {
pass "[Server] ClientDisconnected #".$_[SESSION]->ID;
$poe_kernel->post('server', 'shutdown');
  },
);

POE::Component::Client::TCP->new(
  Alias => "client",
  RemoteAddress => $host,
  RemotePort=> $port,
  Started   => sub {
pass "[Client] Started";
  },
  Connected => sub {
pass "[Client] Connected";
$_[HEAP]{server}->put("Hello");
$poe_kernel->yield('shutdown');
  },
  ServerInput => sub { },
  Disconnected => sub {
pass "[Client] Disconnected";
  },
);

$poe_kernel->run;

pass 'Stopped';


Component::Server::TCP: how to get access to the server's HEAP from a client handler?

2009-05-26 Thread Olivier Mengué
Hi,

I'm using POE for 3 months now with great pleasure. Thanks to all the
developers!

I'm now playing with TCP client and server.
I've created a POE::Component::Server::TCP which has global state stored in
its HEAP, initialized in the Started event.

How can I get access to that HEAP from the Client* events (ClientConnected
in particular) as those are called from a different session ?
Maybe there is a parent-child relationship between the sessions I could use
to retrieve the server session and call it's ->get_heap() ?.

Below is some sample code that I'm sure you'll help me to complete.

Olivier
dolmen on cpan.org


#!/usr/bin/perl

use strict;
use warnings;
use Test::More tests => 8;

use POE qw(Component::Server::TCP Component::Client::TCP);


my $host = 'localhost';
my $port = 12344;

POE::Component::Server::TCP->new(
  Alias => "server",
  Address   => $host,
  Port  => $port,
  Started   => sub {
pass "[Server] Started #".$_[SESSION]->ID;
$_[HEAP]{test} = 42;
  },
  ClientConnected => sub {
pass "[Server] ClientConnected #".$_[SESSION]->ID;
# How to get access to {test} from the server session's HEAP ?
#is(???, 42, "Server HEAP access");
  },
  ClientInput => sub {
pass "[Server] ClientInput #".$_[SESSION]->ID;
diag($_[ARG0]);
  },
  ClientDisconnected => sub {
pass "[Server] ClientDisconnected #".$_[SESSION]->ID;
$poe_kernel->post('server', 'shutdown');
  },
);

POE::Component::Client::TCP->new(
  Alias => "client",
  RemoteAddress => $host,
  RemotePort=> $port,
  Started   => sub {
pass "[Client] Started";
  },
  Connected => sub {
pass "[Client] Connected";
$_[HEAP]{server}->put("Hello");
$poe_kernel->yield('shutdown');
  },
  ServerInput => sub { },
  Disconnected => sub {
pass "[Client] Disconnected";
  },
);

$poe_kernel->run;

pass 'Stopped';