Free features 0.32 software for linux

Lingua::Phonology::Features is a module to handle a set of hierarchical features.

SYNOPSIS

use Lingua::Phonology;

my $phono = new Lingua::Phonology;
my $features = $phono->features;

# Add features programmatically
$features->add_feature(
Node => { type => privative, children => [Scalar, Binary, Privative] },
Scalar => { type => scalar },
Binary => { type => binary },
Privative => { type => privative }
);

# Drop features
$features->drop_feature(Privative);

# Load feature definitions from a file
$features->loadfile(phono.xml);

# Load default features
$features->loadfile;

Lingua::Phonology::Features allows you to create a hierarchy of features of various types, and includes methods for adding and deleting features and changing the relationships between them.

By "heirarchical features" we mean that some features dominate some other features, as in a tree. By having heirarchical features, it becomes possible to set multiple features at once by assigning to a node, and to indicate conceptually related features that are combined under the same node. This module, however, does not instantiate values of features, but only establishes the relationships between features.

Lingua::Phonology::Features recognizes multiple types of features. Features may be privative (which means that their legal values are either true or undef), binary (which means they may be true, false, or undef), or scalar (which means that their legal value may be anything). You can freely mix different kinds of features into the same set of features.

Finally, while this module provides a full set of methods to add and delete features programmatically, it also provides the option of reading feature definitions from a file. This is usually faster and more convenient. The method to do this is "loadfile". Lingua::Phonology::Features also comes with an extensive default feature set.

Gimp::Feature is a Perl module that can check for specific features to be present before registering the script.

SYNOPSIS

use Gimp::Feature;
or
use Gimp::Feature qw(feature1 feature2 ...);

This module can be used to check for specific features to be present. This can be used to deny running the script when neccessary features are not present. While some features can be checked for at any time, the Gimp::Fu module offers a nicer way to check for them.

gtk

checks for the presence of the gtk interface module.

gtk-1.1, gtk-1.2

checks for the presence of gtk-1.1 (1.2) or higher.

perl-5.005

checks for perl version 5.005 or higher.

pdl

checks for the presence of a suitable version of PDL (>=1.9906).

gnome

checks for the presence of the Gnome-Perl module.

gtkxmhtl

checks for the presence of the Gtk::XmHTML module.

unix

checks wether the script runs on a unix-like operating system. At the moment, this is every system except windows, macos, os2 and vms.

persistency

checks wether the Gimp::Data module (Gimp::Data) can handle complex persistent data structures, i.e. perl references in addition to plain strings.

The following features can only be checked after Gimp-main> has been called (usually found in the form exit main). See Gimp::Fu on how to check for these.
gimp-1.1, gimp-1.2

checks for the presense of gimp in at least version 1.1 (1.2).

FUNCTIONS

present(feature)

Checks for the presense of the single feature given as the argument. Returns true if the feature is present, false otherwise.

need(feature,[function-name])

Require a specific feature. If the required feature is not present the program will exit gracefully, logging an appropriate message. You can optionally supply a function name to further specify the place where this feature was missing.

This is the function used when importing symbols from the module.

missing(feature-description,[function-name])

Indicates that a generic feature (described by the first argument) is missing. A function name can further be specified. This function will log the given message and exit gracefully.

describe(feature)

Returns a string describing the given feature in more detail, or undef if there is no description for this feature.

list()

Returns a list of features that can be checked for. This list might not be complete.

Net::Stomp is a Streaming Text Orientated Messaging Protocol Client.

SYNOPSIS

# send a message to the queue foo
use Net::Stomp;
my $stomp = Net::Stomp->new( { hostname => localhost, port => 61613 } );
$stomp->connect( { login => hello, passcode => there } );
$stomp->send(
{ destination => /queue/foo, body => test message } );
$stomp->disconnect;

# subscribe to messages from the queue foo
use Net::Stomp;
my $stomp = Net::Stomp->new( { hostname => localhost, port => 61613 } );
$stomp->connect( { login => hello, passcode => there } );
$stomp->subscribe(
{ destination => /queue/foo,
ack => client,
activemq.prefetchSize => 1
}
);
while (1) {
my $frame = $stomp->receive_frame;
warn $frame->body; # do something here
$stomp->ack( { frame => $frame } );
}
$stomp->disconnect;

# write your own frame
my $frame = Net::Stomp::Frame->new(
{ command => $command, headers => $conf, body => $body } );
$self->send_frame($frame);

This module allows you to write a Stomp client. Stomp is the Streaming Text Orientated Messaging Protocol (or the Protocol Briefly Known as TTMP and Represented by the symbol :ttmp). Its a simple and easy to implement protocol for working with Message Orientated Middleware from any language.

Net::Stomp is useful for talking to Apache ActiveMQ, an open source (Apache 2.0 licensed) Java Message Service 1.1 (JMS) message broker packed with many enterprise features.

A Stomp frame consists of a command, a series of headers and a body - see Net::Stomp::Frame for more details.

DFA::Simple is a Perl module to implement simple Discrete Finite Automata.

SYNOPSIS

