Free dispatch software for linux

Log::Dispatch::ToTk provides class to redirect Log::Dispatch to Tk widgets.

Most users will only need to use Log::Dispatch::TkText widget to have Log::Dispatch messages written on a text widget.

For more fancy uses, this module can be used by a composite widget dedicated to handle Log::Dispatch logs.

This module is the interface class between Log::Dispatch and Tk widgets. This class is derived from Log::Dispatch::Output.

One ToTk object will be created for each Log::Dispatch::Tk* widget and the user must register the ToTk object to the log dispatcher.

Create a new ToTk object. Parameter are :
- widget ($) - The buddy widget object
- name ($) - The name of the object (not the filename!). Required.
- min_level ($) - The minimum logging level this object will accept. See the Log::Dispatch documentation for more information. Required.
- max_level ($) - The maximum logging level this obejct will accept. See the Log::Dispatch documentation for more information. This is not required. By default the maximum is the highest possible level (which means functionally that the object has no maximum).

Log::Dispatch::Atom is a Perl module to log to an atom feed.

SYNOPSIS

use Log::Dispatch::Atom;

my $log = Log::Dispatch::Atom->new(
name => foo,
min_level => debug,
file => file.atom
);
$log->log_message( level => error, message => A problem happened );
$log->log_message( level => debug, message => Got Here );

This class implements logging backed by an Atom feed so that you can subscribe to the errors produced by your application.

You should not use this object directly, but should manage it via a Log::Dispatch object.

IMPLEMENTATION NOTES

In order to safely write to the log file, the entire file must be locked each time that an entry is logged. This probably makes it unsuitable for high volume log files.
The log file is opened and closed on each call to log_message().

METHODS

new()

Takes a hash of arguments. Returns a new Log::Dispatch::Atom object. The following parameters are used:

name [mandatory]

The name of the logging object.

min_level [mandatory]

The minimum logging level this object will accept. See Log::Dispatch for more information.

max_level [optional]

The maximum logging level this object will accept. See Log::Dispatch for more information. The default is the highest possible level (ie: no maximum).

file [mandatory]

Specifies the location of the file to read/write the feed from.

feed_id [optional]

Specifies the identity of the feed itself. Normally, this should be set to the published URI of the feed.
If not specified, it will be omitted, which is in violation of the Atom specification. For more information, see http://www.atomenabled.org/developers/syndication/#requiredFeedElements.

feed_title [optional]

The title of the feed. This should probably be set to the name of your application.

If not specified, it will be omitted, which is in violation of the Atom specification. For more information, see http://www.atomenabled.org/developers/syndication/#requiredFeedElements.
XXX This should probably just use the name parameter. What do you think? Let me know.

feed_author [optional]

The author details of a feed. This is specified as a hash reference, which must contain one or more of the three keys name, email and uri.

In order to create a valid Atom feed, you must either supply an author in every single entry (log message), or ensure that the feed itself has an author. The latter is probably the easier solution, so I recommend this parameter be supplied.

NB: The feed_* parameters will only be used when a new feed is being created. If you are creating a new object for an existing feed, they will be ignored.

log_message()

Takes a hash of arguments. Has no return value. The following parameters are used.

message [mandatory]

The actual log message.

level [mandatory]

The level of the message. See Log::Dispatch for a full list.

id [optional]

Each entry requires an id in order for the feed as a whole to be a valid Atom document. Its used by readers of Atom documents to determine whether or not an entry has been seen previously.

If not specified, this will default to an URL comprising the current time plus the pid plus the hostname plus a monotonically increasing integer. eg: tag:fred.example.com,2005-12-07:1133946771/20827/2. This should be good enough for a uniqueness test.

author [optional]

You can specify author details for an individual entry if desired. The author parameter is expected to be a hash reference, which must contain one or more of the keys name, email or uri.

Hash::Diff::Dispatch allows to execute code depending on difference between hashes.

SYNOPSIS

my $hash_watcher = Hash::Diff::Dispatch->new(

{}, # Sets the starting hash

# The events will be called using the order returned
# by calling keys on these values...

b => &bold,
i => &italic,

);


# Will call: bold(on, 5)
$hash_watcher->update( { b => 5, a => la } );

# Will call: bold(changed, 6)
$hash_watcher->update( { b => 6 } );

# Will call: bold(changed, 0)
$hash_watcher->update( { b => 0 } );

# Will call: bold(off)
$hash_watcher->update( {} );

METHODS

new

Accepts a starting hash-ref, and then a list of keys you want to watch, and the code to execute when they change. It will take a copy of the hash in the hash-ref you specify.

update

Accepts a hash-ref, which itll take a copy of, and make it the saved hash to check the next call to update again.
If a keys value has changed, itll execute the code specified when you created the object. If the key exists where it didnt before, itll pass on as the first argument, and the new value as the second. If its changed, changed and the new value. If its been deleted, itll pass off.

