Ports Search

DateTime::Astro implements functions used in astronomical calendars: - Solar Longitude - Solar Terms - Lunar Longitude - New Moons ... etc This module is best used in environments where a C compiler and the MPFR arbitrary precision math library is installed. It can fallback to using Math::BigInt, but that would pretty much render it useless because of its speed and loss of accuracy that may creep up while doing Perl to C struct conversions.

The DateTime::Event::Easter module returns Easter events for DateTime objects. From a given datetime, it can tell you the previous, the following and the closest Easter event. The 'is' method will tell you if the given DateTime is an Easter Event. Easter Events can be Palm Sunday, Maundy Thursday, Good Friday, Black Saturday and Easter Sunday. If that's not enough, the module will also accept an offset so you can get the date for Pentecost (49 days after Easter Sunday) by passing 49.

Declaring constants is very convenient for writing programs, but as they're often inlined by Perl, retrieving their symbolic names can be tricky. This is made worse with low level modules that use constants for bit-twiddling. Devel::Constants makes this much more manageable. It silently wraps around the constant module, intercepting all constant declarations. It builds a hash, associating the values to their names. The names can then be retrieved as necessary.

The Perl 5 module Devel::Events::Objects provides an event generator and a handler for Devel::Events, that facilitate leak checking. There are two components of this module: Devel::Events::Generator::Objects, and Devel::Events::Handler::ObjectTracker. The first one uses some trickery to generate events for every object creation and destruction in code loaded after it was loaded. The second one will listen on these events, and track all currently living objects.

Perl's global destruction is a little tricky to deal with WRT finalizers because it's not ordered and objects can sometimes disappear. Writing defensive destructors is hard and annoying, and usually if global destruction is happenning you only need the destructors that free up non process local resources to actually execute. For these constructors you can avoid the mess by simply bailing out if global destruction is in effect.

Module Getopt::ArgvFile is a simple supplement to other option handling modules. It allows script options and parameters to be read from files instead of from the command line by interpolating file contents into @ARGV. This way it PREPARES the final option handling. Getopt::ArgvFile does NOT perform any option processing itself, and should work fine together with any other option handling module (e.g. Getopt::Long) or even self coded option handling. -Anton <tobez@FreeBSD.org>

This module provides an attribute wrapper around Getopt::Long. Instead of declaring the options in a hash with references to the variables and subroutines affected by the options, you can use the Getopt attribute on the variables and subroutines directly. As you can see from the Synopsis, the attribute takes an argument of the same format as you would give as the hash key for Getopt::Long. See the Getopt::Long manpage for details.

Module Getopt::Long implements an extended getopt function called GetOptions(). This function implements the POSIX standard for command line options, with GNU extensions, while still capable of handling the traditional one-letter options. In general, this means that command line options can have long names instead of single letters, and are introduced with a double dash `--'. Optionally, Getopt::Long can support the traditional bundling of single-letter command line options.

Gearman is a system to farm out work to other machines, dispatching function calls to machines that are better suited to do work, to do work in parallel, to load balance lots of function calls, or to call functions between languages. This is the server daemon component. The bridge between workers (clients who can do work) and callers (clients who want work done). You should run several of these, at least two, for both load balancing and high availability.

With this module you can capture any combination of STDIN, STDOUT, and STDERR. In the case of STDIN, you may feed any input into capture you want (or even set it to use another file handle). For STDOUT and STDERR you may review the full output of these or prior to capture set a file handle that will receive all the data during the capture.