Re: Is the web site down?

[Matt Sickler]

The website should be fully functional, but it appears the server is down.
Try again later. :/

On Mon, Apr 7, 2008 at 9:51 AM, Ian Docherty <[EMAIL PROTECTED]> wrote:

> Apologies if this has already been asked, I have only just joined the
> mailing list.
>
>
>
> Am I correct in thinking the official web site is http://poe.perl.org
>   and that the site is not working?
>
>
>
> Does anyone know how to get it fixed?
>
>
>
> Regards
>
> Ian
>
> This email is confidential and intended solely for the use of the
> individual to whom it is addressed. Any views or opinions presented are
> solely those of the author and do not necessarily represent those of RedBee
> Media Metadata. If you are not the intended recipient, be advised that you
> have received this email in error and that any use, dissemination,
> forwarding, printing, or copying of this email is strictly prohibited. If
> you have received this email in error please notify the sender.
>
> Red Bee Media Metadata is a trading name of Broadcasting Dataservices
> Limited.
> Registered in England and Wales No.: 2554733. Registered Office: 201 Wood
> Lane, London W12 7TP, UK.
> Broadcasting Dataservices Limited is a wholly owned subsidiary of Red Bee
> Media Limited.
>
>

Re: POE 1.0 released!

[Matt Sickler]

I too thought this was a joke, then I realized the timestamp was last night.

[virutal] BEERS for all involved!  Great Job everyone!

On Tue, Apr 1, 2008 at 10:26 AM, Randal L. Schwartz <[EMAIL PROTECTED]>
wrote:

> > ""John" == "John R " <[EMAIL PROTECTED]> writes:
>
> "John> Rocco Caputo wrote:
> >> 1 April 2008
>
> "John> Am I the only one that thought this was a joke?  :)
>
> It's often a bad idea to announce anything on 1 April, especially if
> it's unusual. :)
>
> "John> Great job everyone involved!!
>
> Indeed!
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
> 0095
> <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
> See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl
> training!
>

Re: calling $poe_kernel more than once

[Matt Sickler]

Go right ahead.  run() doesn't return until the POE loop completely
shutsdown, so its somewhat pointless.
IIRC, the wiki has an example where it does make sense.

On Fri, Mar 14, 2008 at 3:54 PM, Yuri Shtil <[EMAIL PROTECTED]> wrote:

> What will happen if $poe_kernel->run called more than once?
>
> If this is bad, is there a way to detect that the loop is already active.
>
> -- Yuri
>

Re: concurrency and Server::TCP

[Matt Sickler]

Also, ClientInput is a callback specific to the POE::Session that handles a
single connection.
POE is a multitasking environment, not a threaded one - so you are going to
only be processing one line of code at a time anyway.

On Wed, Feb 13, 2008 at 5:28 PM, vidals <[EMAIL PROTECTED]> wrote:

> I have an app that I wrote which is sensitive to being overwhelmed by
> POE's multitasking. I couldn't figure out a way to "slow" it down and
> run serially, so I set Concurrency = 1 like so:
>
> POE::Component::Server::TCP->new(
>   Address  => ListenAddr,
>   Port => ListenPort,
>   #Alias   => 'name',
>   Concurrency  => 1, # 1 means run sequentially; default -1?
> (infinite)
>   ClientInput  => \&process_input,
>
> If I run it with Concurrency 1, then I see that ClientInput only
> accepts input chronologically - one at a time. Where does POE store
> the queued requests of ClientInput? There seems to be an implied
> buffer somewhere?
>
> --Gil Vidals
>
>

Re: RFC - Namespace dissertation for EAI Toolkit

[Matt Sickler]

Your toolkit doesn't even have to be in the POE[::Component]
namespace.  IMO, if its a completely selfsustained toolkit (and it
uses POE under the hood or even exposes some POE stuff) it should
probably go in its own namespace (ie Toolkit::Integration:: playing on
Integration Patterns Toolkit).

On Nov 26, 2007 3:45 PM, Alejandro Imass <[EMAIL PROTECTED]> wrote:
>
>
> Yes, we have had the same concerns! We though that by having the widely
> known terms in the Synopsis should suffice (for search engines).
>
> Perhaps we should reconsider and take the original Exx proposal I made
> on the MQ list. But in that case I would definitively stay away from ESB
> and use EAI instead (although I would personally prefer EIP for that
> matter, but then again I could get sued Hohpe & Co. :) ).
>
> Any one else care to share an opinion?
>
> If no objections arise within the course of this week, we will use
> POE::Component::EAI as our base.
>
> Best,
> Alejandro Imass
>
>
>
> On lun, 2007-11-26 at 14:27 -0600, David Snopek wrote:
> > Alejandro,
> >
> > The only potential issue I see with your proposed names is that those
> > acronyms aren't widely known.  Otherwise, I agree with all your
> > fundamental assertions.
> >
> > Regards,
> > David Snopek.
> >
>

Re: Making a Component

[Matt Sickler]

Not even that!
Components are very generic, high level abstract concepts.  You can
implement any interface you want [as long as its documented].
Some will return POE::Session objects, some will return objects, some
return Session ID's to post() to, etc.
It depends on the implementation and the requirements.

On Nov 16, 2007 6:39 PM, Alejandro Imass <[EMAIL PROTECTED]> wrote:
>
> All I have to do is return a session? and that's it?
>
> use POE;
> use POE::Component::MyAwsomeComponent;
>
> POE::Component::MyAwsomeComponent->new();
>
> and return a session, and that's it?
>
>
> perldoc POE::Component doesn't offer much more, and from the code of
> other components that seems to be about it. I can't find a component
> how-to anywhere else, so I am assuming it's as simple as that, but I'm
> probably wrong, right?
>
>

Re: PoCo::HTTP::Client v subclassing PoCo::Client::HTTP::Request

[Matt Sickler]

Probably the easiest method would be to modify the Filter::HTTPD that
the PoCo uses.

On 10/12/07, Ashley Pond <[EMAIL PROTECTED]> wrote:
> Hi. (Long time casual fan, occasional user of POE, first time wisdom
> seeker.)
>
> I have a POE app I'm working on/with which uses PoCo::HTTP::Client. I
> want to attach some additional security to the application's calls to
> its remote API server.
>
> My idea is to take a user keyed signature of the request as_string
> (always going to be POST) and stuff it in a new header, like
> "X-signed-post" or whatever. The security stuff (keys and certificates
> and checks) are all done and working great in other places. I just need
> to figure out where to hook into *every* HTTP::Request object that goes
> through the application. It could be done on each HTTP::Request before
> it's given to the app but that would be tedious, less secure, and leave
> duplicated code everywhere.
>
> I think I need to subclass PoCo::Client::HTTP::Request, right? Just
> override new(), add my signature header, then SUPER::new(@_). But where
> do I plug PoCo::Client::HTTP::Request back into the application? It's
> spawning a PoCo::Client::HTTP for its ua.
>
> I see that Daisuke Maki touched on plugging in the request class here:
> http://www.mail-archive.com/poe@perl.org/msg03615.html
>
> Did that make it into the code base? Any other ideas if not?
>
> Sorry to be a bit dumb about it but I really do not want to write the
> code twice, or make it messy (server/client code can get hard to read
> quickly if not written as cleanly as possible), or get it plain wrong
> and wonder why it isn't working.
>
> Thank you!
> -Ashley
>

Re: First post, new POE apprentice some doubts to clarify

[Matt Sickler]

Then you will get no data.  You will just tell the IKC client to
shutdown as part of your cleanup routine.

