Software distributions released to the CPAN include a _META.json_ or, for
older distributions, _META.yml_, which describes the distribution, its
contents, and the requirements for building and installing the
distribution. The data structure stored in the _META.json_ file is
described in the CPAN::Meta::Spec manpage.

CPAN::Meta provides a simple class to represent this distribution metadata
(or _distmeta_), along with some helpful methods for interrogating that
data.

The documentation below is only for the methods of the CPAN::Meta object.
For information on the meaning of individual fields, consult the spec.

This module implements a subset of the YAML specification for use in
reading and writing CPAN metadata files like _META.yml_ and _MYMETA.yml_.
It should not be used for any other general YAML parsing or generation
task.

upload things to the CPAN

Debug::Trace instruments subroutines to provide tracing information upon
every call and return.

The 'Digest::JHash' module allows you to use the fast JHash hashing
algorithm developed by Bob Jenkins from within Perl programs. The algorithm
takes as input a message of arbitrary length and produces as output a
32-bit "message digest" of the input in the form of an unsigned long
integer.

Call it a low calorie version of MD5 if you like.

See http://burtleburtle.net/bob/hash/doobs.html for more information.

This modules has the same interface as the much faster 'Digest::MD5'. So
you can easily exchange them, e.g.

BEGIN {
eval {
require Digest::MD5;
import Digest::MD5 'md5_hex'
};
if ($@) { # ups, no Digest::MD5
require Digest::Perl::MD5;
import Digest::Perl::MD5 'md5_hex'
}
}

If the 'Digest::MD5' module is available it is used and if not you take
'Digest::Perl::MD5'.

You can also install the Perl part of Digest::MD5 together with
Digest::Perl::MD5 and use Digest::MD5 as normal, it falls back to
Digest::Perl::MD5 if it cannot load its object files.

For a detailed Documentation see the 'Digest::MD5' module.

Provides an interface to the WHIRLPOOL hash algorithm. This module
subclasses the Digest::base manpage and can be used either directly or
through the the Digest manpage meta-module. Using the latter is
recommended.

Perl's 'chdir()' has the unfortunate problem of being very, very, very
global. If any part of your program calls 'chdir()' or if any library you
use calls 'chdir()', it changes the current working directory for the
*whole* program.

This sucks.

File::chdir gives you an alternative, '$CWD' and '@CWD'. These two
variables combine all the power of 'chdir()', the File::Spec manpage and
the Cwd manpage.

File::ShareDir::Install allows you to install read-only data files from a
distribution. It is a companion module to the File::ShareDir manpage, which
allows you to locate these files after installation.

It is a port the Module::Install::Share manpage to the ExtUtils::MakeMaker
manpage with the improvement of only installing the files you want; '.svn'
and other source-control junk will be ignored.

Locates the full path to the script bin directory to allow the use of paths
relative to the bin directory.

This allows a user to setup a directory tree for some software with
directories /bin and /lib and then the above example will allow
the use of modules in the lib directory without knowing where the software
tree is installed.

If perl is invoked using the *-e* option or the perl script is read from
'STDIN' then FindBin sets both 'Bin()' and 'RealBin()' return values to the
current directory.

This module allows you to do almost anything to a TrueType/OpenType Font
including modify and inspect nearly all tables.

*** Although documentation in this file provides some overview, it is
mainly intended for API documentation. See the
HTML::FormHandler::Manual::Intro manpage for a more detailed introduction.

HTML::FormHandler maintains a clean separation between form construction
and form rendering. It allows you to define your forms and fields in a
number of flexible ways. Although it provides renderers for HTML, you can
define custom renderers for any kind of presentation.

HTML::FormHandler allows you to define form fields and validators. It can
be used for both database and non-database forms, and will automatically
update or create rows in a database. It can be used to process structured
data that doesn't come from an HTML form.

One of its goals is to keep the controller/application program interface as
simple as possible, and to minimize the duplication of code. In most cases,
interfacing your controller to your form is only a few lines of code.

With FormHandler you'll never spend hours trying to figure out how to make
a simple HTML change that would take one minute by hand. Because you CAN do
it by hand. Or you can automate HTML generation as much as you want, with
template widgets or pure Perl rendering classes, and stay completely in
control of what, where, and how much is done automatically. You can define
custom renderers and display your rendered forms however you want.

You can split the pieces of your forms up into logical parts and compose
complete forms from FormHandler classes, roles, fields, collections of
validations, transformations and Moose type constraints. You can write
custom methods to process forms, add any attribute you like, use Moose
method modifiers. FormHandler forms are Perl classes, so there's a lot of
flexibility in what you can do.

HTML::FormHandler provides rendering through roles which are applied to
form and field classes (although there's no reason you couldn't write a
renderer as an external object either). There are currently two flavors:
all-in-one solutions like the HTML::FormHandler::Render::Simple manpage and
the HTML::FormHandler::Render::Table manpage that contain methods for
rendering field widget classes, and the the HTML::FormHandler::Widget
manpage roles, which are more atomic roles which are automatically applied
to fields and form if a 'render' method does not already exist. See the
HTML::FormHandler::Manual::Rendering manpage for more details. (And you can
easily use hand-build forms - FormHandler doesn't care.)

The typical application for FormHandler would be in a Catalyst,
DBIx::Class, Template Toolkit web application, but use is not limited to
that. FormHandler can be used in any Perl application.

More Formhandler documentation and a tutorial can be found in the manual at
the HTML::FormHandler::Manual manpage.

This module provides three utility subroutines that make it easier to
develop interactive applications...

* 'is_interactive()'

This subroutine returns true if '*ARGV' and the currently selected
filehandle (usually '*STDOUT') are connected to the terminal. The test is
considerably more sophisticated than:

-t *ARGV && -t *STDOUT

as it takes into account the magic behaviour of '*ARGV'.

You can also pass 'is_interactive' a writable filehandle, in which case
it requires that filehandle be connected to a terminal (instead of the
currently selected). The usual suspect here is '*STDERR':

if ( is_interactive(*STDERR) ) {
carp $warning;
}

* 'interactive()'

This subroutine returns '*STDOUT' if 'is_interactive' is true. If
'is_interactive()' is false, 'interactive' returns a filehandle that does
not print.

This makes it easy to create applications that print out only when the
application is interactive:

print {interactive} "Please enter a value: ";
my $value = <>;

You can also pass 'interactive' a writable filehandle, in which case it
writes to that filehandle if it is connected to a terminal (instead of
writinbg to '*STDOUT'). Once again, the usual suspect is '*STDERR':

print {interactive(*STDERR)} $warning;

* 'busy {...}'

This subroutine takes a block as its single argument and executes that
block. Whilst the block is executed, '*ARGV' is temporarily replaced by a
closed filehandle. That is, no input from '*ARGV' is possible in a 'busy'
block. Furthermore, any attempts to send input into the 'busy' block
through '*ARGV' is intercepted and a warning message is printed to
'*STDERR'. The 'busy' call returns a filehandle that contains the
intercepted input.

A 'busy' block is therefore useful to prevent attempts at input when the
program is busy at some non-interactive task.

The 'Lingua::EN::Sentence' module contains the function get_sentences,
which splits text into its constituent sentences, based on a regular
expression and a list of abbreviations (built in and given).

Certain well know exceptions, such as abreviations, may cause incorrect
segmentations. But some of them are already integrated into this code and
are being taken care of. Still, if you see that there are words causing the
get_sentences() to fail, you can add those to the module, so it notices
them.