Free augments software for linux

Crossroads is a load balance and failover utility for TCP-based services.
Crossroads Load Balancer is a daemon program running in userspace and features extensive configurability, polling of backends using "wakeup calls", detailed status reporting, "hooks" for special actions when backend calls fail, and more.
It is service-independent; it is usable for HTTP(S), SSH, SMTP, DNS, etc.
Crossroads is a daemon that basically accepts TCP connections at preconfigured ports, and given a list of back ends distributes each incoming connection, so that a client process is served.
Additionally, crossroads maintains an internal administration of the back end connectivity: if a back end isnt usable, then the client request is handled using another back end. Crossroads will then periodically check whether a previously not usable back end has come to life yet. Also, crossroads can select back ends by estimating the load, so that balancing is achieved.
Using this approach, crossroads serves as load balancer and fail over utility. Crossroads will very likely not be as reliable as hardware based balancers, since it always will require a server to run on. This server, in turn, may become a new Single Point of Failure (SPOS). However, in situations where cost efficiency is an issue, crossroads may be a good choice.
Furthermore, crossroads can be deployed in situations where a hardware based balancing already exists and augmenting service reliability is needed. Or, crossroads may be run off a diskless system, which again improves reliability of the underlying hardware.
This document describes how to use crossroads, how to configure it in order to increase the reliability of your systems, and how to compile the program from its sources. This document is also available in PDF format.
Usage:
Crossroads is started from the commandline, and highly depends on /etc/crossroads.conf (the default configuration file). It supports a number of flags (e.g., to overrule the location of the configuration file). The actual usage information is always obtained by typing crossroads without any arguments. Crossroads then displays the allowed arguments.
This section shows the basic usage.
- crossroads start and crossroads stop are typical actions that are run from system startup scripts. The meaning is self-explanatory.
- crossroad status reports on each running service. Per service, the state of each back end is reported.
- crossroads tell service backend state is a command line way of telling crossroads that a given back end, of a given service, is in a given state. Normally crossroads maintains state information itself, but by using crossroads tell, a back end can be e.g. taken off line for servicing.
- crossroads services reports on the configured services. In contrast to crossroads status, this option only shows whats configured -- not whats up and running. Therefore, crossroads services doesnt report on back end states.
- crossroads sampleconf shows a sample configuration on screen. A good way of quicky viewing the configuration file syntax, or of getting a start for your own configuration /etc/crossroads.conf.

GGobi is an open source visualization program for exploring high-dimensional data.
The application provides highly dynamic and interactive graphics such as tours, as well as familiar graphics such as the scatterplot, barchart and parallel coordinates plots.
Plots are interactive and linked with brushing and identification.
Main features:
- Need to look up cases with low or high values on some variables (price, weight,...) and show how they behave in terms of other variables? ? brush in linked plots.
- Want to fluently examine the results of your R analyses in R? Use rggobi to easily transfer data between the two applications.
- Need to "see" the separation between clusters in high dimensions? ? take a (helicopter) tour in high dimension.
- Want to examine network data? ? lay out the network graphically and link it to other plots.
- Need to create high-quality publication graphics? Read about the describe display plugin and associated R package.
- Draw dotplots and scatterplots, barcharts, spineplots and histograms, parallel coordinate plots, scatterplot matrices
- Link data points and lines between plots using persistent or transient brushing, and identification
- Pan and zoom
- Rotate data in 3D, and tour high-dimensional data using sequences of 1D, 2D and 2x1D projections augmented by manual control and automatic projection pursuit guidance
- Acts as a high-dimensional drawing tool, by adding, moving, and drawing lines between points.
- Connects with R to perform statistical analyses
- Can be extended using modular plugins
Installation:
./configure --with-all-plugins
make
sudo make install
make ggobirc
sudo mkdir -p /etc/xdg/ggobi
sudo cp ggobirc /etc/xdg/ggobi/ggobirc
You may need to include /usr/local/lib in LD_LIBRARY_PATH if it is not already there.

