DBIx::Transaction is a wrapper around DBI that helps you manage your
database transactions.

This module attempts to generate a stack dump from a core file by
locating the best available debugger (if any) and running it with the
appropriate arguments and command script.

Devel::StackTrace::AsHTML adds 'as_html' method to the Devel::StackTrace
manpage which displays the stack trace in beautiful HTML, with code snippet
context and function parameters. If you call it on an instance of the
Devel::StackTrace::WithLexicals manpage, you even get to see the lexical
variables of each stack frame.

Devel::Symdump is a Perl module that provides a convenient way to
inspect Perl's symbol table and the class hierarchy within a running
program.

HMAC is used for message integrity checks between two parties that share a
secret key, and works in combination with some other Digest algorithm,
usually MD5 or SHA-1. The HMAC mechanism is described in RFC 2104.

HMAC follow the common 'Digest::' interface, but the constructor takes the
secret key and the name of some other simple 'Digest::' as argument.

Perl interface to the RSA Data Security Inc. MD4 Message-Digest
Algorithm.

The Digest::SHA1 module allows the use of the NIST SHA-1 message digest
algorithm from within Perl programs. The algorithm takes a message of
arbitrary length as input and produces a 160-bit fingerprint or message
digest of the input as output.

One shortcoming of the CPAN clients that currently exist is that they have
no way of specifying conflicting downstream dependencies of modules. This
module attempts to work around this issue by allowing you to specify
conflicting versions of modules separately, and deal with them after the
module is done installing.

For instance, say you have a module 'Foo', and some other module 'Bar' uses
'Foo'. If 'Foo' were to change its API in a non-backwards-compatible way,
this would cause 'Bar' to break until it is updated to use the new API.
'Foo' can't just depend on the fixed version of 'Bar', because this will
cause a circular dependency (because 'Bar' is already depending on 'Foo'),
and this doesn't express intent properly anyway - 'Foo' doesn't use 'Bar'
at all. The ideal solution would be for there to be a way to specify
conflicting versions of modules in a way that would let CPAN clients update
conflicting modules automatically after an existing module is upgraded, but
until that happens, this module will allow users to do this manually.

This module accepts a hash of options passed to its 'use' statement, with
these keys being valid:

* -conflicts

A hashref of conflict specifications, where keys are module names, and
values are the last broken version - any version greater than the
specified version should work.

* -also

