Free poe software for linux

POE::Loop is a documentation for POEs event loop bridge interface.

SYNOPSIS

$kernel->loop_initialize();
$kernel->loop_finalize();
$kernel->loop_do_timeslice();
$kernel->loop_run();
$kernel->loop_halt();

$kernel->loop_watch_signal($signal_name);
$kernel->loop_ignore_signal($signal_name);
$kernel->loop_attach_uidestroy($gui_window);

$kernel->loop_resume_time_watcher($next_time);
$kernel->loop_reset_time_watcher($next_time);
$kernel->loop_pause_time_watcher();

$kernel->loop_watch_filehandle($handle, $mode);
$kernel->loop_ignore_filehandle($handle, $mode);
$kernel->loop_pause_filehandle($handle, $mode);
$kernel->loop_resume_filehandle($handle, $mode);

POEs runtime kernel abstraction uses the "bridge" pattern to encapsulate services provided by different event loops. This abstraction allows POE to cooperate with several event loops and support new ones with a minimum amount of work.
POE relies on a relatively small number of event loop services: signal callbacks, time or alarm callbacks, and filehandle activity callbacks.

The rest of the bridge interface is administrative trivia such as initializing, executing, and finalizing event loop.

POE::Kernel uses POE::Loop classes internally as a result of detecting which event loop is loaded before POE is. You should almost never need to use a POE::Loop class directly, although there is some early support for doing so in cases where its absolutely necessary.

See "Using POE with Other Event Loops" in POE::Kernel for details about actually using POE with other event loops.

POE::Stage is a base Perl class for message-driven objects.

SYNOPSIS

#!/usr/bin/env perl
{
package App;
use POE::Stage::App qw(:base);
sub on_run {
print "hello, ", my $arg_whom, "!n";
}
}
App->new()->run( whom => "world" );
exit;

POE::Stage is a set of base classes for message-driven objects. It cleanly implements standard patterns that have emerged from years of working with POE and POE::Component modules.

As I hope the name implies, POE::Stage objects encapsulate discrete steps, or stages, of a larger task. Eventually they come together to implement programs.
For example, HTTP requests are performed in four or so distinct stages: 1. The servers address is resolved. 2. The client establishes a connection to the server. 3. The client transmits a request. 4. The client receives a response.

By design, POE::Stage promotes the decomposition of tasks into multiple, smaller stages. If these stages are generic enough, new tasks may be handled by reusing them in different configurations.

The hypothetical HTTP client might be a single stage composed of three smaller ones: A DNS resolver stage, which accepts DNS requests and returns DNS responses. A TCP client connection factory, which takes socket endpoint descriptions and other parameters, and eventually returns established connections. Finally, there would be an HTTP protocol stage that uses established connections to send requests and parse responses.

These stages would be encapsulated by a higher-level HTTP client stage. This would accept HTTP requests and return HTTP responses after performing the necessary steps to gather them.

This will sound familiar to anyone working with objects.

These objects are asynchronous and message-driven, however. The base message class, POE::Request, and its subclasses, implement a standard request/response interface between POE::Stage objects. Where possible, these messages attempt to mimic simpler, more direct call/return syntax, albeit asynchronously. POE::Stage also provides a powerful closure-based system for maintaining request and response state, so you dont have to.

POE::Filter::LZW::Progressive is a POE filter wrapped around Compress::LZW::Progressive.

POE::Loop::Event is a bridge that supports Gtks event loop from POE.

SYNOPSIS

See POE::Loop.

This class is an implementation of the abstract POE::Loop interface. It follows POE::Loops public interface exactly. Therefore, please see POE::Loop for its documentation.

POE::Exceptions is a POE class for handling exceptions.

SYNOPSIS

use POE::Exceptions;

POE::Session::Exception->create(
inline_states => {
_start => sub { print START;
$_[KERNEL]->sig(DIE,death_handled);
},
death_handled => sub { print EXCEPTION CAUGHT
$_[KERNEL]->sig_handled();
},
_stop => { print END }
}
);

$poe_kernel->run();

DEPRECATION

This module is deprecated as its functionality has been rolled into the POE core, as of POE 0.33. This module will receive no updates and will be removed from CPAN at some point in the near future.

DISCUSSION

POE::Exceptions extends POE to catch exceptions neatly. A new signal, DIE, is introduced. This signal will be fired every time an exception occurs. (For those of you new to the term exception, an exception is whenever the code decides to bail out by dieing.) If the signal handler returns 1 (as in the example above), POE will assume that the handler dealt with the signal appropriately. If the signal handler returns 0, POE will assume that the handler does not want to deal with the signal and POE will propgate the exception as if the handler never existed.

Caveat: POE::Exceptions will die on its own in the case of a double exception fault. If the DIE signal handler itself throws an exception, POE::Exceptions will shut the program down and bail out.