On 9/18/07, Zack Payton <[EMAIL PROTECTED]> wrote:
> What happens if the IKC requests don't finish in less than five seconds, say
> due to network delay?  Or if you want to run forever and then call a
> shutdown routine when some predetermined event happens?
>
>
>  On 9/18/07, Matt Sickler <[EMAIL PROTECTED]> wrote:
> > Zack,
> > The best way would be to clean up all of the things keeping the POE
> > Kernel alive.
> > In the client case, its the POE::Component::IKC::Client session.  Send
> > it a shutdown event, and the program will clean itself up.
> > See the updated example I put online (
> >
> http://poe.perl.org/?POE_Cookbook/Inter_Kernel_Communique
> )
> >
> > On 9/18/07, Zack Payton < [EMAIL PROTECTED]> wrote:
> > > Marcel,
> > >
> > > Thanks for taking an interest in POE... please don't let my horrible
> example
> > > deter you from reaping its' benefits.  I am the author of that example
> and
> > > you are completely right, it's an error on my part.  The reason is that
> the
> > > 1..10 post statements simply put the call statements in a queue which
> are to
> > > be executed at the POE kernels convenience rather than right now (for
> > > immediate execution use call rather than post).  I haven't looked
> closely
> > > enough at the source however I'd bet a shiny plastic nickel that the
> _stop
> > > event is prioritized and causes (as Matt indicates) the POE kernel to
> exit
> > > before the "Inter Kernel Communique" occurs.  I'm not sure the best way
> to
> > > handle an exit on the clients behalf and this is a very interesting
> > > question.
> > >
> > > If we're not to call _stop directly, what is the best way to put an exit
> > > event at the end of the queue to that all events are executed first and
> then
> > > we gracefully terminate.
> > >
> > > Thanks,
> > > Zack
> > >
> > > On 9/18/07, Marcel < [EMAIL PROTECTED]> wrote:
> > > >
> > > > Hello poe-masters!
> > > >
> > > > After reading the documentation, cases, samples, and understanding a
> > > > little
> > > > of the POE platform, I am dwelling with the examples at the cookbook
> > > > section
> > > > of the site, learning more, and trying to figure out some problems i'm
> > > > having with the ikc_server and ikc_client example of Inter POE's
> Kernel
> > > > Communique.
> > > >
> > > > As for now, i only get the response from ikc_server if i comment out
> the
> > > > line below of the client, which supresses the yield(_stop) event to
> the
> > > > server:
> > > >
> > > > $kernel->yield('_stop');
> > > >
> > > > If this line remains uncommented, all i get from issuing the client is
> the
> > > > line that is the output of the _stop event of the client:
> > > >
> > > > ~/learning_poe$ ./poe_ikc_client.pl
> > > > Finished...
> > > > ~/learning_poe$
> > > >
> > > > With that line commented out, issuing the execution of the client
> leads
> > > > to:
> > > >
> > > > ~/learning_poe$ ./poe_ikc_client.pl
> > > > Result!
> > > > 1
> > > > Result!
> > > > 2
> > > > Result!
> > > > 3
> > > > Result!
> > > > 4
> > > > Result!
> > > > 5
> > > > Result!
> > > > 6
> > > > Result!
> > > > 7
> > > > Result!
> > > > 8
> > > > Result!
> > > > 9
> > > > Result!
> > > > 10
> > > >
> > > > But the client never finishes, but that behaviour was expected.
> > > >
> > > > At the server terminal:
> > > >
> > > > ~/learning_poe$ ./poe_ikc_server.pl
> > > > Someone called!
> > > > Someone called!
> > > > Someone called!
> > > > Someone called!
> > > > Someone called!
> > > > Someone called!
> > > > Someone called!
> > > > Someone called!
> > > > Someone called!
> > > > Someone called!
> > > >
> > > > And the client communicates fine with the server.
> > > >
> > > > Can you point me what is the problem with that example given?
> > > >
> > > > Thank you in advance,
> > > >
> > > > Marcel Mitsuto.
> > > >
> > >
> >
>
>

Re: First post, new POE apprentice some doubts to clarify

[Matt Sickler]

Zack,
 The best way would be to clean up all of the things keeping the POE
Kernel alive.
In the client case, its the POE::Component::IKC::Client session.  Send
it a shutdown event, and the program will clean itself up.
See the updated example I put online (
http://poe.perl.org/?POE_Cookbook/Inter_Kernel_Communique )

On 9/18/07, Zack Payton <[EMAIL PROTECTED]> wrote:
> Marcel,
>
> Thanks for taking an interest in POE... please don't let my horrible example
> deter you from reaping its' benefits.  I am the author of that example and
> you are completely right, it's an error on my part.  The reason is that the
> 1..10 post statements simply put the call statements in a queue which are to
> be executed at the POE kernels convenience rather than right now (for
> immediate execution use call rather than post).  I haven't looked closely
> enough at the source however I'd bet a shiny plastic nickel that the _stop
> event is prioritized and causes (as Matt indicates) the POE kernel to exit
> before the "Inter Kernel Communique" occurs.  I'm not sure the best way to
> handle an exit on the clients behalf and this is a very interesting
> question.
>
> If we're not to call _stop directly, what is the best way to put an exit
> event at the end of the queue to that all events are executed first and then
> we gracefully terminate.
>
> Thanks,
> Zack
>
> On 9/18/07, Marcel <[EMAIL PROTECTED]> wrote:
> >
> > Hello poe-masters!
> >
> > After reading the documentation, cases, samples, and understanding a
> > little
> > of the POE platform, I am dwelling with the examples at the cookbook
> > section
> > of the site, learning more, and trying to figure out some problems i'm
> > having with the ikc_server and ikc_client example of Inter POE's Kernel
> > Communique.
> >
> > As for now, i only get the response from ikc_server if i comment out the
> > line below of the client, which supresses the yield(_stop) event to the
> > server:
> >
> > $kernel->yield('_stop');
> >
> > If this line remains uncommented, all i get from issuing the client is the
> > line that is the output of the _stop event of the client:
> >
> > ~/learning_poe$ ./poe_ikc_client.pl
> > Finished...
> > ~/learning_poe$
> >
> > With that line commented out, issuing the execution of the client leads
> > to:
> >
> > ~/learning_poe$ ./poe_ikc_client.pl
> > Result!
> > 1
> > Result!
> > 2
> > Result!
> > 3
> > Result!
> > 4
> > Result!
> > 5
> > Result!
> > 6
> > Result!
> > 7
> > Result!
> > 8
> > Result!
> > 9
> > Result!
> > 10
> >
> > But the client never finishes, but that behaviour was expected.
> >
> > At the server terminal:
> >
> > ~/learning_poe$ ./poe_ikc_server.pl
> > Someone called!
> > Someone called!
> > Someone called!
> > Someone called!
> > Someone called!
> > Someone called!
> > Someone called!
> > Someone called!
> > Someone called!
> > Someone called!
> >
> > And the client communicates fine with the server.
> >
> > Can you point me what is the problem with that example given?
> >
> > Thank you in advance,
> >
> > Marcel Mitsuto.
> >
>

Re: First post, new POE apprentice some doubts to clarify

[Matt Sickler]

I havn't used IKC before, but it seems that the client session closes
itself before getting any data from the server.
The
  $kernel->yield('_stop');
causes the kernel to fire the current session's _stop handler.  This
is bad for two reasons:
1)  With this model, the client probably stops before ever getting any
data back from the server.
2)  One should _NEVER_ call the predefined underscore events ( _start
_stop etc ) yourself.  Bad things happen and small children cry.

