Ports 搜索

The Devel::Required module only serves a purpose in the development environment of an author of a CPAN module (or more precisely: a user of the ExtUtils::MakeMaker module). It makes sure that any changes to the required modules specified in the Makefile.PL are automatically reflected in the appropriate text file and in the appropriate source files (either explicitly or implicitly specified). It takes the information given with the PREREQ_PM parameter and by default writes this to the README file, as well as to the POD of the file specified with the VERSION_FROM parameter. Both these defaults can be overridden with the "text" and "pod" parameters in the use Devel::Required specification.

This module provides code coverage metrics for Perl. If you can't guess by the version number this is an alpha release. Code coverage data are collected using a pluggable runops function which counts how many times each op is executed. These data are then mapped back to reality using the B compiler modules. There is also a statement profiling facility which needs a better backend to be really useful. The cover program can be used to generate coverage reports. Statement, branch, condition, subroutine, pod and time coverage information is reported. Statement coverage data should be reasonable, although there may be some statements which are not reported. Branch and condition coverage data should be mostly accurate too, although not always what one might initially expect. Subroutine coverage should be as accurate as statement coverage. Pod coverage comes from Pod::Coverage. Coverage data for path coverage are not yet collected.

This defines the policy for file I/O with modules such as File::Slurp::WithinPolicy. The purpose is to allow systems administrators to define locations and restrictions for applications' file I/O and give app developers a policy to follow. Note that the module doesn't ENFORCE the policy - application developers can choose to ignore it (and systems administrators can choose not to install their applications if they do!). You may control which policy gets applied by creating a File::Policy::Config module with an IMPLEMENTATION constant. You may write your own policy as a module within the File::Policy:: namespace. By default (if no File::Policy::Config is present), the File::Policy::Default policy gets applied which doesn't impose any restrictions and provides reasonable default locations for temporary and log files.

This module is a wrapper around Getopt::Long that extends the value of the original Getopt::Long module to: 1) add a simple graphical user interface option screen if no arguments are passed to the program. 2) provide an auto-help mechanism such that -h and --help are handled automatically. It's designed to make the creation of graphical shells trivial without the programmer having to think about it much as well as providing automatic good-looking usage output without the programmer needing to write usage() functions. This also can turn normal command line programs into web CGI scripts as well (automatically). If the Getopt::GUI::Long program is installed as a CGI script then it will automatically prompt the user for the same variables.

Hash::FieldHash provides the field hash mechanism which supports the inside-out technique. You may know Hash::Util::FieldHash. It's a very useful module, but too complex to understand all the functions and only available in 5.10. H::U::F::Compat is available for pre-5.10, but it seems too slow to use. This is an alternative to H::U::F with following features: Simpler interface - Hash::FieldHash provides a few functions: fieldhash() and fieldhashes(). That's enough. Higher performance - Hash::FieldHash is faster than Hash::Util::FieldHash, because its internals use simpler structures. Relic support - Although Hash::FieldHash uses a new feature introduced in Perl 5.10, the uvar magic for hashes described in "GUTS" in Hash::Util::Fieldhash, it supports Perl 5.8 using the traditional tie-hash layer.

IPC::Open3::Simple aims at making it very easy to start a shell command, eventually feed its stdin with some data, then retrieve its stdout and stderr separately. When you want to run a shell command and parse its stdout/stderr or feed its stdin, you often end up using IPC::Run, IPC::Cmd or IPC::Open3 with your own parsing code, and end up writing more code than you intended. IPC::Open3::Simple is about removing this overhead and making IPC::Open3 easier to use. IPC::Open3::Simple calls IPC::Open3 and redirects stdin, stdout and stderr to some function references passed in argument to the constructor. It does a select on the input/output filehandles returned by IPC::Open3 and dispatches their content to and from those functions.

IO::Event provides an object-based callback system for handling nonblocking IO. The design goal is to provide a system that just does the right thing without the user needing to think about it much. All APIs are kept as simple as possible yet at the same time, all functionality is accesible if needed. Simple things are easy. Hard things are possible. Most of the time file handling syntax will work fine: <$filehandle> and print $filehandle 'stuff'. IO::Event provides automatic buffering of output (with a callback to throttle). It provides automatic line-at-a-time input. After initial setup, call IO::Event::loop(). IO::Event was originally written to use Event. IO::Event still defaults to using Event but it can now use AnyEvent or its own event loop.

Inline::TT provides Inline access to version 2.0 and higher of the Template Toolkit. This allows you to house your templates inside the source code file, while retaining the ability to cache compiled templates on the disk (via Inline's caching mechanism). The names of the blocks in the template are exported as functions. Call these with a reference to a hash of values, which will be used for interpolation in the templates. This hash reference is the same as the second argument to the process method of any Template object. The output from template toolkit will be returned to you as a single string. Note that leading and trailing spaces are trimmed, further the template toolkit options PRE_CHOMP and POST_CHOMP are set. Currently, there is no way to change these behaviors.

POE::Session::MultiDispatch is a drop in replacement for POE::Session that adds callback dispatch functionality to POE sessions. Each event may have multiple handlers associated with it. Fine control over the order of execution is available using helper methods that extend the interface of a POE::Session. POE::Session::MultiDispatch uses POE::Session as a base class. When multiple callbacks are registered for an event, only the last callback survives, all the others are clobbered. POE::Session::MultiDispatch is much nicer to your registered callbacks, it keeps them all in the order they were defined. When an event is triggered, all the callbacks are then executed in that same order (unless you muck around with said order).

SVN::Dumpfile represents a Subversion dumpfile. It provides methods to read existing and write modified or new dumpfiles. It supports dumpfiles with the version number 1 - 3 but was written in a tolerant way to also support newer versions as long no major changes are made. This module is a OO redesign and generalisation of SVN::Dumpfilter v0.21. Newer versions of SVN::Dumpfilter are using it to access the input and output dumpfiles. The ability to create new dumpfiles sets it apart from the similar module SVN::Dump. The submodule SVN::Dumpfile::Node::Properties also allows the processing of Subversion revision property files (i.e. the files lying in the $REPOSITORY/db/revprops/ directory holding the author, date and log entry of every revision).