Additional modules to get conflicts from (potentially recursively). This
should generally be a list of modules which use Dist::CheckConflicts,
which correspond to the dists that your dist depends on. (In an ideal
world, this would be intuited directly from your dependency list, but the
dependency list isn't available outside of build time).

* -dist

The name of the distribution, to make the error message from
check_conflicts more user-friendly.

The methods listed below are exported by this module into the module that
uses it, so you should call these methods on your module, not
Dist::CheckConflicts.

As an example, this command line can be used to update your modules, after
installing the 'Foo' dist (assuming that 'Foo::Conflicts' is the module in
the 'Foo' dist which uses Dist::CheckConflicts):

perl -MFoo::Conflicts -e'print "$_\n"
for map { $_->{package} } Foo::Conflicts->calculate_conflicts' | cpanm

In many applications it's wise to let Perl use Unicode for the strings it
processes. Most of the interfaces Perl has to the outside world are still
byte based. Programs therefore needs to decode byte strings that enter the
program from the outside and encode them again on the way out.

The POSIX locale system is used to specify both the language conventions
requested by the user and the preferred character set to consume and
output. The 'Encode::Locale' module looks up the charset and encoding
(called a CODESET in the locale jargon) and arrange for the Encode
module to know this encoding under the name "locale". It means
bytes obtained from the environment can be converted to Unicode strings by
calling 'Encode::encode(locale => $bytes)' and converted back again with
'Encode::decode(locale => $string)'.

Where file systems interfaces pass file names in and out of the program we
also need care. The trend is for operating systems to use a fixed file
encoding that doesn't actually depend on the locale; and this module
determines the most appropriate encoding for file names. The Encode
module will know this encoding under the name "locale_fs". For
traditional Unix systems this will be an alias to the same encoding as
"locale".

For programs running in a terminal window (called a "Console" on some
systems) the "locale" encoding is usually a good choice for what to expect
as input and output. Some systems allow us to query the encoding set for
the terminal and 'Encode::Locale' will do that if available and make these
encodings known under the 'Encode' aliases "console_in" and "console_out".
For systems where we can't determine the terminal encoding these will be
aliased as the same encoding as "locale". The advice is to use "console_in"
for input known to come from the terminal and "console_out" for output
known to go from the terminal.

In addition to arranging for various Encode aliases the following functions
and variables are provided:

* decode_argv( )

* decode_argv( Encode::FB_CROAK )

This will decode the command line arguments to perl (the '@ARGV' array)
in-place.

The function will by default replace characters that can't be decoded by
"\x{FFFD}", the Unicode replacement character.

Any argument provided is passed as CHECK to underlying Encode::decode()
call. Pass the value 'Encode::FB_CROAK' to have the decoding croak if not
all the command line arguments can be decoded. See the Encode/"Handling
Malformed Data" manpage for details on other options for CHECK.

* env( $uni_key )

* env( $uni_key => $uni_value )

Interface to get/set environment variables. Returns the current value as
a Unicode string. The $uni_key and $uni_value arguments are expected to
be Unicode strings as well. Passing 'undef' as $uni_value deletes the
environment variable named $uni_key.

The returned value will have the characters that can't be decoded
replaced by "\x{FFFD}", the Unicode replacement character.

There is no interface to request alternative CHECK behavior as for
decode_argv(). If you need that you need to call encode/decode yourself.
For example:

my $key = Encode::encode(locale => $uni_key, Encode::FB_CROAK);
my $uni_value = Encode::decode(locale => $ENV{$key}, Encode::FB_CROAK);

* reinit( )

* reinit( $encoding )

Reinitialize the encodings from the locale. You want to call this
function if you changed anything in the environment that might influence
the locale.

This function will croak if the determined encoding isn't recognized by
the Encode module.

With argument force $ENCODING_... variables to set to the given value.

* $ENCODING_LOCALE

The encoding name determined to be suitable for the current locale. The
Encode manpage knows this encoding as "locale".

* $ENCODING_LOCALE_FS

The encoding name determined to be suiteable for file system interfaces
involving file names. The Encode manpage knows this encoding as
"locale_fs".

* $ENCODING_CONSOLE_IN

* $ENCODING_CONSOLE_OUT

The encodings to be used for reading and writing output to the a console.
The Encode manpage knows these encodings as "console_in" and
"console_out".

The 'Error' package provides two interfaces. Firstly 'Error' provides a
procedural interface to exception handling. Secondly 'Error' is a base
class for errors/exceptions that can either be thrown, for subsequent
catch, or can simply be recorded.

Errors in the class 'Error' should not be thrown directly, but the user
should throw errors from a sub-class of 'Error'.

ALERT: Marc Lehmann may have taken over the future of event loops in Perl.
Check out his libev library and EV Perl module. 25 Aug 2009

The Event module provide a central facility to watch for various types of
events and invoke a callback when these events occur. The idea is to delay
the handling of events so that they may be dispatched in priority order
when it is safe for callbacks to execute.

Events (in the ordinary sense of the word) are detected by *watchers*,
which reify them as *events* (in the special Event module sense). For
clarity, the former type of events may be called "source events", and the
latter "target events". Source events, such as signals arriving, happen
whether or not they are being watched. If a source event occurs which a
watcher is actively watching then the watcher generates a corresponding
target event. Target events are only created by watchers. If several
watchers are interested in the same source event then each will generate
their own target event. Hence, any particular source event may result in
zero, one, two, or any number of target events: the same as the number of
watchers which were actively watching for it.

Target events are queued to be processed in priority order (priority being
determined by the creating watcher) and in FIFO order among events of the
same priority. Queued ("pending") events can, in some cases, be cancelled
before being processed. A queued event is processed by being passed to the
callback function (or method on a particular object or class) which was
specified to the watcher.

A watcher, once created, operates autonomously without the Event user
having to retain any reference to it. However, keeping a reference makes it
possible to modify most of the watcher's characteristics. A watcher can be
switched between active and inactive states. When inactive, it does not
generate target events.

Some types of source event are not reified as target events immediately.
Signals received, for example, are counted initially. The counted signals
are reified at certain execution points. Hence, signal events may be
processed out of order, and if handled carelessly, on the wrong side of a
state change in event handling. A useful way to view this is that
occurrence of the source event is not actually the arrival of the signal
but is triggered by the counting of the signal.

Reification can be forced when necessary. The schedule on which some other
events are created is non-obvious. This is especially the case with
watchers that watch for a condition rather than an event. In some cases,
target events are generated on a schedule that depends on the operation of
the event loop.

This module can build the C portions of Perl modules by invoking the
appropriate compilers and linkers in a cross-platform manner. It was
motivated by the Module::Build project, but may be useful for other
purposes as well. However, it is not intended as a general cross-platform
interface to all your C building needs. That would have been a much more
ambitious goal!

Often Perl modules are written to wrap functionallity found in existing C
headers, libraries, or to use OS-specific features. It is useful in the
Build.PL or Makefile.PL file to check for the existance of these
requirements before attempting to actually build the module.

This module tries to make it easy to build Perl extensions that use
functions and typemaps provided by other perl extensions. This means that a
perl extension is treated like a shared library that provides also a C and
an XS interface besides the perl one.

This works as long as the base extension is loaded with the RTLD_GLOBAL
flag (usually done with a

sub dl_load_flags {0x01}

in the main .pm file) if you need to use functions defined in the module.

The basic scheme of operation is to collect information about a module in
the instance, and then store that data in the Perl library where it may be
retrieved later. The object can also reformat this information into the
data structures required by ExtUtils::MakeMaker's WriteMakefile function.

When creating a new Depends object, you give it a name, which is the name
of the module you are building. You can also specify the names of modules
on which this module depends. These dependencies will be loaded
automatically, and their typemaps, header files, etc merged with your new
object's stuff. When you store the data for your object, the list of
dependencies are stored with it, so that another module depending on your
needn't know on exactly which modules yours depends.

For example:

Gtk2 depends on Glib

Gnome2::Canvas depends on Gtk2

ExtUtils::Depends->new ('Gnome2::Canvas', 'Gtk2');
this command automatically brings in all the stuff needed
for Glib, since Gtk2 depends on it.

This module tries to figure out how to link C programs with Fortran
subroutines on your system. Basically one must add a list of Fortran
runtime libraries. The problem is their location and name varies with
each OS/compiler combination!

The pkg-config program retrieves information about installed libraries,
usually for the purposes of compiling against and linking to them.

ExtUtils::PkgConfig is a very simplistic interface to this utility,
intended for use in the Makefile.PL of perl extensions which bind libraries
that pkg-config knows. It is really just boilerplate code that you would've
written yourself.

File::Basename::Object is an object-oriented wrapper around
File::Basename. The goal is to allow pathnames to be presented and
manipulated easily.

This module exports a single function called parse_dir(), which can be used
to parse directory listings.

The first parameter to parse_dir() is the directory listing to parse. It
can be a scalar, a reference to an array of directory lines or a glob
representing a filehandle to read the directory listing from.

The second parameter is the time zone to use when parsing time stamps in
the listing. If this value is undefined, then the local time zone is
assumed.

The third parameter is the type of listing to assume. Currently supported
formats are 'unix', 'apache' and 'dosftp'. The default value 'unix'.
Ideally, the listing type should be determined automatically.

The fourth parameter specifies how unparseable lines should be treated.
Values can be 'ignore', 'warn' or a code reference. Warn means that the
perl warn() function will be called. If a code reference is passed, then
this routine will be called and the return value from it will be
incorporated in the listing. The default is 'ignore'.

Only the first parameter is mandatory.

The return value from parse_dir() is a list of directory entries. In a
scalar context the return value is a reference to the list. The directory
entries are represented by an array consisting of [ $filename, $filetype,
$filesize, $filetime, $filemode ]. The $filetype value is one of the
letters 'f', 'd', 'l' or '?'. The $filetime value is the seconds since Jan
1, 1970. The $filemode is a bitmask like the mode returned by stat().

The goal here is simply to provide recursive versions of mkdir() and
rmdir() with as little code and overhead as possible.
This module is in no way meant to derogate File::Path and is in no way an
endorsement to go out and replace all use of File::Path with
File::Path::Tiny.