Mac::FileSpec::Unixish provides two functions, `nativize' and `unixify'
(both of which are exported by default), that will allow you to denote
and manipulate pathspecs in Unixish style, and let you convert these
pathspecs to and from the native OS's format for conveying such things.
It currently assumes that if you are not running under MacOS (as
reported in `$^O'), you must be on a Unix box. If you want better, use
File::Spec -- in essence, Mac::FileSpec::Unixish is a cheap hack to get
around using File::Spec.
fb-adb is a tool for interacting with Android systems. It does much of
what adb does, but with better remote shell support and, hopefully,
fewer bugs. Differences between adb and fb-adb are that fb-adb:
* is binary clean (no LF -> CRLF mangling)
* transmits and updates window size
* distinguishes standard output and standard error
* properly muxes streams with independent flow control
* allows for ssh-like pty allocation control
* propagates program exit status instead of always exiting
with status 0
* properly escapes program arguments
* kills remote program
* provides a generic facility to elevate to root without re-escaping
Moo is an extremely light-weight Object Orientation system. It allows
one to concisely define objects and roles with a convenient syntax that
avoids the details of Perl's object system. Moo contains a subset of
Moose and is optimised for rapid startup.
The name Moo is based on the idea that it provides almost -- but not
quite -- two thirds of Moose.
Unlike Mouse this module does not aim at full compatibility with
Moose's surface syntax, preferring instead to provide full
interoperability via metaclass inflation capabilities.
This is a utility that creates common Moose subtypes, coercions and option
specifications useful for dealing with Path::Class objects as Moose attributes.
This module constructs coercions (see Moose::Util::TypeConstraints) from both
'Str' and 'ArrayRef' to both Path::Class::Dir and Path::Class::File objects.
It also adds the Getopt option type ("=s") for both Path::Class::Dir and
Path::Class::File (see MooseX::Getopt).
This is just meant to be a central place for these constructs, so you don't
have to worry about whether they've been created or not, and you're not tempted
to copy them into yet another class (like I was).
A structured type constraint is a standard container Moose type
constraint, such as an ArrayRef or HashRef, which has been enhanced to
allow you to explicitly name all the allowed type constraints inside the
structure. The generalized form is:
TypeConstraint[@TypeParameters or %TypeParameters]
Where 'TypeParameters' is an array reference or hash references of
Moose::Meta::TypeConstraint objects.
This type library enables structured type constraints. It is built on
top of the MooseX::Types library system, so you should review the
documentation for that if you are not familiar with it.
RecDescent incrementally generates top-down recursive-descent text
parsers from simple yacc-like grammar specifications. It provides:
* Regular expressions or literal strings as terminals (tokens)
* Multiple (non-contiguous) productions for any rule
* Repeated, optional and alternate subrules within productions
* Late-bound (run-time dispatched) subrules
* Full access to Perl within actions specified as part of the grammar
* Simple automated error reporting during generation and parsing
* The ability to commit to, uncommit to, or reject particular
productions during a parse
* Incremental extension of the parsing grammar (even during a parse)
* The ability to retrieve the generated parsing code.
Resources are a way to specify information of interest to program or
packages.
Applications use resource files to specify and document the values of
quantities or attributes of interest.
Resources can be loaded from or saved to resource files. Methods are
provided to search, modify and create resources. Packages use resources to
hardwire in their code the default values for their attributes, along with
documentation for the attributes themselves.
Packages inherit resources when subclassed, and the resource names are
updated dynamically to reflect a class hierarchy.
Methods are provided for interactive resource inspection and editing.
This is a specialized POD viewer to extract embedded tests and code
examples from POD. It doesn't do much more than that. pod2test does the
useful work.
After creating a Pod::Tests object, you parse the POD by calling one of
the available parsing methods documented below. You can call parse as many
times as you'd like, all examples and tests found will stack up inside the
object.
Once extracted, the tests can be built into stand-alone testing code using
the build_tests() and build_examples() methods. However, it is recommended
that you first look at the pod2test program before embarking on this.
LRC - Perl interface for longitudinal redundancy check generation
The Longitudinal Redundancy Check (LRC) is a one byte character,
commonly used as a byte-field in data transmission over analog systems.
Most commonly, in STX-ETX bounded strings sent in financial protocols.
Following some previous experience with such protocols, I wrote
an LRC function in perl and later decided to re-write in C
for efficiency. The result is this module String::LRC,
which generates this aforementioned byte.
Commonly used in financial protocols as follows with ETX (ASCII 03)
appended to LRC sum and packets after the STX (ASCII 02), payload,
and ETX chars.
Test::Class provides a simple way of creating classes and
objects to test your code in an xUnit style.
Built using Test::Builder it is designing to work with
other Test::Builder based modules (Test::More,
Test::Differences, Test::Exception, etc.)
Note: This module will make more sense if you are already
familiar with the "standard" mechanisms for testing perl code.
Those unfamiliar with Test::Harness, Test::Simple, Test::More
and friends should go take a look at them now.
Note: This is an early release. Things may change. Be warned.