Involved Projects and Packages
Module for checking validity of MARC records. 99% of the users will want to do something like is shown in the synopsis. The other intrepid 1% will overload the MARC::Lint module's methods and provide their own special field-level checking.
What this means is that if you have certain requirements, such as making sure that all 952 tags have a certain call number in them, you can write a function that checks for that, and still get all the benefits of the MARC::Lint framework.
Module for handling MARC records as objects.
The file-handling stuff is in MARC::File::*.
MARC::XML is a subclass of MARC.pm which provides methods for round-trip conversions between MARC and XML.
MARC::XML requires that you have the CPAN modules MARC.pm and XML::Parser installed in your Perl library.
Version 1.04 of MARC.pm and 2.27 of XML::Parser (or later) are required.
As a subclass of MARC.pm a MARC::XML object will by default have the full functionality of a MARC.pm object.
See the MARC.pm documentation for details.
This module is a generalization of the functionality provided by
Apache::StatINC and Apache::Reload. It's designed to make it easy to do simple
iterative development when working in a persistent environment.
It does not require mod_perl.
Jesse Vincent ,
I often get email from someone reporting a bug in a module I've written. I
email back, asking what version of the module it is, what version of Perl on
what OS, and sometimes what version of some relevent third library (like
XML::Parser). They reply, saying "Perl 5". I say "I need the exact version, as
reported by perl -v". They tell me. And I say "I, uh, also asked about the
version of my module and XML::Parser [or whatever]". They say "Oh yeah. It's
2.27". "Is that my module or XML::Parser?" "XML::Parser." "OK, and what about
my module's version?" "Ohyeah. That's 3.11." By this time, days have passed,
and what should have been a simple operation -- reporting the version of Perl
and relevent modules, has been needlessly complicated.
This module is for simplifying that task. If you add "use
Module::Versions::Report;" to a program (especially handy if your program is
one that demonstrates a bug in some module), then when the program has finished
running, you well get a report detailing the all modules in memory, and noting
the version of each (for modules that defined a $VERSION, at least).
Sean M. Burke,
Moose is wonderful. Use Moose instead of Mouse.
Unfortunately, Moose has a compile-time penalty. Though significant progress
has been made over the years, the compile time penalty is a non-starter for
some very specific applications. If you are writing a command-line application
or CGI script where startup time is essential, you may not be able to use
Moose. We recommend that you instead use HTTP::Engine and FastCGI for the
latter, if possible.
Mouse aims to alleviate this by providing a subset of Moose's functionality,
We're also going as light on dependencies as possible. Mouse currently has no
dependencies except for testing modules.
SLP is the Service Location Protocol, a protocol fpor discovering the location and attributes of servers for some required service. There is a standard C API for SLP, and this module is a wrapper around that API. The API is described in RFC2614, see which for detailed API usage. All RFC2614 functions are implmeneted except for SLPParseSrvURL() and SLPFree().
Net::Whois::Raw queries WHOIS servers about domains. The module supports
recursive WHOIS queries. Also queries via HTTP is supported for some TLDs.
Setting the variables $OMIT_MSG and $CHECK_FAIL will match the results against
a set of known patterns. The first flag will try to omit the copyright
message/disclaimer, the second will attempt to determine if the search failed
and return undef in such a case.
A big part of good API design is that we should be able to be flexible in the
ways that we take parameters.
Params::Coerce attempts to encourage this, by making it easier to take a
variety of different arguments, while adding negligable additional complexity
to your code.
Params-Util module for perl
Params::Util provides a basic set of importable functions that makes checking parameters a hell of a lot easier While they can be (and are) used in other contexts, the main point behind this module is that the functions both Do What You Mean, and Do The Right Thing, so they are most useful when you are getting params passed into your code from someone and/or somewhere else and you can't really trust the quality.
Thus, Params::Util is of most use at the edges of your API, where params and data are coming in from outside your code. The functions provided by Params::Util check in the most strictly correct manner known, are documented as thoroughly as possible so their exact behaviour is clear, and heavily tested so make sure they are not fooled by weird data and Really Bad Things.
To use, simply load the module providing the functions you want to use as arguments (as shown in the SYNOPSIS).
To aid in maintainability, Params::Util will never export by default.
You must explicitly name the functions you want to export, or use the :ALL param to just have it export everything (although this is not recommended if you have any _FOO functions yourself with which future additions to Params::Util may clash)
This is a sub-module to PDF::Reuse. It creates barcode "images" to be used in PDF documents. It uses GD::Barcode and its sub-modules: GD::Barcode::Code39, COOP2of5, EAN13 and so on, to calculate the barcode pattern. For Code128 it uses Barcode::Code128.
Normally the barcodes are displayed on a white background and with the characters under the bars. You can rotate the "image", make it smaller or bigger, prolong the bars and change the background. (But then, don't forget to test that your barcode scanner still understands it.)
If you don't change the size of the "image", the bars are approximately 24 pixels high (the guard bars a few pixels longer) and the box/background is 38 pixels high and something like 20 pixels wider than the barcodes. The text under the bars are 10 pixels high.
The barcodes are generated using a Type3 font by default. Ghostscript and xpdf don'thave support for Type3 fonts. If you want to target engines that don't handle Type3 fonts properly, see the "mode" parameter.
This is a lightweight module which provides 'Junction' operators, the most
commonly used being any and all.
Inspired by the Perl6 design docs,
Provides a limited subset of the functionality of Quantum::Superpositions, see
"SEE ALSO" for comment.
When using Pod::Coverage in combination with Moose, it will report any method
imported from a Role. This is especially bad when used in combination with
Test::Pod::Coverage, since it takes away its ease of use.
Robert 'phaylon' Sedlacek
This package is based on the package 'perl-Pod-Escapes' from project 'openSUSE:Factory'.
This module provides things that are useful in decoding Pod E<...>
sequences. Presumably, it should be used only by Pod parsers and/or
*Pod::Parser* is a base class for creating POD filters and translators. It
handles most of the effort involved with parsing the POD sections from an
input stream, leaving subclasses free to be concerned only with performing
the actual translation of text.
*Pod::Parser* parses PODs, and makes method calls to handle the various
components of the POD. Subclasses of *Pod::Parser* override these methods
to translate the POD into whatever output format they desire.
POE is a framework for cooperative, event driven multitasking and networking in
Perl. Other languages have similar frameworks. Python has Twisted. TCL has "the
POE originally was developed as the core of a persistent object server and
runtime environment. It has since evolved into something much more generic and
POE provides a unified interface for several other event loops, including
select(), IO::Poll, Glib, Gtk, Tk, Wx, Gtk2, and so on. Check the CPAN for the
full list of POE::Loop modules.
POE is designed in layers, each building atop the lower level ones. Programs
are free to use POE at any level of abstraction, and different levels can be
mixed and matched seamlessly within a single program.
POE's bundled abstraction layers are the tip of a growing iceberg. Sprocket,
POE::Stage, and other CPAN distributions build upon this work. You're
encouraged to look around.
No matter how high you go, though, it all boils down to calls to POE::Kernel.
So your down-to-earth code can easily cooperate with stratospheric systems.
POE::Test::Loops contains one function, generate(), which will generate all
the loop tests for one or more POE::Loop subclasses.
The "SYNOPSIS" example is a version of poe-gen-tests, which is a
stand-alone utility to generate the actual tests. poe-gen-tests also
documents the POE::Test::Loops system in more detail.
Project-Builder is a tool that helps you building packages for your application
(managed with tar file, or a configuration management system such as CVS or
Subversion). It is able to generate build package skeleton for your project,
and with simple configuration files to generate for up to 20 different tuples
of distributions (name, version, architecture), including Fedora, Mandriva,
OpenSuSE, Debian, Ubuntu, Gentoo, Slackware.
RPMQ allows to query binary RPM packages with simple API calls.
RRD::Simple provides a simple interface to RRDTool's RRDs module. This module
does not currently offer a fetch method that is available in the RRDs module.
It does however create RRD files with a sensible set of default RRA (Round
Robin Archive) definitions, and can dynamically add new data source names to an
existing RRD file.
This module is ideal for quick and simple storage of data within an RRD file if
you do not need to, nor want to, bother defining custom RRA definitions.
List::Util contains a selection of subroutines that people have expressed would
be nice to have in the perl core, but the usage would not really be high enough
to warrant the use of a keyword, and the size so small such that being
individual extensions would be wasteful.
This modules provides an OS independent interface to 'at', the Unix command that allows you to execute commands at a specified time.
This module helps you write scripts that conform to best common practices,
quickly. Just include the above as a template, and your script will accept all
of the options that are included in the manual page, as well as summarising
them when you use the -h option.
(Unfortunately, it is not possible to have a `use' dependency automatically add
structure to your POD yet, so you have to include the above manually. If you
want your help message and Perldoc to be meaningful, that is.)
Shortcuts are provided to help you abort or die with various error conditions;
all of which print the name of the program running (taken from $0 if not
passed). The motive for this is that "small" scripts tend to just get written
and forgotten; so, when you have a larger system that is built out of lots of
these pieces it is sometimes guesswork figuring out which script a printed
message comes from!
Sam Vilain, firstname.lastname@example.org
SMS::Send is intended to provide a driver-based single API for sending SMS and MMS messages. The intent is to provide a single API against which to write the code to send an SMS message.
At the same time, the intent is to remove the limits of some of the previous attempts at this sort of API, like "must be free internet-based SMS services".
SMS::Send drivers are installed seperately, and might use the web, email or physical SMS hardware. It could be a free or paid. The details shouldn't matter.
You should not have to care how it is actually sent, only that it has been sent (although some drivers may not be able to provide certainty).