my $Obj = new DFA::Simple
or
my $Obj = new DFA::Simple $Transitions;
or
my $Obj = new DFA::Simple $Actions, $StateRules;

$Obj->Actions = [...];
my $Trans = $LP->Actions;

$Obj->StateRules = [...];
my $StateRules = $LP->StateRules;

my $Obj = new DFA::Simple $Actions,[States];

This creates a simple automaton with a finite number of individual states. The short version is that state numbers are just indices into the array.

The state basically binds the rest of the machine together:

1. There might be something you want done whenever you enter a given state (Transition Table)
2. There might be something you want done whenever you leave a given state (Transition Table)
3. You can go to some states from the current state (Action table)
4. There are tests to decide whether you should go to that new state (Action table)
5. There are conditional tasks you can do while sitting in that new state (Action table)

This structure may remind you of the SysV run-level concepts. It is very similar.
At run time you dont typically feed any state numbers to the finite machine; you ignore them. Rather your program may read inputs or such. The tests for the state transition would examine this input, or some other variables to decide which new state to go to. Whenever your code has gotten enough input, it would call the Check_For_NextState() method. This method runs through the tests, and carries out the state transitions ("firing the rules").

Thread::Pool contains group of threads for performing similar jobs.

SYNOPSIS

use Thread::Pool;
$pool = Thread::Pool->new(
{
optimize => cpu, # default: memory

pre => sub {shift; print "starting worker with @_n",
do => sub {shift; print "doing job for @_n"; reverse @_},
post => sub {shift; print "stopping worker with @_n",

stream => sub {shift; print "streamline with @_n",

monitor => sub { print "monitor with @_n",
pre_post_monitor_only => 0, # default: 0 = also for "do"

checkpoint => sub { print "checkpointingn" },
frequency => 1000,

autoshutdown => 1, # default: 1 = yes

workers => 10, # default: 1
maxjobs => 50, # default: 5 * workers
minjobs => 5, # default: maxjobs / 2
},
qw(a b c) # parameters to "pre" and "post" routine
);

$pool->job( qw(d e f) ); # not interested in result

$jobid = $pool->job( qw(g h i) );
@result = $pool->result( $jobid ); # wait for result to be ready

$jobid = $pool->job( qw(j k l) );
@result = $pool->result_dontwait( $jobid ); # do _not_ wait for result

@result = $pool->waitfor( qw(m n o) ); # submit and wait for result

$pool->add; # add worker(s)
$pool->remove; # remove worker(s)
$pool->workers( 10 ); # adapt number of workers
$pool->join; # wait for all removed worker threads to finish

$workers = $pool->workers;
$todo = $pool->todo;
$removed = $pool->removed;

$pool->maxjobs( 100 ); # adapt or (de-)activate job throttling
$pool->minjobs( 10 );

$pool->autoshutdown( 1 ); # shutdown when object is destroyed
$pool->shutdown; # wait until all jobs done
$pool->abort; # finish current job and remove all workers

$done = $pool->done; # simple thread-use statistics
$notused = $pool->notused;

Thread::Pool->remove_me; # inside "do" only

GTK-Pinger is a cyclic multi ping utility for selected adresses using ncurses/GTK.
You simply write adresses into a configuration file and after execution of pinger, you will see small nice window, which inform you about current status of selected hosts and their triptimes.
Enhancements:
- The GTK window is now scrollable.
- Debian package support was added.
- Memory leaks were fixed.
- Some minor changes were made.

KonSort is a graphical front-end for GNUFilter, which makes creating filters even easier for users.
About GNUFilter:
GNUFilter is a command-line application that addresses the need to keep a users directories structured and clean.
Main features:
- KonSort can load GNUFilter configuration files.
- KonSort provides two ways to create new filters: a wizard for beginning users and a more advanced window.

Video Related Picture Editor is a gtk2 GUI frontend for batch-manipulating images using ImageMagick, MPlayer and transcode.

Its also the name of the infamous VRPE Team who paid me for hacking this together quickly because they needed it.

The name

Why "video related picture encoder" ? Because I didnt find a better name :) Any suggestions are welcome. With v0.1 the project was called "gFader" because all it did was "morphing" single frames to slow-down a video (giving a "fade-like effect") as batch-job with nice gui so poor Windows users could use it ;) My customer then wanted gFader to also do crop and scaling of multiple image files which rendered "gFader" as projectname useless. So i tried to make up some general name, which still fits if the application-range grows.

What can it do?

VRPE is able to do batch image-processing on a large set of images providing a way to move between images and giving a preview of the current, the previous and the next frame all with a nice GUI.

Different effects can be applied to the image-set (e.g morph, crop). Some of the effects support variable parameters so an effect can change with the image position.

VRPE can load several image formats (the ones supported by gtk2 and ImageMagick) or can convert almost any video to single frames using mplayer. It exports single images but also can render a videofile using mencoder or transcode. You can even launch mplayer to look at what youve done.

Other Features are:

Tooltip explainations almost everywhere
Nice wiki
quite fast

Drawbacks at this time:

lousy hacked together code
somewhat static filename handling
no "project" cababilities (images from previous sessions get imported if directory is not cleared etc.)
morph-curve gets lost
many more...