I am currently learning the POE::Component::IKC module, and will
update that wiki page as soon as I can (and I learn my wiki password
:( )

Thanks for taking an interest in POE, by the way!

~ Matt

On 9/18/07, Marcel <[EMAIL PROTECTED]> wrote:
> Hello poe-masters!
>
> After reading the documentation, cases, samples, and understanding a little
> of the POE platform, I am dwelling with the examples at the cookbook section
> of the site, learning more, and trying to figure out some problems i'm
> having with the ikc_server and ikc_client example of Inter POE's Kernel
> Communique.
>
> As for now, i only get the response from ikc_server if i comment out the
> line below of the client, which supresses the yield(_stop) event to the
> server:
>
> $kernel->yield('_stop');
>
> If this line remains uncommented, all i get from issuing the client is the
> line that is the output of the _stop event of the client:
>
> ~/learning_poe$ ./poe_ikc_client.pl
> Finished...
> ~/learning_poe$
>
> With that line commented out, issuing the execution of the client leads to:
>
> ~/learning_poe$ ./poe_ikc_client.pl
> Result!
> 1
> Result!
> 2
> Result!
> 3
> Result!
> 4
> Result!
> 5
> Result!
> 6
> Result!
> 7
> Result!
> 8
> Result!
> 9
> Result!
> 10
>
> But the client never finishes, but that behaviour was expected.
>
> At the server terminal:
>
> ~/learning_poe$ ./poe_ikc_server.pl
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
> Someone called!
>
> And the client communicates fine with the server.
>
> Can you point me what is the problem with that example given?
>
> Thank you in advance,
>
> Marcel Mitsuto.
>

Re: There needs to be a book!

[Matt Sickler]

I like the idea of having a wiki / online book like what the
subversion project does.  POE changes way too fast for a book to keep
up.  The wiki is already in place, it just needs more lovin', maybe
even HTML versions of the POD put up too.

On 9/8/07, Rocco Caputo <[EMAIL PROTECTED]> wrote:
> Nevertheless, it's not going to happen until people commit to making
> it so.  What do you need from me to help make this a reality?
>
> --
> Rocco Caputo - [EMAIL PROTECTED]
>
>
> On Sep 7, 2007, at 22:12, lanas wrote:
>
> > Le Vendredi, 7 Septembre 2007 15:29:52 -0400,
> > Rocco Caputo <[EMAIL PROTECTED]> a écrit :
> >
> >> POE has had a "documentation" project for over four years.  It's in
> >> http://poe.svn.sourceforge.net/viewvc/poe/trunk/docs/ ... see
> >> revision 1997 for some really old documentation.
> >
> >> If people are really interested in contributing, please let me know
> >> how I can help.  I can't actually write documentation.  Until POE's
> >> perldocs are done, they have priority on my documentation
> >> resources. Maybe I can resurrect some old guidelines and outlines to
> >> provide some guidance, though.
> >
> > Personally, how I see it is more like a real book than documentation.
> > For comparison's sake, it'd be like a book on Perl OO such has the one
> > by Damian instead of the Perl OO man pages.  The POE Cookbook gives
> > some
> > good examples, but it is not like a book with all the extraneous text
> > and context explanation unecessary bla bla and such things (even
> > funny bits) that makes a book a book.  That makes it an interesting
> > read and ultimately inspiring for trying things out.
> >
> > Documentation is very important, but a book, with its less formal
> > approach is great when it uses entertaining and interesting examples,
> > not only the basic stuff.
> >
> > Cheers,
> > Al
>
>
>

Re: POE::Filter error reporting

[Matt Sickler]

ap { [ ref($stream), $_ ] } @$stream;
> >  return;
> >}
> >
> ># Otherwise it's plain data.  Combine the streamed data,
> ># and buffer it.
> >
> >if (@$self and ref($self->[-1]) eq "ARRAY") {
> >  $self->[-1] .= join "", @$stream;
> >  return;
> >}
> >
> >push @$self, join "", @$stream;
> >return;
> > }
> >
> > # Return the next chunk, which was prepared in get_one_start().
> >
> > sub get_one {
> >my $self = shift;
> >return bless [ ], "POE::Filter::Datatype::Empty" unless @$self;
> >    return shift @$self;
> > }
> >
> > # Return a list rather than a list reference.
> > # The problem here is that we may be returning
> > # many different types of things, each requiring
> > # its own envelope.
> >
> > sub get_pending {
> >my $self = shift;
> >return @$self;
> > }
> >
> > --
> > Rocco Caputo - [EMAIL PROTECTED]
> >
> >
> > On Aug 15, 2007, at 11:57, Nicholas Perez wrote:
> >
> > > The only reason I questioned it is because I heard mentioned in #poe
> > > about wanting to maintain the non-POE-ness of filters (ie. usage
> > > outside of POE). I could have the context wrong, though and I forgot
> > > specifically who said it? Chris maybe?
> > >
> > > On 8/15/07, Matt Sickler <[EMAIL PROTECTED]> wrote:
> > >> How is adding that error mechanism binding the filter to the wheel
> > >> any
> > >> more than the current get_one() and put() API is?
> > >>
> > >> I don't care how many API's we have to break, Filters should have
> > >> proper error checking.
> > >> Sure there are alot of third party filters, but 90% of the devs
> > >> are on
> > >> #poe, and the other 10% are probably smart enough to read the docs
> > >> and
> > >> figure out the changes.
> > >>
> > >> On 8/15/07, Nicholas Perez <[EMAIL PROTECTED]> wrote:
> > >>> This certainly looks promising, but how do you know when to read it?
> > >>> When the filter returns an empty array ref? I'd like not for the
> > >>> error
> > >>> checking to be required after every time an empty array ref gets
> > >>> returned, because that could be quite a few times depending on
> > >>> how big
> > >>> of a buffer the filter has before a usable chunk comes out the other
> > >>> end. Also, it seems like the OOB stuff shouldn't get passed in to
> > >>> get_one(). While I'm all for breaking the API to fix something, it
> > >>> seems like there should be an OOB mechanism built-in, that doesn't
> > >>> require passing arguments to get_one.
> > >>>
> > >>> I still thinking adding a property is the way to go. To indicate
> > >>> error
> > >>> state, I like the idea of passing into the constructor a ref to a
> > >>> scalar and checking its boolean value after each execution (I think
> > >>> this sounds like a compromise). That seems like less cycles for
> > >>> error
> > >>> checking, and we don't change the return [ ] behavior on error or no
> > >>> records.
> > >>>
> > >>> The only problem with an error indicator passed in is this: we have
> > >>> just coupled the container to the filter (as witnessed by the
> > >>> changes
> > >>> to readwrite). Do we really want this?
> > >>>
> > >>> In reality any of these approaches will work. I would just like to
> > >>> find the least painful of them all.
> > >>>
> > >>> On 8/14/07, David Davis <[EMAIL PROTECTED]> wrote:
> > >>>> My work on POE::Filter::SSL is relevant here.
> > >>>>
> > >>>> I needed a way to pass OOB data back to the readwrite wheel
> > >>>> during the SSL
> > >>>> negotiation.  The method LotR and I came up works great.  I pass
> > >>>> an array
> > >>>> ref to get_one (lets call it $oob), and any time a filter has
> > >>>> OOB data, it
> > >>>> blesses it into a namespace, and pushes it onto @$oob.  For
> > >>>> Filter::SSL, I
> > >>>> used the OOB namespace 'POE::OOB::put

Re: POE::Filter error reporting

[Matt Sickler]

How is adding that error mechanism binding the filter to the wheel any
more than the current get_one() and put() API is?

I don't care how many API's we have to break, Filters should have
proper error checking.
Sure there are alot of third party filters, but 90% of the devs are on
#poe, and the other 10% are probably smart enough to read the docs and
figure out the changes.

On 8/15/07, Nicholas Perez <[EMAIL PROTECTED]> wrote:
> This certainly looks promising, but how do you know when to read it?
> When the filter returns an empty array ref? I'd like not for the error
> checking to be required after every time an empty array ref gets
> returned, because that could be quite a few times depending on how big
> of a buffer the filter has before a usable chunk comes out the other
> end. Also, it seems like the OOB stuff shouldn't get passed in to
> get_one(). While I'm all for breaking the API to fix something, it
> seems like there should be an OOB mechanism built-in, that doesn't
> require passing arguments to get_one.
>
> I still thinking adding a property is the way to go. To indicate error
> state, I like the idea of passing into the constructor a ref to a
> scalar and checking its boolean value after each execution (I think
> this sounds like a compromise). That seems like less cycles for error
> checking, and we don't change the return [ ] behavior on error or no
> records.
>
> The only problem with an error indicator passed in is this: we have
> just coupled the container to the filter (as witnessed by the changes
> to readwrite). Do we really want this?
>
> In reality any of these approaches will work. I would just like to
> find the least painful of them all.
>
> On 8/14/07, David Davis <[EMAIL PROTECTED]> wrote:
> > My work on POE::Filter::SSL is relevant here.
> >
> > I needed a way to pass OOB data back to the readwrite wheel during the SSL
> > negotiation.  The method LotR and I came up works great.  I pass an array
> > ref to get_one (lets call it $oob), and any time a filter has OOB data, it
> > blesses it into a namespace, and pushes it onto @$oob.  For Filter::SSL, I
> > used the OOB namespace 'POE::OOB::put' for data that needs to be directly
> > sent out the wheel's driver.  Filter::Stackable and Wheel::ReadWrite needs
> > to be aware of this OOB data, so I've patched them too.  We can use this
> > method to add 'POE::OOB::error' and handle it by sending an event.
> >
> > Relevant files:
> > http://svn.xantus.org/sprocket/trunk/Sprocket/lib/POE/Filter/Stackable.pm
> > http://svn.xantus.org/sprocket/trunk/Sprocket/lib/POE/Filter/SSL.pm
> > http://svn.xantus.org/sprocket/trunk/Sprocket/lib/POE/Wheel/ReadWrite.pm
> >
> > Cheers,
> > David
> >
> > On 8/14/07, Martijn van Beers <[EMAIL PROTECTED]> wrote:
> > >
> > > There was a discussion about this on #poe, which I thought I'd share:
> > >
> > > <+nperez> an isa check every single time something goes through the
> > >   filter just seems like overkill...
> > > <+LotR> compared to the work that Filter::XML does?
> > > <+nperez> yes, because it will add up. hold on, writing a benchmark
> > > script
> > > <+LotR> I'm sure it will prove to be nothing compared to parsing an xml
> > > subtree
> > > <+nperez> but what about other filters? Stream? Line?
> > > <+LotR> stream doesn't ever need to generate any errors. nor does line
> > > <+LotR> if you just use those, you can forget about error checking
> > > altogether
> > > * LotR will send the discussion to the list when we're done
> > > <+nopaste> "nperez" at 12.5.72.252 pasted "undef vs isa" (30 lines) at
> > >http://nopaste.snit.ch:8001/10886
> > > <+nperez> take a look
> > > <+nperez> that's a huge difference
> > > <+LotR> but an isa() still is pretty damn fast.
> > > <+nperez> besides, it is less of a rewrite checking for undef.
> > > consider:
> > >   you have to now check ref and then isa on every return value
> > >   from the filter
> > > <+nperez> what if it isn't a ref that gets returned?
> > > <+nperez> and isa only worked on blessed objects
> > > <+LotR> you're still going to have to check for undef too
> > > <+nperez> works
> > > <+nperez> exactly, so why do the other checks and you can just do the
> > > one
> > > <+LotR> and it is going to be more of a change if you then have to ask
> > > the filter for extra data
> > > <+nperez> not really, implementing an get_error() isn't as profound of
> > > a
> > >   change
> > > <+nperez> it is OOB
> > > <+nperez> without you still have checking for undef for errors in a lot
> > >   of modules anyhow
> > > <+nperez> if they want to know more info, they then call get_error()
> > > <+nperez> otherwise, they might not care
> > > <+LotR> that "whout you still.." sentence doesn't parse for me
> > > <+LotR> without. duh
> > > <+nperez> sorry, without get_error(), you still have checking for undef
> > > <+LotR> still don't get it. how does checking for undef for errors in
> > > 'a