SQLAlchemy is a SQL toolkit and object relational mapper for Python.
The Python SQL toolkit and Object Relational Mapper that gives application developers the full power and flexibility of SQL. SQLAlchemy provides a full suite of well known enterprise-level persistence patterns, designed for efficient and high-performing database access, adapted into a simple and Pythonic domain language.
- extremely easy to use for all the basic tasks, such as: accessing thread-safe and pooled connections, constructing SQL from Python expressions, finding object instances, and commiting object modifications back to the database.
- powerful enough for complicated tasks, such as: eager load a graph of objects and their dependencies via joins; map recursive adjacency structures automatically; map objects to not just tables but to any arbitrary join or select statement; combine multiple tables together to load whole sets of otherwise unrelated objects from a single result set; commit entire graphs of object changes in one step.
- built to conform to what DBAs demand, including the ability to swap out generated SQL with hand-optimized statements, full usage of bind parameters for all literal values, fully transactionalized and consistent updates using Unit of Work.
- modular. Different parts of SQLAlchemy can be used independently of the rest, including the connection pool, SQL construction, and ORM. SQLAlchemy is constructed in an open style that allows plenty of customization, with an architecture that supports custom datatypes, custom SQL extensions, and ORM plugins which can augment or extend mapping functionality.
SQLAlchemys Philosophy:
- SQL databases behave less and less like object collections the more size and performance start to matter; object collections behave less and less like tables and rows the more abstraction starts to matter. SQLAlchemy aims to accomodate both of these principles.
- Your classes arent tables, and your objects arent rows. Databases arent just collections of tables; theyre relational algebra engines. You dont have to select from just tables, you can select from joins, subqueries, and unions. Database and domain concepts should be visibly decoupled from the beginning, allowing both sides to develop to their full potential.
- For example, table metadata (objects that describe tables) are declared distinctly from the classes theyre designed to store. That way database relationship concepts dont interfere with your object design concepts, and vice-versa; the transition from table-mapping to selectable-mapping is seamless; a class can be mapped against the database in more than one way. SQLAlchemy provides a powerful mapping layer that can work as automatically or as manually as you choose, determining relationships based on foreign keys or letting you define the join conditions explicitly, to bridge the gap between database and domain.
SQLAlchemys Advantages:
- The Unit Of Work system organizes pending CRUD operations into queues and commits them all in one batch. It then performs a topological "dependency sort" of all items to be committed and deleted and groups redundant statements together. This produces the maxiumum efficiency and transaction safety, and minimizes chances of deadlocks. Modeled after Fowlers "Unit of Work" pattern as well as Java Hibernate.
- Function-based query construction allows boolean expressions, operators, functions, table aliases, selectable subqueries, create/update/insert/delete queries, correlated updates, correlated EXISTS clauses, UNION clauses, inner and outer joins, bind parameters, free mixing of literal text within expressions, as little or as much as desired. Query-compilation is vendor-specific; the same query object can be compiled into any number of resulting SQL strings depending on its compilation algorithm.
- Database mapping and class design are totally separate. Persisted objects have no subclassing requirement (other than object) and are POPOs : plain old Python objects. They retain serializability (pickling) for usage in various caching systems and session objects. SQLAlchemy "decorates" classes with non-intrusive property accessors to automatically log object creates and modifications with the UnitOfWork engine, to lazyload related data, as well as to track attribute change histories.
- Custom list classes can be used with eagerly or lazily loaded child object lists, allowing rich relationships to be created on the fly as SQLAlchemy appends child objects to an object attribute.
- Composite (multiple-column) primary keys are supported, as are "association" objects that represent the middle of a "many-to-many" relationship.
- Self-referential tables and mappers are supported. Adjacency list structures can be created, saved, and deleted with proper cascading, with no extra programming.
- Data mapping can be used in a row-based manner. Any bizarre hyper-optimized query that you or your DBA can cook up, you can run in SQLAlchemy, and as long as it returns the expected columns within a rowset, you can get your objects from it. For a rowset that contains more than one kind of object per row, multiple mappers can be chained together to return multiple object instance lists from a single database round trip.
- The type system allows pre- and post- processing of data, both at the bind parameter and the result set level. User-defined types can be freely mixed with built-in types. Generic types as well as SQL-specific types are available.

Array::Each::Tutorial - POD giving various examples how to use Array::Each.

SYNOPSIS

man Array::Each
man Array::Each::Tutorial

or

perldoc Array::Each
perldoc Array::Each::Tutorial

Overview

This tutorial contains only POD, so dont do this:

use Array::Each::Tutorial; # dont do this

Rather, simply read the POD (as you are doing). But first, please read the docs for Array::Each, because the whole scoop is there.

This tutorial is intended to augment those docs with examples showing situations where you might want to use Array::Each instead of other techniques.

EXAMPLES

Parallel Arrays vs. Using a Hash

First of all, use a hash. Its almost always the best solution if you want to associate a "key" with a "value". And there are modules available that will let you do wonderful things with hashes, like keeping the keys sorted or keeping them in the order they were added.

So given a hash, you might at some point want to do this:

my %h = ( a=>1, b=>2, c=>3, d=>4, e=>5 );
while( my( $k, $v ) = each %h ) {
# ... do something with $k and $v ...
}

On the other hand, if parallel arrays better implement your algorithm, then you may find you want to do something like this:

my @k = qw( a b c d e );
my @v = qw( 1 2 3 4 5 );
for my $i ( 0 .. $#k ) {
my( $k, $v ) = ( $k[$i], $v[$i] );
# ... do something with $k and $v (and maybe $i) ...
}

Using Array::Each, you could do the same thing this way:

use Array::Each;
my @k = qw( a b c d e );
my @v = qw( 1 2 3 4 5 );
my $obj = Array::Each->new( @k, @v );
while( my( $k, $v, $i ) = $obj->each ) {
# ... do something with $k and $v (and maybe $i) ...
}

If you dont need $i at all, you can leave it out, e.g.,

while( my( $k, $v ) = $obj->each ) {
# ... do something with $k and $v ...
}

If you have more than two parallel arrays, include them all in the call to new() and add as many "capture" variables as you need, e.g.,

