Ports Search

Certain applications like to defer the decision to use a particular module till runtime. This is possible in perl, and is a useful trick in situations where the type of data is not known at compile time and the application doesn't wish to pre-compile modules to handle all types of data it can work with. Loading modules at runtime can also provide flexible interfaces for perl modules. Modules can let the programmer decide what modules will be used by it instead of hard-coding their names.

require EXPR only accepts Class/Name.pm style module names, not Class::Name. How frustrating! For that, we provide load_class 'Class::Name'. It's often useful to test whether a module can be loaded, instead of throwing an error when it's not available. For that, we provide try_load_class 'Class::Name'. Finally, sometimes we need to know whether a particular class has been loaded. Asking %INC is an option, but that will miss inner packages and any class for which the filename does not correspond to the package name. For that, we provide is_class_loaded 'Class::Name'.

This module provides a 'Local Mean Time' timezone for DateTime. Using it you can determine the Mean Time for any location on Earth. Note however that the Mean Time and the Apparent Time (where the sun is in the sky) differ from day to day. This module may account for Local Apparent Time in the future but then again, the Solar:: modules will probably be a better bet. If you want more information on the difference between LMT and LAT, search the www for 'equation of time' or 'ephemeris'.

File::NFSLock - perl module to do NFS (or not) locking. The module is based of concept of hard linking of files being atomic across NFS. This concept was mentioned in Mail::Box::Locker (which was originally presented in Mail::Folder::Maildir). Some routine flow is taken from there -- particularly the idea of creating a random local file, hard linking a common file to the local file, and then checking the nlink status. Some ideologies were not complete (uncache mechanism, shared locking) and some coding was even incorrect (wrong stat index). File::NFSLock was written to be light, generic, and fast.

Mac::FileSpec::Unixish provides two functions, `nativize' and `unixify' (both of which are exported by default), that will allow you to denote and manipulate pathspecs in Unixish style, and let you convert these pathspecs to and from the native OS's format for conveying such things. It currently assumes that if you are not running under MacOS (as reported in `$^O'), you must be on a Unix box. If you want better, use File::Spec -- in essence, Mac::FileSpec::Unixish is a cheap hack to get around using File::Spec.

This is a utility that creates common Moose subtypes, coercions and option specifications useful for dealing with Path::Class objects as Moose attributes. This module constructs coercions (see Moose::Util::TypeConstraints) from both 'Str' and 'ArrayRef' to both Path::Class::Dir and Path::Class::File objects. It also adds the Getopt option type ("=s") for both Path::Class::Dir and Path::Class::File (see MooseX::Getopt). This is just meant to be a central place for these constructs, so you don't have to worry about whether they've been created or not, and you're not tempted to copy them into yet another class (like I was).

Resources are a way to specify information of interest to program or packages. Applications use resource files to specify and document the values of quantities or attributes of interest. Resources can be loaded from or saved to resource files. Methods are provided to search, modify and create resources. Packages use resources to hardwire in their code the default values for their attributes, along with documentation for the attributes themselves. Packages inherit resources when subclassed, and the resource names are updated dynamically to reflect a class hierarchy. Methods are provided for interactive resource inspection and editing.

This is a specialized POD viewer to extract embedded tests and code examples from POD. It doesn't do much more than that. pod2test does the useful work. After creating a Pod::Tests object, you parse the POD by calling one of the available parsing methods documented below. You can call parse as many times as you'd like, all examples and tests found will stack up inside the object. Once extracted, the tests can be built into stand-alone testing code using the build_tests() and build_examples() methods. However, it is recommended that you first look at the pod2test program before embarking on this.

Test::Class provides a simple way of creating classes and objects to test your code in an xUnit style. Built using Test::Builder it is designing to work with other Test::Builder based modules (Test::More, Test::Differences, Test::Exception, etc.) Note: This module will make more sense if you are already familiar with the "standard" mechanisms for testing perl code. Those unfamiliar with Test::Harness, Test::Simple, Test::More and friends should go take a look at them now. Note: This is an early release. Things may change. Be warned.

Java-Readline is a port of GNU Readline for Java. Or, to be more precise, it is a JNI-wrapper to Readline. It is distributed under the LGPL. You must call Readline.load(ReadlineLibrary lib); before using any other methods. If you omit the call to the load()-method, the pure Java fallback solution is used. Possible values for lib are: ReadlineLibrary.PureJava ReadlineLibrary.GnuReadline ReadlineLibrary.Editline ReadlineLibrary.Getline Note that all programs using GnuReadline will fall under the GPL, since Gnu-Readline is GPL software!