Re: POE::Filter error reporting

[Matt Sickler]

I second this method.  It provides a simple API, and simple Filters
wouldn't have to be modified much.

On 8/14/07, Nicholas Perez <[EMAIL PROTECTED]> wrote:
> I second this.
>
> And I think something like POE::Filter::Error would be a good place to
> encapsulate something like that. But like what was stated in IRC,
> making the error appear in the normal data stream could be
> problematic. I suggest a property on the filter itself store an error
> object that can be checked if it returns undef  (a much simpler
> indicator for error). This pattern is really no different than any of
> the perl built ins when they set $!.
>
> On 8/14/07, Martijn van Beers <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > so with filters becoming more and more complex (e.g. POE::Filter::XML,
> > Filter::HTTPD) I think it would be a good idea to have a standard way of
> > reporting back errors.
> >
> > Currently Filter::HTTPD returns a HTTP::Response object instead of a
> > HTTP::Request, to send back to the remote end. Filter::XML uses a
> > callback mechanism, which you can attach to a POE event.
> >
> > Especially if you want to combine several complex filters into a
> > Stackable one, this becomes problematic. Each would have to know about
> > the way its predecessor in the stack reports problems.
> >
> > I suggest we decide on a standard object type to use for filter errors.
> > For Filter::SAXBuilder I picked Error::Simple for now, but that may not
> > be the best choice. With a standard object, Filter::Stackable could just
> > skip over the rest of the stack when it encounters an error, so filters
> > don't need to do any error handling of their own.
> >
> > Does anyone know a good CPAN module to use, or should we write our own?
> > It could be something really simple, basically just a container for
> > whatever you like, just blessed in a standard way so it can be
> > identified as an error.
> >
> >
> > Martijn
> >
> >
>

Re: HTTPS server

[Matt Sickler]

The Client* Interface doesnt have a method to expose the socket.  A
simple patch to the module should allow it though.

On 8/9/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:
>
> On Aug 7, 2007, at 5:07 PM, Joel Bernstein wrote:
>
> > On Tue, Aug 07, 2007 at 11:10:16AM -0700, Kevin Scaldeferri wrote:
> >> I need to add SSL to my web server implemented in POE.  At the
> >> moment, I'm familiar with 3 HTTP server implementations:
> >>
> >> PoCo::Server::TCP + POE::Filter::HTTPD
> >> PoCo::Server::HTTP
> >> PoCo::Server::SimpleHTTP
> >>
> >>
> >> Of these, the last seems to be the only one that has an option for
> >> SSL support.  Before I start switching my whole app over to using
> >> that library, I'm wondering if there's any other option that I've
> >> missed.
> >
> > Well, PoCo::Server::SimpleHTTP uses PoCo::SSLify to do the SSL stuff.
> > Would it be more work to rewrite your app to use another library,
> > or to
> > patch your current http server component to SSLify its socket?
> >
> > http://search.cpan.org/~apocal/POE-Component-SSLify-0.08/lib/POE/
> > Component/SSLify.pm
>
>
> I considered that, but it seems difficult to get access to the socket
> from PoCo::Server::TCP (which I've been using).  You can do it with
> the deprecated Acceptor interface, I think; but I didn't see how to
> make it work with the Client* interface.
>
> FWIW, PoCo::Server::SimpleHTTP seems to have once been based on top
> of PoCo::Server::TCP, but now uses more low-level.  I'm not sure what
> the history is here; but it's possible that adding SSL support had
> something to do with it.
>
>
> -kevin
>

Irssi + PoCoEasyDBI

[Matt Sickler]

For some reason EasyDBI does not work when spawned directly inside an
irssi script.

use strict;
use Glib;
use POE qw(Loop::Glib);
use POE::Component::EasyDBI;
use POE::Session::Irssi;

POE::Component::EasyDBI->spawn(
  alias => 'edbi',
  dsn => "DBI:mysql:database=mylog2;host=192.168.24.11;port=3306",
  username => 'irssi',
  password => 'irssi',
  alt_fork => 1,

  ping_timeout => 120,
);


If I use POE::Wheel::Run to fork/exec a script that runs the EasyDBI
stuff, it works just fine.
I tried EasyDBI with and without the alt_fork, same effect.
The error I get is "POE::Component::EasyDBI tried 5 times to create a
Wheel and is giving up... at
/usr/lib/perl5/site_perl/5.8.8/POE/Component/EasyDBI.pm line 642.  ***
 ignoring. "

Re: Wheel::FollowTail resume where it left off?

[Matt Sickler]

You could store the current byte position in another file.  This would
only work as long as the file is only appended, if it is removed,
moved, or replaced, this would fail.

On 7/30/07, Tom Lanyon <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Does anyone have a tricky way of using Wheel::FollowTail to watch
> some logfiles, but be able to exit and then resume from the last
> point? Is this even possible on a continually growing file?
>
> Thanks,
> Tom
>

Re: module maintainership

[Matt Sickler]

thirdlobe, talk to dngor
awesome and free

On 6/14/07, Matt Cashner <[EMAIL PROTECTED]> wrote:

I'm looking for new homes for my POE modules. If you have any
interest, please email me privately at [EMAIL PROTECTED] and we'll talk.
Thanks all.

--
Matt Cashner
[EMAIL PROTECTED]
http://mattcashner.com

Re: Access to socket from PoCo::Server::TCP

[Matt Sickler]

I just committed a change that adds get_input_handle and
get_output_handle methods to Wheel::ReadWrite.  :)

On 5/23/07, Rohan Almeida <[EMAIL PROTECTED]> wrote:


Matt Sickler wrote:
> Perhaps a better way would be to have methods that do the getsockopt
> calls themselves?

There would be no end to this. Why use layered methods when a
simple getsockopt (and others) on the socket would suffice?

--
Rohan


> On 5/23/07, Nicholas Perez <[EMAIL PROTECTED]> wrote:
>> I seem to remember wanting similar functionality in the past and it
>> was countered for some reason. A wheel would be useless without the
>> handles (ie, yanked out via accessor), but it keeps the end developer
>> from holding onto a reference to the handles when building the wheel
>> in the first place.
>>
>> On 5/23/07, Matt Sickler <[EMAIL PROTECTED]> wrote:
>> > The component wouldnt be the one to provide access to it.
>> > You would need to patch POE::Wheel::ReadWrite to provide an accessor
>> > method to the input and output handles.
>> >
>> > On 5/22/07, Rohan Almeida <[EMAIL PROTECTED]> wrote:
>> > >
>> > > I need access to the socket, as I have to use the getsockopt
>> > > call. I don't have any problems with using SocketFactory and
>> > > Wheels for my server. Just though it would be nice if
>> > > PoCo::Server::TCP does provide access to the socket.
>> > >
>> > > Thanks,
>> > > Rohan
>> > >
>> > > Matt Sickler wrote:
>> > > > There arent any documented ways to get at a ReadWrite wheel's
>> handle.
>> > > > The non-POE way you could do it (and breaking encapsulation)
>> would be to
>> > > > use
>> > > > $heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_INPUT ] and
>> > > > $heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_OUTPUT ]
>> > > > ( those would be the same in many situations ).
>> > > > This breaks encapsulation and could change at no notice and its
>> all your
>> > > > fault.
>> > > >
>> > > > A better question you need to ask is why do you need to get at
>> the socket?
>> > > >
>> > > > On 5/22/07, Rohan Almeida <[EMAIL PROTECTED]> wrote:
>> > > >>
>> > > >> Hi,
>> > > >>
>> > > >> Is there any way I can get access to the underlying socket while
>> > > >> using PoCo::Server::TCP without using the Client* callbacks?
>> > > >>
>> > > >> The docs say that the socket is only passed if I use the Acceptor
>> > > >>   callback, which then means I have to create my own Wheel for
>> > > >> read/write and so on.
>> > > >>
>> > > >> Again, $heap->{listener} is only available if I use the Acceptor
>> > > >> callback. $heap->{client} seems to be a ReadWrite wheel. I tried
>> > > >> accessing the Handle for this wheel (which should be the socket),
>> > > >> but I'm not getting anywhere.
>> > > >>
>> > > >> Thanks,
>> > > >> Rohan
>> > > >>
>> > > >>
>> > > >
>> > >
>> > >
>> >
>>
>

Re: Access to socket from PoCo::Server::TCP

[Matt Sickler]

Perhaps a better way would be to have methods that do the getsockopt
calls themselves?

On 5/23/07, Nicholas Perez <[EMAIL PROTECTED]> wrote:

I seem to remember wanting similar functionality in the past and it
was countered for some reason. A wheel would be useless without the
handles (ie, yanked out via accessor), but it keeps the end developer
from holding onto a reference to the handles when building the wheel
in the first place.

