Data::Printer is meant to do one thing and one thing only: display Perl
variables and objects on screen, properly formatted (to be inspected by a
human).
Here's what Data::Printer has to offer to Perl developers, out of the box:
- Very sane defaults (I hope!)
- Highly customizable (in case you disagree with me :)
- Colored output by default
- Human-friendly output, with array index and custom separators
- Full object dumps including methods, inheritance and internals
- Exposes extra information such as tainted data and weak references
- Ability to easily create filters for objects and regular structures
- Ability to load settings from a .dataprinter file so you don't have to write
anything other than "use DDP;" in your code!
DateTime::Format::Oracle may be used to convert Oracle date and timestamp values
into DateTime objects. It also can take a DateTime object and produce a date
string matching the NLS_DATE_FORMAT.
Oracle has flexible date formatting via its NLS_DATE_FORMAT session variable.
Date values will be returned from Oracle according to the current value of that
variable. Date values going into Oracle must also match the current setting of
NLS_DATE_FORMAT.
Timestamp values will match either the NLS_TIMESTAMP_FORMAT or
NLS_TIMESTAMP_TZ_FORMAT session variables.
This module keeps track of these Oracle session variable values by examining
environment variables of the same name. Each time one of Oracle's formatting
session variables is updated, the %ENV hash must also be updated.
Devel::NYTProf is a powerful feature-rich perl source code profiler.
* Performs per-line statement profiling for fine detail
* Performs per-subroutine statement profiling for overview
* Performs per-block statement profiling (the first profiler to do so)
* Accounts correctly for time spent after calls return
* Performs inclusive and exclusive timing of subroutines
* Subroutine times are per calling location (a powerful feature)
* Can profile compile-time activity, just run-time, or just END time
* Uses novel techniques for efficient profiling
* Sub-microsecond (100ns) resolution on systems with clock_gettime()
* Very fast - the fastest statement and subroutine profilers for perl
* Handles applications that fork, with no performance cost
* Immune from noise caused by profiling overheads and I/O
* Program being profiled can stop/start the profiler
* Generates richly annotated and cross-linked html reports
* Trivial to use with mod_perl - add one line to httpd.conf
* Includes an extensive test suite
* Tested on very large codebases
File::ConfigDir is a helper for installing, reading and finding configuration
file locations. It's intended to work in every supported Perl5 environment and
will always try to Do The Right Thing(TM).
File::ConfigDir is a module to help out when perl modules (especially
applications) need to read and store configuration files from more than one
location. Writing user configuration is easy thanks to File::HomeDir, but what
when the system administrator needs to place some global configuration or there
will be system related configuration (in /etc on UNIX(TM) or $ENV{windir} on
Windows(TM)) and some network configuration in nfs mapped /etc/p5-app or
$ENV{ALLUSERSPROFILE} . "\\Application Data\\p5-app", respectively.
File::ConfigDir has no "do what I mean" mode - it's entirely up to the user to
pick the right directory for each particular application.
MooseX::NonMoose allows for easily subclassing non-Moose classes with
Moose, taking care of the annoying details connected with doing this,
such as setting up proper inheritance from Moose::Object and installing
(and inlining, at make_immutable time) a constructor that makes sure
things like BUILD methods are called. It tries to be as non-intrusive
as possible - when this module is used, inheriting from non-Moose classes
and inheriting from Moose classes should work identically, aside from the
few caveats mentioned below. One of the goals of this module is that
including it in a Moose::Exporter-based package used across an entire
application should be possible, without interfering with classes that
only inherit from Moose modules, or even classes that don't inherit from
anything at all.
While ANSI color escape codes are fairly simple, it can be hard to
remember the codes for all of the attributes and the code resulting
from hard-coding them into your script is definitely difficult to
read. This module is designed to fix those problems, as well as
provide a convenient interface to do a few things for you
automatically (like resetting attributes after the text you print out
so that you don't accidentally leave attributes set).
Despite its name, this module can also handle non-color ANSI text
attributes (bold, underline, reverse video, and blink). It uses either
of two interfaces, one of which uses "constants" for each different
attribute and the other of which uses two subs which take strings of
attributes as arguments.
From the Phing homepage:
PHing Is Not GNU make; it's a PHP project build system or build tool based on
Apache Ant. You can do anything with it that you could do with a traditiona
build system like GNU make, and its use of simple XML build files and
extensible PHP "task" classes make it an easy-to-use and highly flexible build
framework.
Features include running PHPUnit and SimpleTest unit tests (including test
result and coverage reports), file transformations (e.g. token replacement,
XSLT transformation, Smarty template transformations), file system operations,
interactive build support, SQL execution, CVS/SVN/GIT operations, tools for
creating PEAR packages, documentation generation (DocBlox, PhpDocumentor) and
much, much more.
This is PIRE, Perl Incompatible Regular Expressions library.
This library is aimed at checking a huge amount of text against
relatively many regular expressions. Roughly speaking, it can just
check whether given text maches the certain regexp, but can do it
really fast (more than 400 MB/s on our hardware is common). Even
more, multiple regexps can be combined together, giving capability
to check the text against apx.10 regexps in a single pass (and
mantaining the same speed).
Since Pire examines each character only once, without any lookaheads
or rollbacks, spending about five machine instructions per each
character, it can be used even in realtime tasks.
On the other hand, Pire has very limited functionality (compared
to other regexp libraries). Pire does not have any Perlish conditional
regexps, lookaheads & backtrackings, greedy/nongreedy matches;
neither has it any capturing facilities.
This module implements a very fast JSON encoder/decoder for Python.
JSON stands for JavaScript Object Notation and is a text based lightweight
data exchange format which is easy for humans to read/write and for machines
to parse/generate. JSON is completely language independent and has multiple
implementations in most of the programming languages, making it ideal for
data exchange and storage.
The module is written in C and it is up to 250 times faster when compared to
the other python JSON implementations which are written directly in python.
This speed gain varies with the complexity of the data and the operation and
is the range of 10-200 times for encoding operations and in the range of
100-250 times for decoding operations.
Envisage is a Python-based framework for building extensible applications, that
is, applications whose functionality can be extended by adding "plug-ins".
Envisage provides a standard mechanism for features to be added to an
application, whether by the original developer or by someone else. In fact,
when you build an application using Envisage, the entire application consists
primarily of plug-ins. In this respect, it is similar to the Eclipse and
Netbeans frameworks for Java applications.
Each plug-in is able to:
* Advertise where and how it can be extended (its "extension points").
* Contribute extensions to the extension points offered by other plug-ins.
* Create and share the objects that perform the real work of the application
("services").
The Envisage project provides the basic machinery of the Envisage framework.