Ports Search

The Proc::Reliable is intended to be a method for simple, reliable and configurable subprocess execution in PERL. It includes all the functionality of the backticks operator and system() functions, plus many uses of fork/exec, open2() and open3(). Proc::Reliable incorporates a number of options, including sending data to the subprocess on STDIN, collecting STDOUT and STDERR separately or together, killing hung processes, timeouts and automatic retries. Seamus Venasse <svenasse@polaris.ca>

This is a rather simplistic lexer and tokenizer for the RPSL language. It currently does not validate the object in any way, it just tries (rather hard) to grab the biggest ammount of information it can from the text presented and place it in a Parse Tree (that can be passed to other objects from the RPSL namespace for validation and more RFC2622 related functionality).

Support for the foreach looping construct. Foreach is an idiom that allows for iterating over elements in a collection, without the use of an explicit loop counter. This package in particular is intended to be used for its return value, rather than for its side effects. In that sense, it is similar to the standard lapply function, but doesn't require the evaluation of a function. Using foreach without side effects also facilitates executing the loop in parallel.

Perl 5 ships with a module called Term::ReadLine which is an interface to command line editing and recall. The version that ships with Perl is only a stub, and offers little functionality. This module supplements Term::ReadLine so that it uses GNU readline, which comes with FreeBSD. Applications that use Term::ReadLine do not need to be modified to gain the benefits of this package; it will happen transparently upon installation.

When coding it is common to come up against problems that need to be addressed but that are not a big deal at the moment. What generally happens is that the coder adds comments like: # FIXME - what about windows that are bigger than the screen? # FIXME - add checking of user priviledges here. Test::Fixme allows you to add a test file that ensures that none of these get forgotten in the module.

This modules causes any warnings produced by test scripts to be captured and stored. It automatically adds an extra test that will run when your script ends to check that there were no warnings. If there were any warnings, the test will give a "not ok" and diagnostics of where, when and what the warning was, including a stack trace of what was going on when the it occurred.

Test::Output provides a simple interface for testing output sent to STDOUT or STDERR. A number of different utilities are included to try and be as flexible as possible to the tester. Originally this module was designed not to have external requirements, however, the features provided by Sub::Exporter over what Exporter provides is just to great to pass up. Test::Output ties STDOUT and STDERR using Test::Output::Tie.

These routines are the inverse of built-in perl functions localtime() and gmtime(). They accept a date as a six-element array, and return the corresponding time(2) value in seconds since the system epoch (Midnight, January 1, 1970 UTC on Unix, for example). This value can be positive or negative, though POSIX only requires support for positive values, so dates before the system's epoch may not work on all operating systems.

Odfpy aims to be a complete API for OpenDocument in Python. Unlike other more convenient APIs, this one is essentially an abstraction layer just above the XML format. The main focus has been to prevent the programmer from creating invalid documents. It has checks that raise an exception if the programmer adds an invalid element, adds an attribute unknown to the grammar, forgets to add a required attribute or adds text to an element that doesn't allow it.

Advanced Python Scheduler (APScheduler) is a Python library that lets you schedule your Python code to be executed later, either just once or periodically. You can add new jobs or remove old ones on the fly as you please. If you store your jobs in a database, they will also survive scheduler restarts and maintain their state. When the scheduler is restarted, it will then run all the jobs it should have run while it was offline.