On 5/23/07, Matt Sickler <[EMAIL PROTECTED]> wrote:
> The component wouldnt be the one to provide access to it.
> You would need to patch POE::Wheel::ReadWrite to provide an accessor
> method to the input and output handles.
>
> On 5/22/07, Rohan Almeida <[EMAIL PROTECTED]> wrote:
> >
> > I need access to the socket, as I have to use the getsockopt
> > call. I don't have any problems with using SocketFactory and
> > Wheels for my server. Just though it would be nice if
> > PoCo::Server::TCP does provide access to the socket.
> >
> > Thanks,
> > Rohan
> >
> > Matt Sickler wrote:
> > > There arent any documented ways to get at a ReadWrite wheel's handle.
> > > The non-POE way you could do it (and breaking encapsulation) would be to
> > > use
> > > $heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_INPUT ] and
> > > $heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_OUTPUT ]
> > > ( those would be the same in many situations ).
> > > This breaks encapsulation and could change at no notice and its all your
> > > fault.
> > >
> > > A better question you need to ask is why do you need to get at the socket?
> > >
> > > On 5/22/07, Rohan Almeida <[EMAIL PROTECTED]> wrote:
> > >>
> > >> Hi,
> > >>
> > >> Is there any way I can get access to the underlying socket while
> > >> using PoCo::Server::TCP without using the Client* callbacks?
> > >>
> > >> The docs say that the socket is only passed if I use the Acceptor
> > >>   callback, which then means I have to create my own Wheel for
> > >> read/write and so on.
> > >>
> > >> Again, $heap->{listener} is only available if I use the Acceptor
> > >> callback. $heap->{client} seems to be a ReadWrite wheel. I tried
> > >> accessing the Handle for this wheel (which should be the socket),
> > >> but I'm not getting anywhere.
> > >>
> > >> Thanks,
> > >> Rohan
> > >>
> > >>
> > >
> >
> >
>

Re: Access to socket from PoCo::Server::TCP

[Matt Sickler]

The component wouldnt be the one to provide access to it.
You would need to patch POE::Wheel::ReadWrite to provide an accessor
method to the input and output handles.

On 5/22/07, Rohan Almeida <[EMAIL PROTECTED]> wrote:


I need access to the socket, as I have to use the getsockopt
call. I don't have any problems with using SocketFactory and
Wheels for my server. Just though it would be nice if
PoCo::Server::TCP does provide access to the socket.

Thanks,
Rohan

Matt Sickler wrote:
> There arent any documented ways to get at a ReadWrite wheel's handle.
> The non-POE way you could do it (and breaking encapsulation) would be to
> use
> $heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_INPUT ] and
> $heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_OUTPUT ]
> ( those would be the same in many situations ).
> This breaks encapsulation and could change at no notice and its all your
> fault.
>
> A better question you need to ask is why do you need to get at the socket?
>
> On 5/22/07, Rohan Almeida <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> Is there any way I can get access to the underlying socket while
>> using PoCo::Server::TCP without using the Client* callbacks?
>>
>> The docs say that the socket is only passed if I use the Acceptor
>>   callback, which then means I have to create my own Wheel for
>> read/write and so on.
>>
>> Again, $heap->{listener} is only available if I use the Acceptor
>> callback. $heap->{client} seems to be a ReadWrite wheel. I tried
>> accessing the Handle for this wheel (which should be the socket),
>> but I'm not getting anywhere.
>>
>> Thanks,
>> Rohan
>>
>>
>

Re: Access to socket from PoCo::Server::TCP

[Matt Sickler]

There arent any documented ways to get at a ReadWrite wheel's handle.
The non-POE way you could do it (and breaking encapsulation) would be to use
$heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_INPUT ] and
$heap->{client}->[ POE::Wheel::ReadWrite::HANDLE_OUTPUT ]
( those would be the same in many situations ).
This breaks encapsulation and could change at no notice and its all your fault.

A better question you need to ask is why do you need to get at the socket?

On 5/22/07, Rohan Almeida <[EMAIL PROTECTED]> wrote:


Hi,

Is there any way I can get access to the underlying socket while
using PoCo::Server::TCP without using the Client* callbacks?

The docs say that the socket is only passed if I use the Acceptor
  callback, which then means I have to create my own Wheel for
read/write and so on.

Again, $heap->{listener} is only available if I use the Acceptor
callback. $heap->{client} seems to be a ReadWrite wheel. I tried
accessing the Handle for this wheel (which should be the socket),
but I'm not getting anywhere.

Thanks,
Rohan

Re: Making PoCo::Client::HTTP's RequestFactory configurable

[Matt Sickler]

First off, download the svn source from source forge.  Maybe Rocco
(dngor) will give you commit access if you have a SF account,
otherwise paste the changes here and one of us will commit your
change.
Also, dont forget to add tests to make sure your changes work and dont
break anything else.

On 5/17/07, Daisuke Maki <[EMAIL PROTECTED]> wrote:

Hi,

I'm currently building a crawler framework called Gungho. So far I think
the project is going great. Now I'm starting to think about
optimizations, and one of them happens to revolve around PoCo::Client::HTTP.

In a past experiment, I've hacked on PoCo::Client::HTTP::Request so that
it writes the data content to disk -- this greatly reduced the overhead
on each process that was doing the crawling, since hundreds or thousands
of requests may be sent all at once. But at that time it required
actually hacking on the installed PoCo::Client::HTTP::Request source, or
to cut n' paste a bunch of code from said module and doing the fack --
which wasn't such a great idea, because the internal dependencies were
delicate enough that upgrading PoCo::Client::HTTP caused the module to
break.

I'd like to do something similar in Gungho, but this time I'd like to
make it so that things don't break just because we upgraded
PoCo::Client::HTTP. The easiest solution seems to be just to create a
new type of PoCo::Client::HTTP::Request, so that while the bulk of the
code may be identical to PoCo::Client::HTTP::Request, it can lead a
different life cycle that doesn't depend on the other.

To make this possible, I'd like to make PoCo::Client::HTTP able to
change the type of RequestFactory it creates -- or, make RequestFactory
be able to produce difference types of Requests.

In either case, this should be a simple 3-4 line change. I don't mind
doing the hacking myself, can you please tell me where I should start?

Regards,
--d

Re: data in HEAP vs. OBJECT

[Matt Sickler]

It really depends on what the session does.
If its a really OO-centric module and uses all object states (like PoCo-IRC)
then you could use OBJECT exclusively (like PoCo-IRC).
If there are no object states, then OBJECT doesnt apply.
It really depends on what you are doing and how you want to accomplish it.
The only difference between the two is, OBJECT only appears in object states
(when it is the instance object that POE uses to call the
event/method/state) and HEAP is everywhere.

On 5/5/07, John R. <[EMAIL PROTECTED]> wrote:


I see in the documentation that HEAP is a good place for run time
storage.  About how about in OBJECT?  Is OBJECT only for states?  It
seems possible to use it for data.

Thanks,

John

POE + Glade

[Matt Sickler]

okay, heres the story
I am developing a messenger app for my school (win32), currently I am using
POE + Tk
Then I wanted a GUI  GUI-maker.  someone pointed me to Glade (which is Gtk,
Glib, etc)


i found http://gladewin32.sourceforge.net  which installed glib, glade, gtk,
etc or whatever, and now I am trying to install the necessary Perl modules

just wondering if anyone has any pointers or if you want me to paste the
specific CPAN.pm log I can

Re: PoCo::Server::TCP bug or wrong usage ?

[Matt Sickler]

The InlineStates, PackageStates, and ObjectStates for PoCoServerTCP are for
the client sessions:
when you spawn() a PCST, it makes a master session that sits around
listening for connections, when one arrives, it spawns a new session which
get InlineStates, PackageStates, and ObjectStates.

On 3/22/07, zgrim <[EMAIL PROTECTED]> wrote:


  Hello,

I'm trying to post something to a tcp server inline state from
elsewhere, but it doesn't seem to work. I built a test script, if
anyone cares to look at it,
http://zgrim.lsd.ro/tmp/pocostt.pl.txt
I used similar code with the tcp client component, which worked, hence
my current surprise. Maybe I'm doing something wrong though, so I
wouldn't mind even a rtfm _there_. :)
TIA