POE::Component::IRC is a fully event-driven IRC client module.

SYNOPSIS

# A simple Rot13 encryption bot

use strict;
use warnings;
use POE qw(Component::IRC);

my $nickname = Flibble . $$;
my $ircname = Flibble the Sailor Bot;
my $ircserver = irc.blahblahblah.irc;
my $port = 6667;

my @channels = ( #Blah, #Foo, #Bar );

# We create a new PoCo-IRC object and component.
my $irc = POE::Component::IRC->spawn(
nick => $nickname,
server => $ircserver,
port => $port,
ircname => $ircname,
) or die "Oh noooo! $!";

POE::Session->create(
package_states => [
main => [ qw(_default _start irc_001 irc_public) ],
],
heap => { irc => $irc },
);

$poe_kernel->run();
exit 0;

sub _start {
my ($kernel,$heap) = @_[KERNEL,HEAP];

# We get the session ID of the component from the object
# and register and connect to the specified server.
my $irc_session = $heap->{irc}->session_id();
$kernel->post( $irc_session => register => all );
$kernel->post( $irc_session => connect => { } );
undef;
}

sub irc_001 {
my ($kernel,$sender) = @_[KERNEL,SENDER];

# Get the components object at any time by accessing the heap of
# the SENDER
my $poco_object = $sender->get_heap();
print "Connected to ", $poco_object->server_name(), "n";

# In any irc_* events SENDER will be the PoCo-IRC session
$kernel->post( $sender => join => $_ ) for @channels;
undef;
}

sub irc_public {
my ($kernel,$sender,$who,$where,$what) = @_[KERNEL,SENDER,ARG0,ARG1,ARG2];
my $nick = ( split /!/, $who )[0];
my $channel = $where->[0];

if ( my ($rot13) = $what =~ /^rot13 (.+)/ ) {
$rot13 =~ tr[a-zA-Z][n-za-mN-ZA-M];
$kernel->post( $sender => privmsg => $channel => "$nick: $rot13" );
}
undef;
}

# We registered for all events, this will produce some debug info.
sub _default {
my ($event, $args) = @_[ARG0 .. $#_];
my @output = ( "$event: " );

foreach my $arg ( @$args ) {
if ( ref($arg) eq ARRAY ) {
push( @output, "[" . join(" ,", @$arg ) . "]" );
} else {
push ( @output, "$arg" );
}
}
print STDOUT join , @output, "n";
return 0;
}

POE::Component::IRC is a POE component (whod have guessed?) which acts as an easily controllable IRC client for your other POE components and sessions. You create an IRC component and tell it what events your session cares about and where to connect to, and it sends back interesting IRC events when they happen. You make the client do things by sending it events. Thats all there is to it. Cool, no?

[Note that using this module requires some familiarity with the details of the IRC protocol. Id advise you to read up on the gory details of RFC 1459 before you get started. Keep the list of server numeric codes handy while you program. Needless to say, youll also need a good working knowledge of POE, or this document will be of very little use to you.]
The POE::Component::IRC distribution has a docs/ folder with a collection of salient documentation including the pertinent RFCs.

POE::Component::IRC consists of a POE::Session that manages the IRC connection and dispatches irc_ prefixed events to interested sessions and an object that can be used to access additional information using methods.

Sessions register their interest in receiving irc_ events by sending register to the component. One would usually do this in your _start handler. Your session will continue to receive events until you unregister. The component will continue to stay around until you tell it not to with shutdown.

The SYNOPSIS demonstrates a fairly basic bot.

SYNOPSIS

use POE::Filter::ErrorProof;
my $wheel = POE::Wheel::ReadWrite->new(
Filter => POE::Filter::ErrorProof->new(POE::Filter::Something->new()),
);

This module is a wrapper around other POE::Filters. I made this module when I noticed POE::Filter::XML would die() when non-XML input was given to it. The author of the module wasnt there, so I had to bring up a solution. You can use this module if you use a POE::Filter that might die if something bad happens. This Filter does nothing more than giving through the input in eval blocks.

THE NEW METHOD

POE::Filter::ErrorProof->new(); # Create a POE::Filter::ErrorProof with a POE::Filter::Stream in it
POE::Filter::ErrorProof->new(POE::Filter::XML->new()); # Do the same but with a POE::Filter::XML
POE::Filter::ErrorProof->new(POE::Filter::XML->new(), 1); # Do the same, but output errors on STDERR
POE::Filter::ErrorProof->new(POE::Filter::XML->new(), $socket); # Do the same, but output errors on this socket
$wheel = POE::Wheel::ReadWrite->new( .... );
POE::Filter::ErrorProof->new(POE::Filter::XML->new(), $wheel); # Output errors to this wheel