my @k = qw( a b c d e );
my @v = qw( 1 2 3 4 5 );
my @p = qw( - + ~ = : );
my $obj = Array::Each->new( @k, @v, @p );
while( my( $k, $v, $p, $i ) = $obj->each ) {
# ... do something with $k, $v, and $p (and maybe $i) ...
}

Perl6::Classes project contains first class classes in Perl 5.

SYNOPSIS

use Perl6::Classes;

class Composer {
submethod BUILD { print "Giving birth to a new composern" }
method compose { print "Writing some music...n" }
}

class ClassicalComposer is Composer {
method compose { print "Writing some muzak...n" }
}

class ModernComposer is Composer {
submethod BUILD($) { $.length = shift }
method compose() { print((map { int rand 10 } 1..$.length), "n") }
has $.length;
}

my $beethoven = new ClassicalComposer;
my $barber = new ModernComposer 4;
my $mahler = ModernComposer->new(400);

$beethoven->compose; # Writing some muzak...
$barber->compose # 7214
compose $mahler; # 89275869347968374698756....

Perl6::Classes allows the creation of (somewhat) Perl 6-style classes in Perl 5. The following features are currently supported:

subs, methods, and submethods
And their respective scoping rules.

Attributes
Which are available through the has keyword, and look like $.this.

Inheritance
Both single and multiple inheritance are available through the is keyword.

Signatures
Signatures on methods, subs, and submethods are supported, but just the Perl 5 kind.

Data hiding
Using the public, protected, and private traits, you can enforce (run-time) data hiding. This is not supported on attributes, which are always private.

Anonymous classes
That respect closures. You can now nest them inside methods of other classes, even other anonymous ones!

The Perl6::Classes module augments Perls syntax with a new declarator: class. It offers the advantage over Perls standard OO mechanism that it is conceptually easier to see (especially for those from a C++/Java background). It offers the disadvantage, of course, of being less versatile.

idl2html is a Perl module that enerates HTML documentation from IDL source files.

SYNOPSIS

idl2html [options] spec.idl

OPTIONS

All options are forwarded to C preprocessor, except -f -h -i -o -s -t -v -x.

With the GNU C Compatible Compiler Processor, useful options are :

-D name
-D name=definition
-I directory
-I-
-nostdinc

Specific options :

-f

Enable the frameset mode.

-h

Display help.

-i directory

Specify a path for import (only for version 3.0).

-o file

Specificy the outfile for HTML Help (default "htmlhelp").

-s style

Generate an external Cascading Style Sheet file.

-t title

Specificy the title of HTML Help.

-v

Display version.

-x

Enable export (only for version 3.0).

idl2html parses the declarations and doc comments in a IDL source file and formats these into a set of HTML pages. idl2html generates some helper files for HTML Help compiler.

idl2html works like javadoc.

Within doc comments, idl2html supports the use of special doc tags to augment the documentation. idl2html also supports standard HTML within doc comments. This is useful for formatting text.

idl2html reformats and displays declaration for:

Modules, interfaces and value types

Operations (with parameters) and attributes

Types (typedef, enum, struct, union with members)

Exceptions (with members)

Constants

Pragma (ID, version as tag)

Automated support for compound RPC calls is a project which augments RPCGEN to support NFSv4-style compound procedures.

NFSv4 specifies that the RPC calls be batched into a "compound" call. There is no support for this in RPCGEN.

By rearranging the ONC IDL for NFSv4 into AutoGen definitions, these templates will emit the original IDL *plus* all the code to package, send, distribute, collect, return, and dispatch the results.

The distributed program author merely needs to call and supply server procedures for the routines specified in the IDL.

Templates for these calls and service routines is provided, too. The NFSv4 definitions are included.

Data distribution is achieved by transparent replication of a shared scene graph among the participating processes of a distributed application.

A sophisticated group communication system is used to guarantee state consistency even in the presence of late joining and leaving processes. The familiar dataflow graph found in modern stand-alone 3D-application toolkits extends nicely to the distributed case.

Many toolkits for the development of stand-alone VE applications exist today. They provide the programmer with a high-level interface to represent complex geometry in a scene graph and to render that scene graph. The programmer is shielded from the details of dealing with low-level graphics and system APIs, and can concentrate on the development of the application itself.

AVANGO provides programmers with the concept of a shared scene-graph, accessible from all processes forming a distributed application. Each process owns a local copy of the scene graph and the contained state information, which is kept synchronized.

Our object-oriented framework allows the creation of application specific classes, which inherit these distribution properties. Furthermore, the shared scene-graph is augmented with a distributed dataflow graph. This provides the same evaluation characteristics in distributed applications as in stand-alone applications, and effectively supports the development of distributed interactive applications.

In contrast to similar systems like Repo-3D (MacIntyre:1998) we focus on high-end, real-time, virtual environments like CAVEs (Cruz-Neira:1993:SSP) and Workbenches (HKP:Krueger94,HKP:Krueger95), therefore the development is based on SGI Performer (Rohlf:1994:IPH).

With AVANGO, we provide a framework that combines the familiar programming model of existing stand-alone toolkits with built-in support for data distribution that is almost transparent to the application developer.