Free modules software for linux

Lin-setibuf Modules are a set of Perl modules for manipulating both the SETI@Home client files, and the SETI@Home text client.
SETI::Monitor offers an intuitive interface to stats retrieval, and manipulation via a Perl program. SETI::Client gives the Perl programmer a high-level layer for control of the SETI@Home client.
Enhancements:
- Bug fixed in the Do_Loop sub (thaks to beatrice).
- Added Glin-setibuf in the contrib/ directory. Glin-setibuf is a graphical tool (written in Perl/GTK) that checks the stack status. See README.contrib for more details, and glin-setibufs help for its command line options.
- Resyncd with SETI 0.44 - history file changed, so there could be warnings from Perl, complaining about a null concatenation; to avoid them, you may backup the old history file, create a new history and then diff back the old stats.
- Bug fixed in the `PushStack sub - now adding units to the stack works again.
- Main PID file is saved only when elaboration starts (because you may want to launch download when still elaborating).

CGI::WeT::Modules::Basic is a basic rendering engine extensions.

SYNOPSIS

use CGI::WeT::Modules::Basic ();

This module provides basic rendering constructs for the engine. Please be aware that the code supersedes the documentation. While I have tried to be accurate there are times that words fail me and a look at the code is far more enlightening than anything I could cobble together. This is especially true when trying to write a theme. Download a theme and see how someone else did it. Then try making modifications and see what happens.

CGI::WeT::Modules::Calendar are Perl extensions to engine to allow calendar management.

SYNOPSIS

use CGI::WeT::Modules::Calendar ();

This module provides rendering constructs to allow navigation through a set of calendars. Support is provided for multiple types of events in multiple calendars, both public and private (general and user specific).

EXTENSIONS

CGI::WeT::Modules::Calendar::initialize($engine, $r)

This subroutine will initialize the engine passed as $engine with information from Apache (passed as $r). The base URL for calendars is set with the following.

PerlSetVar WeT_CalendarURL /baseURL/

This is available for building URLs as @@CALENDAR@@. For example, the top level calendar can be viewed at the URL returned by

$engine->url(@@CALENDAR@@/general/);

A list of available calendars might be found at

$engine->url(@@CALENDAR@@/);

Module::Versions is a Perl module to handle versions of loaded modules with flexible result interface.

SYNOPSIS

use Module::Versions;

# Simple Interface
list Module::Versions; # prints formatted results to STDOUT
Module::Versions->list; # prints formatted results to STDOUT

# Shortcuts
$vers = get Module::Versions; # retrieves loaded modules

$vers = Module::Versions->get; # retrieves loaded modules

$array = Module::Versions->ARRAY; # returns array with version infos
$hash = Module::Versions->HASH; # returns hash with version infos

$list = Module::Versions->SCALAR; # returns text list with version infos
$csv = Module::Versions->CSV; # returns csv list with version infos
$xml = Module::Versions->XML; # returns xml struct with version infos
$xsd = Module::Versions->XSD; # returns xml schema of version infos
$dtd = Module::Versions->DTD; # returns DTD of version infos

# Individual Parameters
$vers = Module::Versions # retrieves mods and vars as defined
->new($mods,$vars)
->get($criteria);

$vers->list($fd,$mask); # prints formatted results to file
$vers->list($fd,$preform); # prints preformatted results to file
$vers->list($fd,&cb); # prints serialied results as handled
# in callback routine
$vers->data(&cb); # returns transformed results as
# defined in callback routine
# Individual formatted output
list Module::Versions(*LOG, %5d %1s %-20s %10s %-16s);
# prints individually formatted
# results to LOG
list Module::Versions(*DBIMPORT, %s|%s|%s);
# prints individually formatted
# results to Database Import file

list Module::Versions(*FD, SCALAR);# prints text list results to file
list Module::Versions(*FD, CSV); # prints csv list results to file
list Module::Versions(*FD, XML); # prints xml struct results to file
list Module::Versions(*FD, XSD); # prints xml schema to file
list Module::Versions(*FD, DTD); # prints DTD to file

list Module::Versions(*FD, ARRAY); # prints serialized results to file
list Module::Versions(*FD, HASH); # prints serialized results to file

Module::Versions->list(*LOG); # prints formatted results to LOG

# Pretty Compact
Module::Versions->list # prints formatted results on STDOUT
->list(*XML,XML); # prints xml struct results to XML file

Module::Versions->list # prints formatted results on STDOUT
->list(*XSD,XSD) # prints xml schema to XSD file
->list(*XML,XML); # prints xml struct results to XML file

Module::Versions->list # prints formatted results on STDOUT
->list(*DTD,DTD) # prints DTD to DTD file
->list(*XML,XML); # prints xml struct results to XML file

Module::Versions handles versions of loaded modules with a flexible result interface. The main goal is to get as much version informations as possible about a module or module list with a simple call interface and an absolutely flexible result interface. Module::Versions handles *loaded* and *loadable* modules.

The motivation for writing this module was the need for better support facilities to get informations about the used modules and versions in the productivity environment. Module::Versions allows shipping applications basically with something like a -version option (See Getopt::Long) but with expanded functions.

Module::Versions tries to read the loaded/loadable modules $VERSION. For extended purposes any private project version variables can be fetched ($_VERSION, $version, $REV, etc.).

Module::Versions has a flexible result interface to satisfy different needs: results can be lists and data structures with different formats - pre-formed ARRAY, HASH, SCALAR, CSV, XML/XSD/DTD and a full flexible user callback interface.
It is for example very simple to print a good formatted version list to the console and save a version.xml file (in conjunction with an xsd-schema) at the same time with an absolutely minimum of coding (SYNOPSIS, Pretty Compact) .
Module::Versions tries to load version.pm to support Perl 5.10.0s $VERSION formatting.

Gimp::Module can run scripts embedded into the Gimp program.

SYNOPSIS

not anything you would expect - and not documented, even!

Module::Build::JSAN is a Perl module to build JavaScript modules for JSAN.

SYNOPSIS

use Module::Build::JSAN;

my $build = Module::Build::JSAN->new(
module_name => Foo-Bar,
license => perl,
dist_author => Joe Developer ,
dist_abstract => Say something pithy here,
dist_version => 0.02,
keywords => [qw(Foo Bar pithyness)],
build_requires => {
Test.Simple => 0.20,
},
requires => {
JSAN => 0.10,
Baz-Quux => 0.02,
},
);

$build->create_build_script;

This is a developer aid for creating JSAN distributions. Please use the example given in the SYNOPSIS to create distributions.

Module::Build is a Perl module for build and install Perl modules.

SYNOPSIS

Standard process for building & installing modules:
perl Build.PL
./Build
./Build test
./Build install
Or, if youre on a platform (like DOS or Windows) that doesnt require the "./" notation, you can do this:
perl Build.PL
Build
Build test
Build install

Module::Build is a system for building, testing, and installing Perl modules. It is meant to be an alternative to ExtUtils::MakeMaker. Developers may alter the behavior of the module through subclassing in a much more straightforward way than with MakeMaker.

It also does not require a make on your system - most of the Module::Build code is pure-perl and written in a very cross-platform way. In fact, you dont even need a shell, so even platforms like MacOS (traditional) can use it fairly easily. Its only prerequisites are modules that are included with perl 5.6.0, and it works fine on perl 5.005 if you can install a few additional modules.