--
perl -MLWP::Simple -e'print$_[rand(split(q|%%\n|,
get(q=http://cpan.org/misc/japh=)))]'

Re: Do you review additions to POE?

[Matt Sickler]

I do not believe there is any mandatory review for anything except core POE
(which Rocco releases himself anyway).
Go ahead and submit it to CPAN - it will be tested and reviewed by many, and
thats the best way to get feedback.

On 3/21/07, Chris Cobb <[EMAIL PROTECTED]> wrote:


Greetings,
I'd like to submit some work to CPAN. Do you prefer to
comment on the module name space first, or should I
just go directly to PAUSE and request this name space?

  POE::Event::Message

I've created several POE components based on this. I plan
to add them to CPAN, and can discuss them if appropriate.

I've been using POE for some years now. Thanks so much for
conceiving and providing this cool...thingy.
Cheers,
Chris


Features of POE::Event::Message

Messages of this class have flexible routing capabilities
that work both inside and outside POE-based applications.

The messages are designed to be plug-compatible with
POE's existing 'postback' mechanism. I refer to this as
a 'routeback' mechanism.

In addition, this class has the ability to introduce
multiple 'forward' and/or 'reverse' routing to multiple
event and/or remote host destinations. This allows for
temporary interruption of normal message flow, without
any of the intended participants knowing or caring.

Messages are delivered based on the type of the destination.
A 'local' routing will trigger a POE 'post' or 'call' event,
while a 'remote' routing invokes a socket connection to a
particular host and port.

Messages can also be sent through a file handle, such as
from a non-POE child to a POE-based parent process.

Re: POE::Component::Server::HTTP, Keep alive, and leaking sockets

[Matt Sickler]

A better fix would be a patch to the source that fixes the leak

On 3/21/07, Eric Busto <[EMAIL PROTECTED]> wrote:


Firefox seems to keep them alive as well.  Unfortunately, since the app
I am writing uses a meta refresh every few seconds to have the browser
reload it, a browser left up overnight will easily cause the app to run
out of file descriptors.

   -Original Message-
   From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mathieu Longtin
   Sent: Wednesday, March 21, 2007 12:27 PM
   To: Eric Busto
   Cc: poe@perl.org
   Subject: Re: POE::Component::Server::HTTP, Keep alive, and
leaking sockets


   My memory is fuzzy, but I think if you close the browser,
especially if it's local, the sockets closes. I remember IE keeping the
connections alive for a while.


   On 3/21/07, Eric Busto <[EMAIL PROTECTED]> wrote:

   From what I have gathered, for a web server to be HTTP
1.1 compliant, it
   must support keep alive, and keep alive is enabled by
default.

   When using POE::Component::Server::HTTP in its simple
case, as in the
   cookbook entry

http://poe.perl.org/?POE_Cookbook/Web_Server_With_Components, keeping
   the connections open even after the event for the URL
request has been
   handled causes file descriptors to "leak" as the socket
will not get
   closed.

   I can force the connection to get closed after the
ContentHandler
   triggers by having a PreHandler like so:
   POE::Component::Server::HTTP->new (
   Port=> 80,
   PreHandler  => {
   '/' => sub {
$_[0]->header(Connection =>
   'close') }
   },
   ContentHandler  => {
   '/' => \&web_status,
   }
   }

   My question is, is this the "right" thing to do?  Is
there a more
   elegant method, or am I missing something that should be
obvious?  If
   I'm not missing anything, should this be added to the
cookbook page for
   a basic web server with PoCo::Server::HTTP?







---
   This email message is for the sole use of the intended
recipient(s) and may contain
   confidential information.  Any unauthorized review, use,
disclosure or distribution
   is prohibited.  If you are not the intended recipient,
please contact the sender by
   reply email and destroy all copies of the original
message.


---





   --
   Mathieu Longtin

Re: How to write a new wheel?

[Matt Sickler]

The best bet would be to modify an existing Wheel to do your evil bidding..
using others and POE::Wheel as reference

On 3/19/07, flw <[EMAIL PROTECTED]> wrote:


Because the POE::Wheel::ReadLine module can't work on Win32 platform.
So I want to write a new wheel like POE::Wheel::ReadLine to support
Win32 platform.

Any document or hint are welcome.

Re: :Wheel::Run->new not returning?

[Matt Sickler]

as maybe a catcher, you could add a
 warn '$/ is not default' if $/ != "\n";
 local $/ = "\n";
just before the read


On 3/16/07, Eric Busto <[EMAIL PROTECTED]> wrote:


Last e-mail, I promise.

I found the source of the problem.  I was setting $/ to undef, without
declaring it as a local change (i.e. local $/ = undef).  This was
causing the <$sem_pipe_read> to not use the default of newlines as a
delimiter.  So it would read the "go\n", then try to read again, and
would block there.

The reason this wasn't happening all of the time in my program was
because I was only setting $/ in certain situations (when I needed to
read in a while file into a scalar variable).

So, yeah, I'm a bonehead.  The <$sem_pipe_read>, however, does require
that $/ be set to the default, so any opposition to POE::Wheel::Run
setting $/ itself?

-Original Message-
From: Eric Busto
Sent: Thursday, March 15, 2007 2:09 PM
To: poe@perl.org
Subject: RE: :Wheel::Run->new not returning?


So by running my script like so:

PERLDB_OPTS="NonStop=1 LineInfo=debug.out AutoTrace"
/home/utils/perl-5.8.8/bin/perl -d ./RSM.pl

I have been able to see precisely where the hang is occurring.  The
child gets all the way to exec'ing:
POE::Wheel::Run::new(/home/utils/perl-5.8.8/lib/site_perl/5.8.8/POE/Whee
l/Run.pm:498):
498:exec(join(" ", $program, @$prog_args))
499:  or die "can't exec ($program) in child pid $$: $!";

But the parent is stuck waiting to read from a pipe:
POE::Wheel::Run::new(/home/utils/perl-5.8.8/lib/site_perl/5.8.8/POE/Whee
l/Run.pm:546):
546:  <$sem_pipe_read>;

Ideas?  Thoughts?  Suggestions?

-Original Message-
From: Eric Busto
Sent: Wednesday, March 14, 2007 11:36 AM
To: poe@perl.org
Subject: POE::Wheel::Run->new not returning?

I'm using POE::Wheel::Run to spawn off child rsync processes.  Every so
often (i.e. every 1 in 50 to 100 calls), the new method fails to return.
Since it seems a bit random, I'm stumped on how to go about figuring
this out.  Has anyone else encountered this before, or have any ideas?

I'm not doing anything crazy, I don't believe:

$heap->{task}   = POE::Wheel::Run->new (
   Program => $cmd,
   StdoutEvent => 'child_stdout',
   StderrEvent => 'child_stderr',
   ErrorEvent  => 'child_error'
);

$kernel->sig_child($heap->{task}->PID(), 'child_done');
print now(), " Back from POE::Wheel::Run new\n";

Most of the time I see the print line, but when I don't, a strace of the
perl process shows:

# strace -p 14399
Process 14399 attached - interrupt to quit
read(23,

And a gdb backtrace:

(gdb) bt
#0  0x003bb48b7e52 in __read_nocancel () from /lib64/tls/libc.so.6
#1  0x004b9da1 in PerlIOUnix_read ()
#2  0x004b8b0e in Perl_PerlIO_read ()
#3  0x004baeff in PerlIOBuf_fill ()
#4  0x004b8dbd in Perl_PerlIO_fill ()
#5  0x004b964a in PerlIOBase_read ()
#6  0x004b8b0e in Perl_PerlIO_read ()
#7  0x004bc4a3 in PerlIO_getc ()
#8  0x00474f23 in Perl_sv_gets ()
#9  0x00468a9b in Perl_do_readline ()
#10 0x004653ae in Perl_runops_standard ()
#11 0x0041eae8 in S_run_body ()
#12 0x0041ea20 in perl_run ()
#13 0x0041bb64 in main ()
(gdb)


---
This email message is for the sole use of the intended recipient(s) and
may contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.  If you are not the intended recipient, please contact
the sender by
reply email and destroy all copies of the original message.

---

Re: run_one_timeslice & a little toy about workhorse

[Matt Sickler]

I once wrote a POE::API module that had a do_events_until and wait_until
methods that would let the kernel do other things until a variable was set
or a time passed - they both used run_one_timeslice but I found that that
method didnt have the granularity that my methods needed.  ie. they would
run multiple events rather than just one or a few

On 3/8/07, Sun Yi-Ming <[EMAIL PROTECTED]> wrote:


Hi POE,
   I formerly write a lot of event_driven code, and always involv
using a pattern like
while (not $done) {
do_sth_normally();
loop_once();
},
  I also see about the run_one_timeslice method in Kernel, and I
always invented a little toy as   workhorse to do that normally work:

package POE::Component::Normal::Workhorse;

use POE;

sub spawn {
$mi = shift;
my %params = @_;
my $done = delete $params{check_end};
my $work = delete $params{work};
my $context = delete $params{context};
POE::Session->create
( inline_states => {
_start => sub { $_[KERNEL]->yield( workhorse ) },
workhorse => sub {
return if $done->();
$_[KERNEL]->yield( workhorse );
$work->($_[HEAP]->{context});
},
  }
);
}


package main;

use POE;

my $done = 0;
POE::Component::Normal::Workhorse->spawn
( check_end => sub { return $done },
  work => sub { print "run once\n" },
  context => {},
);

Is it somewhat useful or thorough rubbish？

--
Sincerely,

孙一鸣 Simon Sun
--
Be a man with simple interface.

Re: QUESTION: POE Nomenclature

[Matt Sickler]

i believe 'event chain' would be appropriate

On 3/1/07, Michael Collins <[EMAIL PROTECTED]> wrote:


POE Gang,

I have a nomenclature question.  Let's say you have one or more POE
sessions.  When you have an 'event flow' - the flow of control moves
from session to session (or to different events within a session) - I'm
wondering what you call it.  Is it a 'thread' or a 'threadoid'?  Just
curious what terminology you use.

I'm working on a program that has several threads or 'event chains' as I
call them.  I'm trying to document my program with intuitive terms that
would make sense to someone familiar with POE.

So, in the context of POE, do you call them 'threads' or is there a
better expression to be used?

Thanks,
MC

Re: POE newbie question

[Matt Sickler]

select_read( $socket, "event to fire") tells the kernel to fire the event
"event to fire" to the current session whenever there is data that can be
read from $socket

yield("event") tells the kernel to queue the signal, event, whatever you
want to call it, to the current session

On 2/23/07, Fei Liu <[EMAIL PROTECTED]> wrote:


P Dobranski wrote:
> POE::Kernel::yield is sort of a shortcut for 'post'.
> You 'yield' an event in the current session.
> It is the same as 'post'ing the event to the current session.
>
> $kernel->yield('some_event_handler');
>
> is roughly the same as
> $kernel->post($my_session, 'some_event_handler');
>
> (assuming both statements happen in the same session).
>
> select_read/select_write allow you to get events when a file
> descriptor becomes ready to read or write without you having to manage
> your own select() loops.
>
> On 2/22/07, Fei Liu <[EMAIL PROTECTED]> wrote:
>>
>> Hi group, just wondering what's the difference between
>> POE::Kernel::select_read/write method and POE::Kernel::yield method?
How
>> should I use select_read/select_write? Do they do anything special
about
>> the events that they select? Thanks,
>>
>> Fei

Thanks for your reply. I was reading Rocco's tutorial
(http://poe.perl.org/?Evolution_of_a_POE_Server) on POE and my question
came up when he first introduced POE framework to replace the original
non-blocking tcp echo server. In the example no Wheel or
Component::Server::TCP were used, it was basic POE::Session.

POE::Session->create
  ( inline_states =>
  { _start => \&server_start,
event_accept => \&server_accept,
event_read   => \&client_read,
event_write  => \&client_write,
event_error  => \&client_error,
  }
  );

sub server_start {
my $server = IO::Socket::INET->new
  ( LocalPort => 12345,
Listen => 10,
Reuse  => "yes",
  ) or die "can't make server socket: [EMAIL PROTECTED]";

$_[KERNEL]->select_read( $server, "event_accept" );
}

Here it seems select_read works sort of like yield, doesn't it? It
yields to event_accept handler? Quote 'The _start handler creates the
server socket and allocates its event generator with select_read()",
what's a event generator and what does it do?

Another thing confusing me here is that there seems to be a total of one
session in this echo server implementation, how can it handle mutliple
clients?

Sorry for so many questions, I can use POE just fine but I want to
understand what's going on under the hood.

Fei

Re: POE newbie question

[Matt Sickler]

select_read and select_write tell POE::Kernel to watch a filehandle for
those states

$poe_kernel->yield() its NOT like Thread's yield().  NOT AT ALL.

read the perldoc on POE::Kernel to see what yield() does (ditto on the other
two)

POE is quite well documented

On 2/22/07, Fei Liu <[EMAIL PROTECTED]> wrote:


Hi group, just wondering what's the difference between
POE::Kernel::select_read/write method and POE::Kernel::yield method? How
should I use select_read/select_write? Do they do anything special about
the events that they select? Thanks,

Fei

Re: Performing actions _after_ PoCo::Server::TCP shuts down

[Matt Sickler]

in any case the post() would fail because no session can message another
session within _stop states

On 2/21/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:


I'm trying to figure out how to schedule an action to happen after my
PoCo::Server::TCP shuts down.  I.e., after all the pending requests
have finished processing.  I tried doing it through _stop like this,
but it didn't work:

   POE::Component::Server::TCP->new
   ( Alias => 'server',
 Port => $port,
 ClientFilter => 'POE::Filter::HTTPD',
 ClientInput => \&dispatch,
 PackageStates => [ main => [ ...
  "_stop"
],
],
 );


...

sub _stop {
  warn "STOP CALLED";
  $_[KERNEL]->post("BlahBlah" => "cleanup");
   }


In fact, _stop() was never called.


I see that PoCo::Server::TCP can take a Started callback, but no
Stopped/Shutdown callback.

Is there some other way I should be approaching this?


Thanks,

-kevin

Re: POE & DBI

[Matt Sickler]

yes, DBI  and PoCoEasyDBI work just fine on windows

On 2/21/07, Bill Nash <[EMAIL PROTECTED]> wrote:



Well...

A better question would be: Do Perl and DBI work with windows?

- billn

On Wed, 21 Feb 2007, Mathieu Longtin wrote:

> Do any of them work with windows?
>
> On 2/21/07, Matt Sickler <[EMAIL PROTECTED]> wrote:
> >
> > POE::Component::EasyDBI is what I use - quite simple and can be
powerful
> >
> > On 2/20/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:
> > >
> > > Anyone want to strongly advocate for one of the four or so
components
> > > that comes up on a CPAN search for "POE DBI"?
> > >
> > > -kevin
> > >
> >
>
>
>
>

Re: POE & DBI

[Matt Sickler]

POE::Component::EasyDBI is what I use - quite simple and can be powerful

On 2/20/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:


Anyone want to strongly advocate for one of the four or so components
that comes up on a CPAN search for "POE DBI"?

-kevin

Re: non-interactive child processes?

[Matt Sickler]

sounds like a simple Component wrapper - POE::Component::Child::Simple or
something
your description of what you want is nearly pseudo code

you might want to look into PoCo::Child or the likes, I personally havent
used them so I dont know anything about them.

On 1/20/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:


Yes, but you can't just provide a CloseEvent to Wheel::Run, and the
arguments that CloseEvent are called with do not include any of the
output of the program.

What I'm talking about is basically having a StdoutEvent that
concatenates all the output and stores it in the heap, and a
StderrEvent that does something similar, and then a CloseEvent that
reads that stuff out of the heap and processes it.  But, I'd rather
not have all my users have to do that, so what I'm looking for is a
simplified API that hides all that.  It doesn't seem that hard to do,
but I can't find anything published on CPAN that does it.


-kevin


On Jan 19, 2007, at 11:02 PM, Matt Sickler wrote:

> I believe you can use Wheel::Run and theres a CloseEvent or the like
>
> On 1/20/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:
>>
>> I figure I can write this myself easily enough, but I'm wondering if
>> there's a module already for this task.  I want to run command-line
>> functions which I know to be non-interactive.  Of course,
>> POE::Wheel::Run and POE::Component::Child can do this, but their
>> interfaces are overly complicated for what I need in this
>> application.  I'm not expecting to need to write anything to the
>> child process, so rather than incrementally receiving data from
>> stdout and stderr, I'd rather just defer until the process terminates
>> and then have a single callback called with all the stdout and all
>> the stderr and the exit code.  Am I missing a module that does this
>> already?
>>
>> Thanks,
>>
>> -kevin
>>

Re: non-interactive child processes?

[Matt Sickler]

I believe you can use Wheel::Run and theres a CloseEvent or the like

On 1/20/07, Kevin Scaldeferri <[EMAIL PROTECTED]> wrote:


I figure I can write this myself easily enough, but I'm wondering if
there's a module already for this task.  I want to run command-line
functions which I know to be non-interactive.  Of course,
POE::Wheel::Run and POE::Component::Child can do this, but their
interfaces are overly complicated for what I need in this
application.  I'm not expecting to need to write anything to the
child process, so rather than incrementally receiving data from
stdout and stderr, I'd rather just defer until the process terminates
and then have a single callback called with all the stdout and all
the stderr and the exit code.  Am I missing a module that does this
already?

Thanks,

-kevin

Re: Serial communications

[Matt Sickler]

and even if it doesnt, you can use Wheel::Run or Wheel::Generic to fork it
away

On 12/8/06, Michael Erskine <[EMAIL PROTECTED]> wrote:


On Friday 08 December 2006 05:20, Rocco Caputo wrote:
> The poor Win32 users have bigger problems.  Namely that perl's select
> () is written in terms of winsock's select() function, so you can
> only use perl's select on sockets.  Even if you do properly configure
> the port, you can't multiplex it...

Yup, it's true that Win32 users have bigger problems but the
Win32::SerialPort
module works well and I'm sure it can play nicely with POE (although I
admit
I know nothing of POE internals!)

Regards,
Michael Erskine.

--
"Are you sure you're not an encyclopedia salesman?"
No, Ma'am.  Just a burglar, come to ransack the flat."
-- Monty Python

Re: Serial communications

[Matt Sickler]

isnt serial comms done with readwrite on /dev/serialdevice or something?
although that is a good idea to write a Driver for serial comms.


On 12/5/06, Nicholas Perez <[EMAIL PROTECTED]> wrote:


I guess it would help if I copied the list...

-- Forwarded message --
From: Nicholas Perez <[EMAIL PROTECTED]>
Date: Dec 5, 2006 11:17 PM
Subject: Re: Serial communications
To: lanas <[EMAIL PROTECTED]>


My two US$0.02:

Write a configurable Filter (make meaningful objects from input).
Write a configurable Driver (handle all the nasty flow control etc
here). Then add those two things into a generic Wheel::ReadWrite. And
then it is trivial to write a POE::Component that uses these things to
cut out some of the tedium.

For all the low level serial stuff, I would probably reference one of
the serial modules for how they do it, and then adapt it into a more
POE-ish way of thinking. This way you get the benefit of reuse (sort
of), and the benefit of NOT trying to shoe-horn in a blocking beast of
code. As long as you meet the interface requirements of POE::Driver,
you are pretty much free to do whatever it takes.

On 12/5/06, lanas <[EMAIL PROTECTED]> wrote:
> Folks,
>
>   Recently I've asked about serial communications.  If I'd like to add
> serial communications support to POE, what would be the best way to do
> this ?  By using an existing Perl module and wrapping around it or by
> writing serial comms from scratch ?
>
>   (You may file that as a meditative question... ;-)
>
> Cheers,
> Al
>

Re: POE::Kernel->run() returning?

[Matt Sickler]

run() only returns when all sessions have died.
A session dies when there is nothing left for it to process; an alias doesnt
keep it alive when the only thing keeping every session alive is an alias.

On 10/25/06, Tom Lanyon <[EMAIL PROTECTED]> wrote:


Hi All,

Having a problem with a small app I was fiddling with.

I have ASSERT_DEFAULT and TRACE_DEFAULT on and I can see all my sessions
being created,
and at the end of the test script I call $poe_kernel->run(), however I'm
receiving a
"POE::Kernel's run() method was never called".

To debug, I've removed all processing code from the application and
basically left it
at just creating sessions and then calling $poe_kernel->run(). In this
form, I no longer
receive the 'run method was never called' error however the script just
continues after
run() is called.

It was my understanding that run() would never return and that a POE app
will only end
once all sessions have nothing left to do. So, when all my sessions have
aliases, should
it not just sit there until I kill it?

Mildly confused,
Tom

--
Tom Lanyon

Re: Brace yourself. POE 0.38 is uploaded to PAUSE.

[Matt Sickler]

you can also use refcount_increment() - which is more work, but at least you
get to decide whether watching for a signal keeps you alive

On 19 Sep 2006 08:18:59 -0700, Randal L. Schwartz 
wrote:


> "Rocco" == Rocco Caputo <[EMAIL PROTECTED]> writes:

Rocco> + The sig() reference count has been removed.  There will be
much  rejoicing,
Rocco> and probably some gnashing of teeth.

I've not been following.  Is this an even-numbered week or an odd numbered
week?  As in, if a session is waiting for a real or artificial signal is
that
still enough to keep it alive, or has that now gone away?  If it's gone
away,
what's the pattern I'll need to keep it around... create an artifically
delayed bogus event?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
0095
 http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl
training!

Re: POE 0.38 change of plans

[Matt Sickler]

use POE::API::Peek;
my $api = POE::API::Peek->new();
my @sessions = $api->session_list();

# cheers

On 9/10/06, Maciej Pijanka <[EMAIL PROTECTED]> wrote:


On 10/09/06, Rocco Caputo <[EMAIL PROTECTED]> wrote:
> The sig() reference count rollback went easier than planned.  It's
> done, tested, and committed now.  People with extra concerns about it
> should consider testing against the repository before the next release.
>
> It was so easy that I'm going to add the sig_chld() watcher and
> release both as 0.38.  That'll be one less CPAN release to test or
> ignore before everything's fixed.  I hope.
>
> Are there any other signals issues/quirks/requirements I should
> address while I'm in here?
>

an method allowing to get session list without peeking at POE kernel
internals?

--
Maciej Pijanka
Linux user #133161

Re: signal design discussions from IRC, leading up to 0.33's change of sig() persistence

[Matt Sickler]

I dont use signals all that much or POE, but I thought Id put in my 2 cents.

IMO, signals should mirror UNIX signals - they dont keep a session alive.  I
hear that this can cause problems with certain signals, so someone suggested
adding a sig() that keeps a session alive.  Rocco didnt like having two
method calls for slightly different semantics.
Perhaps we could fall in the middle: sig() doesnt keep a session alive
UNLESS you ask it to.  sig( "SIGNAL" => 'state' ) doesnt keep a session
alive, but sig( "SIGNAL" => 'state', -keepalive ) would.
Theres two sides to this fence, and only implementing one side is going to
make the other unhappy.  Straddling the fence isnt desireable, but it looks
to be the best option.

Another thing I did think of recently is that only signals that require to
keep a session alive keep them alive.  DIE, TERM, USR1, etc wouldnt keep a
session alive, but the ones that need to ( UI_DESTROY was mentioned in this
case ) would keep a session alive.

PS. Sorry if that sounds like a bunch of rambling.

On 8/23/06, Nick Williams <[EMAIL PROTECTED]> wrote:


Rocco Caputo wrote:

> Attached as a gzipped text file.  Sorry for posting a "binary", but I
> couldn't pass up the 3:1 compression.  Please quote relevant parts of
> the discussion if you want to comment on things.  Total time to cull
> and clean this, about 90 minutes.
>
> I hope it explains the motivations and reasoning behind the sig()
> semantics change.  Armed with the full context, we might be able to
> come up with a better and lasting resolution to the signals problems.
>
> Regarding SIGCHLD, I think Philip Gwyn later suggested some form of
> process ID watcher to supplant the signal.  I don't think he proposed
> it on the list, though.
>
>
Gosh, thanks for spending that time and providing the discussion, it's
quite a fair amount of reading and most valuable :-).

To my mind, the initial part of the discussion regarding SIGCHLD is
completely orthogonal to the later problem discussed of reference
counts. I'm fine with the way that the SIGHCHLD discussion turned out
(and btw, in case anyone cares, I'm one of those people that was bitten
by system() and qx() going wrong when using POE - the reason being that
I don't just use POE, I sometimes (shock horror) use OTHER perl modules
too. One doesn't always have control of what those other modules might
be doing in their depths and system() is one of those things...) :-). We
have some systems written with POE that use over 200 different modules.
Tracking downstream modules for their use of system() is just not
feasible.

