Free delta airlines software for linux

EDelta is a fast XDelta-style binary differ, but optimized for executables which have a very systematic way of changing between versions. EDelta has not been thoroughly evaluated so far, but on one example (two versions of Vim) it produces a 30kB delta where XDelta needs 250kB.
My personal use for edelta is to quickly deploy Linux kernels from my development-laptop to my test-machines, especially when working over my slow ADSL line at home. I frequently see factor of 100 speedups compared to shipping the whole file.
Whats New in 0.9e Stable Release:
- This release adds a -q switch, better arguments parsing, and an improved version of the epatch script for remote patching using SSH.
Whats New in 0.10a Development Release:
- This version adds the -le switch, which provides better compression on Intel and other little-endian platforms.
- It also fixes a few bugs.

Delta project assists users in minimizing "interesting" files, subject to a test of their "interestingness".
A common such situation is when attempting to isolate a small failure-inducing substring of a large input that causes a program to exhibit a bug.
The best way to understand how to use delta is with an example of its usage. Below is one example helpfully written up for me by Simon Goldsmith; read it first. For those wanting more, I also wrote a more detailed and harder to read document describing each tool: Using Delta.
Note that what follows is an example of using delta to minimize an input file to a program that reads programs, much as a compiler does. Note two features of file minimization that are present in the example.
Do a controlled experiment.
Below we dont just minimize a file that causes Oink to produce an error message, we minimize a file that causes gcc to accept AND oink to reject in a specific way. That is, the test delta does is a controlled experiment, where gcc is the control. Ignoring this aspect of the problem seems to be a frequent mistake of first time users.
Exploit nested structure.
One may minimize files of simpler syntax than C++ but really all files are interesting in the first place because they are in some language or another. Some simple configuration files are literally just a list of lines but most languages have some nested structure. Multidelta filters the input through the topformflat utility (included) to suppress any newlines past a particular nesting depth; this "explains" the nesting structure to the otherwise line-oriented delta utility (a brilliantly simple idea of Scott McPeaks).
If your input file language has no nesting structure, you can hack on multidelta to remove the filtration through topformflat or just use the raw delta program. If your language has a different nesting structure than C/C++, you can write your own multidelta and substitute it. A simple flex program should suffice; it need not be terribly accurate for delta to do well.
Enhancements:
- It is now much easier to stop delta.
- It catches signals and distinguishes them from return codes.
- It watches for the DELTA-STOP file at the same granularity as the tests are run.
- In multidelta, running the input file through cpp is off by default and can be turned on with the flag -cpp.

DFA::Kleene is a Kleenes Algorithm for Deterministic Finite Automata.

Calculates the "language" (set of words) accepted (= recognized) by a Deterministic Finite Automaton.

SYNOPSIS

use DFA::Kleene qw(initialize define_accepting_states define_delta kleene example);

use DFA::Kleene qw(:all);

&initialize(6,"ab");

