Ports Search

This small low-level module only has one purpose: pass a file descriptor to another process, using a (streaming) Unix domain socket (on POSIX systems) or any (streaming) socket (on WIN32 systems). The ability to pass file descriptors on windows is currently the unique selling point of this module. Have I mentioned that it is really small, too?

Test::CPAN::Meta::YAML was written to ensure that a META.yml file, provided with a standard distribution uploaded to CPAN, meets the specifications that slowly being introduced to module uploads, via the use of ExtUtils::MakeMaker, Module::Build and Module::Install. See CPAN::Meta for further details of the CPAN Meta Specification.

IPC::ShellCmd comes from the nth time I've had to implement a select loop and wanted appropriate sudo/su privilege magic, environment variables that are set in the child, working directories set etc. It aims to provide a reasonable interface for setting up command execution environment (working directory, environment variables, stdin, stdout and stderr redirection if necessary), but allowing for ssh and sudo and magicking in the appropriate shell quoting. It tries to be flexible about how you might want to capture output, exit status and other such, but in such a way as it's hopefully easy to understand and make it work. Setup method calls are chain-able in a File::Find::Rule kind of a way.

POD is a pretty simple format to write, but it can be a big pain to deal with reading it and doing anything useful with it. Most existing POD parsers care about semantics, like whether a =item occurred after an =over but before a back, figuring out how to link a L<>, and other things like that. Pod::Eventual is much less ambitious and much more stupid. Fortunately, stupid is often better. (That's what I keep telling myself, anyway.) Pod::Eventual reads line-based input and produces events describing each POD paragraph or directive it finds. Once complete events are immediately passed to the handle_event method. This method should be implemented by Pod::Eventual subclasses. If it isn't, Pod::Eventual's own handle_event will be called, and will raise an exception.

Data::Dumper and other modules do a great job at dumping data structures. Their output, however, often takes more brain power to understand than the data itself. When dumping large amounts of data, the output can be overwhelming and it's difficult to see the relationship between each piece of the dumped data. Data::TreeDumper also dumps data in a tree-like fashion but hopefully in a format more easily understood. Data::TreeDumper also gives one extraordinary control over output and provides for custom filtering of and iteration over data structures.

Return::Type allows you to specify a return type for your subs. Type constraints from any Type::Tiny, MooseX::Types or MouseX::Types type library are supported. The simple syntax for specifying a type constraint is shown in the "SYNOPSIS" [1]. If the attribute is passed a single type constraint as shown, this will be applied to the return value if called in scalar context, and to each item in the returned list if called in list context. (If the sub is called in void context, type constraints are simply ignored.) [1] http://search.cpan.org/dist/Return-Type/lib/Return/Type.pm#SYNOPSIS

The Mmap module lets you use mmap to map in a file as a Perl variable rather than reading the file into dynamically allocated memory. The advantage of this is that several processes may share one copy of the file or string, saving memory, and concurrently making changes to portions of the file or string. When not used with a file, it is an alternative to SysV shared memory that places no arbitrary size limits on the shared memory area, and efficiently handles sparse memory usage.

Portdowngrade helps to downgrade FreeBSD ports by analyzing the history of commits to the port and presenting the user the list of changes. By selecting one, the port can be set back to a previous version easily.

Fileprune will delete files from the specified set targeting a given distribution of the files within time as well as size, number, and age constraints. Its main purpose is to keep a set of daily-created backup files in manageable size, while still providing reasonable access to older versions. Specifying a size, file number, or age constraint will simply remove files starting from the oldest, until the constraint is met. The distribution specification (exponential, Gaussian (normal), or Fibonacci) provides finer control of the files to delete, allowing the retention of recent copies and the increasingly aggressive pruning of the older files. The retention schedule specifies the age intervals for which files will be retained. As an example, an exponential retention schedule for 10 files with a base of 2 will be 1 2 4 8 16 32 64 128 256 512 1024 The above schedule specifies that for the interval of 65 to 128 days there should be (at least) one retained file (unless constraints and options override this setting).

mod_whatkilledus is an experimental module for Apache httpd 2.x which tracks the current request and logs a report of the active request when a child process crashes. Requirements: Apache httpd >= 2.0.49 must be built with the --enable-exception-hook configure option and mod_so enabled. Activating mod_whatkilledus: 1. Load it like any other DSO. LoadModule whatkilledus_module modules/mod_whatkilledus.so 2. Enable exception hooks for modules like mod_whatkilledus: EnableExceptionHook On 3. Choose where the report on current activity should be written. If you want it reported to some place other than the error log, use the WhatKilledUsLog directive to specify a fully-qualified filename for the log. Note that the web server user id (e.g., "nobody") must be able to create or append to this log file, as the log file is not opened until a crash occurs.