So, the SIGCHLD part good. Now let's move onto the reference counting.
The discussion implies that the reference counting is neccessary for the
SIGCHILD reform. Now that's the bit that's confusing me.

>10:13 @   hachi : shouldn't a signal handler keep any session
alive, no matter what?
>10:44 @   dngor : Signal handlers don't affect reference counts.
>11:01 @   hachi : now that has me puzzled
>11:02 @   hachi : signal handlers are IPC, like filehandles... why
don't they keep sessions alive?

That's a misnomer. A handler isn't an IPC like a filehandle. As has been
said previously, if you look at UNIX semantics, signals are very very
different. And BTW, the "ultimate" example of this is the DIE handler.
If I put in place a DIE handler, it's because of defensive programming
(all those external 200 modules :-): I do not EXPECT nor WANT a DIE to
actually happen. However, if I put in place a DIE handler, my session
becomes persistent. And there's a possible race condition with me
removing the DIE handler when I *think* my session is going to die (but
hasn't yet reached _stop, and so could quite easily still get a DIE) and
the session really evaporating.

>11:05 @   dngor : Requiring interest in a signal to be registered
explicitly is a relatively new advancement.  Now that we have it, I
don't see why not.
>11:25 @   hachi : well, I think it might have to happen, at least
in the case of a CHLD handler, because you can't have that signal
watcher dying off silently on people


So, that last comment is one of the spurs for putting in reference
counting. I've been misled by reading the RT stuff saying that the
refcounting was there for the UI_DESTROY problem. Okay. So

I *guess* that the signal watcher logic is only invoked if there's
someone interested in SIGCHLD. If there's nobody interested in SIGCHLD,
then the default behaviour can work just fine. Is that true? And then
the follow-on is that if someone was previously interested in SIGHCHLD
and then they say they're not, what happens? If the signal handler
reverts back to normal perl semantics, then I don't see a problem with
the signal watcher no longer spinning. So, I can't quite see how this
adds up to requiring persistent sessions. I feel very much that I'm
missing some understanding here of how the SIGCHLD stuff has been done.
I'll go away and read code while waiting for others to correct

Re: rt.cpan.org rt19037 Possible security bug in POE

[Matt Sickler]

Hello dazjorz,
 I looked over your code from the ticket and I found your problem.
When you set the kill_after_flush, you set it globally for all connections
created.
To get a per-connection flag access the kill_after_flush flag with:
$_[HEAP]->{kill_after_flush}->{$wheel_id}
-- OR --
Use POE::Component::Server::TCP which creates a complete session to handle
each incoming connection.

Re: POE message not sent or received

[Matt Sickler]

What is it that your trying to accomplish?  This will help us suggest
what to use.

On 2/25/06, lanas <[EMAIL PROTECTED]> wrote:
> Rocco Caputo <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> > {Inline,Object,Package}States apply to each connection session, not
> > the main server session for the component. You can certainly send
> > arbitrary messages to the server session, but it will not handle them.
>
> Is there a way, then, for a session to tell the TCP server component to
> send data to its already connected (external to POE) client ?
>
> Would it be otherwise possible, by using a Socket Factory and a R/W
> Wheel instead of a component ? Would two servers built like this be able
> to communicate to each other using POE messages targeted at their
> respective POE Sessions ?
>
> Thanks !
>
>
>