Content Dispatcher project will dispatch content over many plone sites in one click.

Let a content to be dispatch over many plone sites in one click.

Log::Dispatch::File::Alerts is a Perl object for logging to alert files.

SYNOPSIS

use Log::Dispatch::File::Alerts;

my $file = Log::Dispatch::File::Alerts->new(
name => file1,
min_level => emerg,
filename => Somefile%d{yyyy!!!!}.log,
mode => append );

$file->log( level => emerg,
message => "Ive fallen and I cant get upn" );

ABSTRACT

This module provides an object for logging to files under the Log::Dispatch::* system.

This module subclasses Log::Dispatch::File for logging to date/time stamped files. See Log::Dispatch::File for instructions on usage. This module differs only on the following three points:

alert files

This module will use a seperate file for every log message.

multitasking-safe

This module uses flock() to lock the file while writing to it.

stamped filenames

This module supports a special tag in the filename that will expand to the current date/time/pid.

It is the same tag Log::Log4perl::Layout::PatternLayout uses, see Log::Log4perl::Layout::PatternLayout, chapter "Fine-tune the date". In short: Include a "%d{...}" in the filename where "..." is a format string according to the SimpleDateFormat in the Java World (http://java.sun.com/j2se/1.3/docs/api/java/text/SimpleDateFormat.html). See also Log::Log4perl::DateFormat for information about further restrictions.
In addition to the format provided by Log::Log4perl::DateFormat this module also supports $ for inserting the PID and ! for inserting a uniq number. Repeat the character to define how many character wide the field should be.
A note on the !: The module first tries to find a fresh filename with this set to 1. If there is already a file with that name then it is increased until either a free filename has been found or it reaches 9999. In the later case the module dies.

XML::Filter::Dispatcher is a path based event dispatching with DOM support.

SYNOPSIS

use XML::Filter::Dispatcher qw( :all );

my $f = XML::Filter::Dispatcher->new(
Rules => [
foo => &handle_foo_start_tag,
@bar => &handle_bar_attr,

## Send any elts and their contents to $handler
snarf//self::node() => $handler,

## Print the text of all elements
description
=> [ string() => sub { push @out, xvalue } ],
],

Vars => {
"id" => [ string => "12a" ],
},
);

WARNING: Beta code alert.

A SAX2 filter that dispatches SAX events based on "EventPath" patterns as the SAX events arrive. The SAX events are not buffered or converted to an in-memory document representation like a DOM tree. This provides for low lag operation because the actions associated with each pattern are executed as soon as possible, usually in an elements start_element() event method.

This differs from traditional XML pattern matching tools like XPath and XSLT (which is XPath-based) which require the entire document to be built in memory (as a "DOM tree") before queries can be executed. In SAX terms, this means that they have to build a DOM tree from SAX events and delay pattern matching until the end_document() event method is called.

Sub::PatMat can call a version of subroutine depending on its arguments.
SYNOPSIS
use Sub::PatMat;
# basics:
sub fact : when($_[0] $b) { 1 }
print join ", ", sort mysort (3,1,2);
# intuiting parameter names:
sub dispatch : when($ev eq "help") { my ($ev) = @_; print "helpn" }
sub dispatch : when($ev eq "blah") { my ($ev) = @_; print "blahn" }
dispatch("help");
dispatch("blah");
# no fallback, this will die:
dispatch("hest"); # dies with "Bad match"
# silly
sub do_something : when(full_moon()) { do_one_thing() }
sub do_something { do_something_else() }
The Sub::PatMat module provides the programmer with the ability to define a subroutine multiple times and to specify what version of the subroutine should be called, depending on the parameters passed to it (or any other condition).
This is somewhat similar to argument pattern matching facility provided by many programming languages.
To use argument pattern matching on a sub, the programmer has to specify the when attribute. The parameter to the attribute must be a single Perl expression.
When the sub is called, those expressions are evaluated consequitively until one of them evaluates to a true value. When this happens, the corresponding version of a sub is called.
If none of the expressions evaluates to a true value, a Bad Match exception is thrown.
It is possible to specify a fall-back version of the function by doing one of the following:
specifying when without an expression
specifying when with an empty expression
not specifying the when attribute at all
Please note that it does not make sense to specify any non-fall-back version of the sub after the fall-back version, since such will never be called.
There is an additional limitation for the last form of the fall-back version (the one without the when attribute at all), namely, it must be the last version of the sub defined.
It is possible to specify named sub parameters in the when-expression. This facility is highly experimental and is currently limited to scalar parameters only. The named sub parameters are extracted from expressions of the form
my (parameter list) = @_;
anywhere in the body of the sub.
Version restrictions:
- The ability to intuit parameter names is very limited and without doubts buggy.
- The when attribute condition is limited to a single Perl expression.
Enhancements:
- Perl