Define the number of states (state #1 is the "start" state!) of your Deterministic Finite Automaton and the alphabet used (as a string containing all characters which are part of the alphabet).

&define_accepting_states(2,3,4,5);

Define which states are "accepting states" in your Deterministic Finite Automaton (list of state numbers).

&define_delta(1,a,4);

Define the state transition function "delta" (arguments are: "from" state, character (or empty string!) read during the transition, "to" state).
You need several calls to this function in order to build a complete transition table describing your Deterministic Finite Automaton.

@language = &kleene();

Returns a (sorted) list of regular expressions describing the language (= set of patterns) recognized ("accepted") by your Deterministic Finite Automaton.
&example();

Calculates the language of a sample Deterministic Finite Automaton.
Prints a (sorted) list of regular expressions which should be equivalent to the following regular expression:

(a(a)*b)*a(a)*(b)*

This is the same as

((a+)b)*(a+)b*

The routines in this module allow you to define a Deterministic Finite Automaton and to compute the "language" (set of "words" or "patterns") accepted (= recognized) by it.

Actually, a list of regular expressions is generated which describe the same language (set of patterns) as the one accepted by your Deterministic Finite Automaton.

The output generated by this module can easily be modified to produce Perl-style regular expressions which can actually be used to recognize words (= patterns) contained in the language defined by your Deterministic Finite Automaton.

Other modules in this series (variants of Kleenes algorithm):

Math::MatrixBool (see "Kleene()")
Math::MatrixReal (see "kleene()")

Test::Number::Delta is a Perl module to compare the difference between numbers against a given tolerance.

SYNOPSIS

# Import test functions
use Test::Number::Delta;

# Equality test with default tolerance
delta_ok( 1e-5, 2e-5, values within 1e-6);

# Inequality test with default tolerance
delta_not_ok( 1e-5, 2e-5, values not within 1e-6);

# Provide specific tolerance
delta_within( 1e-3, 2e-3, 1e-4, values within 1e-4);
delta_not_within( 1e-3, 2e-3, 1e-4, values not within 1e-4);

# Compare arrays or matrices
@a = ( 3.14, 1.41 );
@b = ( 3.15, 1.41 );
delta_ok( @a, @b, compare @a and @b );

# Set a different default tolerance
use Test::Number::Delta within => 1e-5;
delta_ok( 1.1e-5, 2e-5, values within 1e-5); # ok

# Set a relative tolerance
use Test::Number::Delta relative => 1e-3;
delta_ok( 1.01, 1.0099, values within 1.01e-3);

At some point or another, most programmers find they need to compare floating-point numbers for equality. The typical idiom is to test if the absolute value of the difference of the numbers is within a desired tolerance, usually called epsilon. This module provides such a function for use with Test::Harness. Usage is similar to other test functions described in Test::More. Semantically, the delta_within function replaces this kind of construct:

ok ( abs($p - $q) < $epsilon, $p is equal to $q ) or
diag "$p is not equal to $q to within $epsilon";

While theres nothing wrong with that construct, its painful to type it repeatedly in a test script. This module does the same thing with a single function call. The delta_ok function is similar, but either uses a global default value for epsilon or else calculates a relative epsilon on the fly so that epsilon is scaled automatically to the size of the arguments to delta_ok. Both functions are exported automatically.

Because checking floating-point equality is not always reliable, it is not possible to check the equal to boundary of less than or equal to epsilon. Therefore, Test::Number::Delta only compares if the absolute value of the difference is less than epsilon (for equality tests) or greater than epsilon (for inequality tests).

PHP Online RPG project is an graphical online RPG.
This RPG uses only the browser to create a vast world. The power of html tables allow us to create a graphical online rpg that is fast, and vivid. The only requirements are a browser and patience.
As the world grows, its possible for the code to move slower and we ask your patience. This game truly is an inspiration to those who want to play games at work on a simple web browser.
The RPG featured has certain placement graphics from Delta Taos ClanLord. These are not meant for distribution, but for examples. You can change the style to a Diablo-type RPG, or an anime rpg, or something completely different such as a space RPG.
The project, including the layout, is open ended. The first couple of releases are to get public interest. The code is not the best. When we have a stable release we will mark the download. The only admin at this time is Adam.Atomical.
Enhancements:
- Object oriented interface
- Specialized function interface ( for PHP coders )
- Multi-player combat
- Single player combat
- Treasure
- Finding Inventory
- Spawning of Items

dbdeploy is a Database Change Management tool. The project helps developers and DBAs change their database in a simple, controlled, flexible and frequent manner.

The recurring problem with database development is that at some point you’ll need to upgrade an existing database and preserve its content. In development environments it’s often possible (even desirable) to blow away the database and rebuild from scratch as often as the code is rebuilt but this approach cannot be taken forward into more controlled environments such as QA, UAT and Production.

Drawing from our experiences, we’ve found that one of the easiest ways to allow people to change the database is by using version-controlled SQL delta scripts. We’ve also found it beneficial to ensure that the scripts used to build development environments are the exact same used in QA, UAT and production. Maintaining and making use of these deltas can quickly become a significant overhead - dbdeploy aims to address this.

How It Works

By comparing the SQL delta scripts on your filesystem against a patch table in the target database, it generates SQL scripts – it doesn’t directly apply them.

Invocation methods

dbdeploy can be called from within an ant build file.

DBMS support

dbdeploy supports the following DBMS:

Oracle
MS SQL Server
Sybase
Hypersonic SQL

Time::Skew is a Perl module that computes local clock skew with respect to a remote clock.

SYNOPISI

use Time::Skew

# Init Convex Hull and timing data
my $hull=[];
my $result={};

# Iterate data point introduction
Time::Skew::convexhull($result,$datapoint,$hull);

This module supports the computation of the skew between two clocks: the (relative) skew is the speed with which two clocks diverge. For instance, if yesterday two clocks, at the same time, showed respectively 10:00 and 10:05, while today when the former shows 10:00 the latter shows 10:04, we say that their relative skew is 1 minute/24 hours, roughly 7E-4.

The module contains one single subroutine, which accepts as input a pair of timestamps, associated to a message from host A to host B: the timestamps correspond to the time when the message was sent, and to the time when message is received. Each timestamp reflects the value of the local clock where the operation takes place: the clock of host A for the send, the clock of B for the receive.

Please note that the module does _not_ contain any message exchange facility, but only the mathematics needed to perform the skew approximation, once timestamps are known.

The subroutine takes as argument:

a reference to a hash where values related to the timing of the network path from A to B;
a 2-elems array (a data point in the sequel) containing the timestamp of the receive event, and the differece between the send timestamp and the receive timestamp for one message;
a stack containing some data points, those that form the convex hull.

The usage is very simple, and is illustrated by the following example:

#!/usr/bin/perl -w
use strict;
use Time::Skew;

# Initialize data
my $hull=[];
my $result={};
while ( 1 ) {
# Exchange message and acquire a new data point
my $datapoint = acquire();
# Call the convexhull subroutine
Time::Skew::convexhull($result,$datapoint,$hull);
# After first message some results are still undefined
( defined $result->{skewjitter} ) || next;
# here you can use the results

};
}

The data returned in the "result" hash is the following:

result->{skew} the clock skew;
result->{skewjitter} the variance of the skew estimate, used to estimate convergence;
result->{jitter} difference between the current delay and the previous delay;
result->{delay} the communication delay, decremented by a constant (yet unknown) value, used to compute communication jitter;
result->{elems} the number of data points in the convex hull;
result->{select} the index of the data point in the convex hull used to compute the skew;
result->{itimestamp} the timestamp, first element in the data point just passed to the subroutine;
result->{delta} the timestamp difference, second element in the data point just passed to the subroutine;

The data returned in the "hull" stack is a series of data points, selected from those passed to successive calls of the subroutine. The number of data points in the "hull" stack usually does not exceed 20 units.

The algorithm is very fast: each call consists in scanning at most all data points in the "hull" stack, performing simple arithmetic operations for each element.

The algorithm must be fed with a sequence of data points before returning significant results. The accuracy of the estimate keeps growing while new data points are passed to the subroutine. A rough rule of thumb to evaluate estimate accuracy is to observe the skew jitter, and assume it corresponds to the skew estimate accuracy. Paths with quite regular communication delay (small jitter) converge faster.