Ports Search

PatchReader is a set of utilities for reading in, transforming, and doing various other things with a patch. It basically allows you to create a chain of readers that can read a patch, remove files from a patch, add CVS context, fix up the patch root according to CVS, and output the patch as raw unified or through a template processor (used in some places to output a patch as HTML).

If you need nonblocking access to an external program, or want to execute some blocking code in a separate process, but you don't want to write a wrapper module or some POE::Wheel::Run boilerplate code, then POE::Quickie can help. You just specify what you're interested in (stdout, stderr, and/or exit code), and POE::Quickie will handle the rest in a sensible way. It has some convenience features, such as killing processes after a timeout, and storing process-specific context information which will be delivered with every event. There is also an even lazier API which suspends the execution of your event handler and gives control back to POE while your task is running, the same way LWP::UserAgent::POE does. This is provided by the quickie_* functions which are exported by default.

POE::Session::MultiDispatch is a drop in replacement for POE::Session that adds callback dispatch functionality to POE sessions. Each event may have multiple handlers associated with it. Fine control over the order of execution is available using helper methods that extend the interface of a POE::Session. POE::Session::MultiDispatch uses POE::Session as a base class. When multiple callbacks are registered for an event, only the last callback survives, all the others are clobbered. POE::Session::MultiDispatch is much nicer to your registered callbacks, it keeps them all in the order they were defined. When an event is triggered, all the callbacks are then executed in that same order (unless you muck around with said order).

POE::Stage is a proposed base class for POE components. Its purpose is to standardize the most common design patterns that have arisen through years of POE::Component development.

POE::Test::Loops contains one function, generate(), which will generate all the loop tests for one or more POE::Loop subclasses.

Implementation of the abstract POE::Loop interface written in C using the poll(2) system call.

This class is an implementation of the abstract POE::Queue interface. It implements a priority queue using C, with an XS interface supplied.

POE is a general purpose multitasking and networking framework. POE does standard event loop things, cooperative multitasking, network clients and servers; includes a high level class library that takes care of event driven I/O; provides a framework for portable program components.

POEx::Role::SessionInstantiation provides a nearly seamless integration for non-POE objects into a POE environment. It does this by handling the POE stuff behind the scenes including allowing per instances method changes, session registration to the Kernel, and providing some defaults like setting an alias if supplied via the attribute or constructor argument, or defining a _default that warns if your object receives an event that it does not have. This role exposes your class' methods as POE events.

POEx::Role::Streaming provides a common idiom for streaming data from one filehandle to another. It accomplishes this by making good use of sysread and POE::Wheel::ReadWrite. This Role errs on the side of doing as many blocking reads of the "input_handle" as possible up front (until the high water mark is hit on the Wheel). If this default isn't suitable for the consumer, simply override "get_data_from_input_handle". After Streamer has exhausted the source, and flushed the last of the output, it will clean up after itself by closing the wheel, the handles, and sending all of them out of scope. If an exception happens, it will clean up after itself, and let the DIE signal propagate.