Ports Search

This class implements a simple state machine pattern, allowing you to quickly build rules-based state machines in Perl. As a simple implementation of a powerful concept, it differs slightly from an ideal DFA model in that it does not enforce a single possible switch from one state to another. Rather, it short circuits the evaluation of the rules for such switches, so that the first rule to return a true value will trigger its switch and no other switch rules will be checked. (But see the strict attribute and parameter to new().) It differs from an NFA model in that it offers no back-tracking. But in truth, you can use it to build a state machine that adheres to either model--hence the more generic FSA moniker.

Pit is a command-line project manager that integrates with Git. Basic Pit entities are projects, tasks, and notes. One project can have multiple tasks, and a task can have multiple notes. Each entity has a number of attributes. For example, project has name and status, task has name, status, priority, date, and time, and within note there is message body. All attributes except name and message body are optional and can be omitted. The attributes have no semantic meaning, and do not have a pre-defined set of values. For example, depending on the particular need, the time attribute could be used as projected time in weeks, hours spent on the task, or days left to finish the task. Pit tries to maintain a notion of "current" project, task, or note. When you create new project, it automatically becomes current. If you do not specify project number when creating a task, the new task will be associated with the current project.

This module is meant to be the definitive implementation of iterators, as popularized by Mark Jason Dominus's lectures and recent book (Higher Order Perl, Morgan Kauffman, 2005). An "iterator" is an object, represented as a code block that generates the "next value" of a sequence, and generally implemented as a closure. When you need a value to operate on, you pull it from the iterator. If it depends on other iterators, it pulls values from them when it needs to. Iterators can be chained together (see Iterator::Util for functions that help you do just that), queuing up work to be done but not actually doing it until a value is needed at the front end of the chain. At that time, one data value is pulled through the chain. Iterator.pm provides a class that simplifies creation and use of these iterator objects. Other Iterator:: modules (see "SEE ALSO") provide many general-purpose and special-purpose iterator functions.

There's a whole bunch of class builders out there. In fact, creating a class builder seems to be something of a rite of passage (this is my fifth, at least). Unfortunately, most of the time I want a class builder I'm in a hurry and sketching out lots of fairly simple data classes with fairly simple structure, mostly just read-only accessors, and that's about it. Often this is for code that won't end up on CPAN, so adding a small dependency doesn't matter much. I just want to be able to define these classes FAST. By which I mean LESS typing than writing them by hand, not more. And I don't need all those weird complex features that bloat out the code and take over the whole way I build modules. And so, I present yet another member of the Tiny family of modules, Object::Tiny.

This is a sister module of Parse::PMFile. This module parses local .pm files (and a META file if any) in a specific (current if not specified) directory, and returns a hash reference that represents "provides" information (with some extra meta data). This is almost the same as Module::Metadata does (which has been in Perl core since Perl 5.13.9). The main difference is the most of the code of this module is directly taken from the PAUSE code as of June 2013. If you need better compatibility to PAUSE, try this. If you need better performance, safety, or portability in general, Module::Metadata may be a better and handier option (Parse::PMFile (and thus Parse::LocalDistribution) actually evaluates code in the $VERSION line (in a Safe compartment), which may be problematic in some cases).

This module is a first crack at providing a consistent interface to Unix (and maybe other multitasking OS's) process table information. The impetus for this came about with my frustration at having to parse the output of various systems' ps commands to check whether specific processes were running on different boxes at a large mixed Unix site. The output format of ps was different on each OS, and sometimes changed with each new release of an OS. Also, running a ps subprocess from within a perl or shell script and parsing the output was not a very efficient or aesthetic way to do things. With this module, you can do things like this: # kill memory pigs use Proc::ProcessTable; $t = new Proc::ProcessTable; foreach $p ( @{$t->table} ){ if( $p->pctmem > 95 ){ $p->kill(9); } }

Releasing a new version of software takes a lot of steps... finding the next version number (and making sure you didn't already use that version number before), making sure your changelog is updated, making sure your "make dist" results in a tarball that builds, committing changes (with updated version number), tagging, and uploading the tarball somewhere. Or maybe more steps. Or not some of the above. Maybe you forgot something! And maybe you manage multiple projects, and each project has a different release process. This is all a pain in the ass. You want to be hacking, not jumping through hoops. Your contributors want to see their patches actually make it into a release, which won't happen if you're afraid of releases. shipit automates all the hell. It makes life beautiful.

Test::WWW::Mechanize is a subclass of WWW::Mechanize that incorporates features for web application testing. The Test::WWW::Mechanize::Catalyst module meshes the two to allow easy testing of Catalyst applications without needing to starting up a web server. Testing web applications has always been a bit tricky, normally requiring starting a web server for your application and making real HTTP requests to it. This module allows you to test Catalyst web applications but does not require a server or issue HTTP requests. Instead, it passes the HTTP request object directly to Catalyst. Thus you do not need to use a real hostname: "http://localhost/" will do. However, this is optional. The following two lines of code do exactly the same thing:

Starting with Perl 5.10, it is possible to create a lexical version of the Perl default variable $_. Certain Perl constructs like the given keyword automatically use a lexical $_ rather than the global $_. It is occasionallly useful for a sub to be able to access its caller's $_ variable regardless of whether it was lexical or not. The (_) sub prototype is the official way to do so, however there are sometimes disadvantages to this; in particular it can only appear as the final required argument in a prototype, and there is no way of the sub differentiating between an explicitly passed argument and $_. The lexical::underscore function returns a scalar reference to either a lexical $_ variable somewhere up the call stack (using PadWalker magic), or to the global $_ if there was no lexical version. Wrapping lexical::underscore in ${ ... } dereferences the scalar reference, allowing you to access (and even assign to) it.

`slibtool` is an independent reimplementation of the widely used libtool, written in C. `slibtool` is designed to be a clean, fast, easy-to-use libtool drop-in replacement, and is accordingly aimed at package authors, distro developers, and system integrators. `slibtool` maintains compatibility with libtool in nearly every aspect of the tool's functionality as well as semantics, leaving out (or turning into a no-op) only a small number of features that are no longer needed on modern systems. Being a compiled binary, and although not primarily written for the sake of performance, building a package with `slibtool` is often faster than with its script-based counterpart. The resulting performance gain would normally vary between packages, and is most noticeable in builds that invoke libtool a large number of times, and which are characterized by the short compilation duration of individual translation units.