Free predictive texting software for linux

astGUIclient is a GUI client application for the Asterisk open-source PBX.
This is a suite of programs that are designed to interact with the Asterisk Open-Source PBX Phone system at a client computer level to extend the functionality of your phone and system.
The suite of software is designed to work with an Asterisk system that has Zap(T1/E1/PSTN),IAX or SIP trunks and SIP/IAX/Zap phones.
The main GUI application, astGUIclient, is a set of PHP web-based scripts utilizing Javascript and XMLHTTPRequest functions that work through a browser to give real-time information and functionality with nothing more than an internet browser on the client computer.
Another component included with the astGUIclient package is the VICIDIAL auto-dialer. This is a list dialer(another real-time web-client) that can be added to Asterisk and is highly configurable with detailed logging. VICIDIAL can dial one-call-at-a-time or you can put it in auto-dial mode and it acts as a predictive dialer. VICIDIAL also can function as an ACD for inbound calls or for Closer calls coming from VICIDIAL fronters and even allows for remote agents that may only have a phone.
The software suite also includes a from-scratch software installation document, full English and Spanish versions of the web-clients and admin pages, and the Asterisk Central Queue System(ACQS) which allows for optimized and streamlined Asterisk integration.
This group of applications is designed to run on top of just about any version of Asterisk so no messing around with the Asterisk source code is necessary. For more information see the system requirements. astGUIclient is not an Asterisk configuration utility, it is an end-user Graphical User Interface.
All astGUIclient software elements are distributed freely through the GPL with no warranty.
Main features:
- Grabs live call info from a DB updated every second
- Displays live status of users phones and Zap/IAX/SIP/Local channels
- Allows calls to be placed from GUI and directed to phone
- Allows intrasystem calls at the click of a button
- Allows call recording at the click of a button
- Allows conference calling of up to 6 channels through GUI
- Administrative Hangup of any live Zap/IAX/SIP/Local channel
- Administrative Hijack of any live Zap/IAX/SIP/Local channel
- Administrative switch user function
- Call Parking sends calls to park ext and then redirects to phone ext
- CallerID popup with buttons to open custom web pages
- Voicemail display and button to go right to check voicemail
- Allows Blind listening of calls on Zap channels
- Allows Blind transfers of calls to specific voicemail boxes
- Allows Blind transfers of calls to intrasystem extensions
- Allows Blind transfers of calls to external numbers
Additional Features available only in the web version:
- More than 6 channels in the conference room
- Send to Voicemail directly from the inbound call popup window
- All client phone connections are shown not just the first
- Allows transfers to conferences
- Call parking with callerID

Audio::Data is a module for representing audio data to perl.

SYNOPSIS

use Audio::Data;
my $audio = Audio::Data->new(rate => , ...);

$audio->method(...)

$audio OP ...

Audio::Data represents audio data to perl in a fairly compact and efficient manner using C via XS to hold data as a C array of float values. The use of float avoids many issues with dynamic range, and typical float has 24-bit mantissa so quantization noise should be acceptable. Many machines have floating point hardware these days, and in such cases operations on float should be as fast or faster than some kind of "scaled integer".

Nominally data is expected to be between +1.0 and -1.0 - although only code which interacts with outside world (reading/writing files or devices) really cares.
It can also represent elements (samples) which are "complex numbers" which simplifies many Digital Signal Processing methods.

Methods

The interface is object-oriented, and provides the methods below.
$audio = Audio::Data->new([method => value ...])
The "constructor" - takes a list of method/value pairs and calls $audio->method(value) on the object in order. Typically first "method" will be rate to set sampling rate of the object.

$rate = $audio->rate
Get sampling rate of object.
$audio->rate($newrate)
Set sampling rate of the object. If object contains existing data it is re-sampled to the new rate. (Code to do this was derived from a now dated version of sox.)
$audio->comment($string)
Sets simple string comment associated with data.
$string = $audio->comment
Get the comment
$time = $audio->duration
Return duration of object (in seconds).
$time = $audio->samples
Return number of samples in the object.
@data = $audio->data
Return data as list of values - not recommended for large data.
$audio->data(@data)
Sets elements from @data.
$audio->length($N)
Set number of samples to $N - tuncating or padding with zeros (silence).
($max,$min) = $audio->bounds([$start_time[,$end_time]])
Returns a list of two values representing the limits of the values between the two times if $end_time isnt specified it defaults to the duration of the object, and if start time isnt specified it defaults to zero.
$copy = $audio->clone
Creates copy of data carrying over sample rate and complex-ness of data.
$slice = $audio->timerange($start_time,$end_time);
Returns a time-slice between specified times.
$audio->Load($fh)
Reads Sun/NeXT .au data from the perl file handle (which should have binmode() applied to it.)
This will eventually change - to allow it to load other formats and perhaps to return list of Audio::Data objects to represnt multiple channels (e.g. stereo).
$audio->Save($fh[,$comment])
Write a Sun/NeXT .au file to perl file handle. $comment if specified is used as the comment.
$audio->tone($freq,$dur,$amp);
Append a sinusoidal tone of specified freqency (in Hz) and duration (in seconds), and peak amplitude $amp.
$audio->silence($dur);
Append a period of 0 value of specified duration.
$audio->noise($dur,$amp);
Append burst of (white) noise of specified duration and peak amplitude.
$window = $audio->hamming($SIZE,$start_sample[,$k])
Returns a "raised cosine window" sample of $SIZE samples starting at specified sample. If $k is specified it overrides the default value of 0.46 (e.g. a value of 0.5 would give a Hanning window as opposed to a Hamming window.)
windowed = ((1.0-k)+k*cos(x*PI))
$freq = $audio->fft($SIZE)
$time = $freq->ifft($SIZE);
Perform a Fast Fourier Transform (or its inverse). (Note that in general result of these methods have complex numbers as the elements. $SIZE should be a power-of-two (if it isnt next larger power of two is used). Data is padded with zeros as necessary to get to $SIZE samples.
@values = $audio->amplitude([$N[,$count]])
Return values of amplitude for sample $N..$N+$count inclusive. if $N is not specified it defaults to zero. If $count is not specified it defaults to 1 for scalar context and rest-of-data in array context.
@values = $audio->dB([$N[,$count]])
Return amplitude - in deci-Bells. (0dB is 1/2**15 i.e. least detectable value to 16-bit device.) Defaults as for amplitude.
@values = $audio->phase([$N [,$count]])
Return Phase - (if data are real returns 0). Defaults as for amplitude.
$diff = $audio->difference
Returns the first difference between successive elements of the data - so result is one sample shorter. This is a simple high-pass filter and is much used to remove DC offsets.
$Avalues = $audio->lpc($NUM_POLES,[$auto [,$refl]])
Perform Linear Predictive Coding analysis of $audio and return coefficents of resulting All-Pole filter. 0th Element is not a filter coefficent (there is no A[0] in such a filter) - but is a measure of the "error" in the matching process. $auto is an output argument and returns computed autocorrelation. $refl is also output and are so-called reflection coefficents used in "lattice" realization of the filter. (Code for this lifted from "Festival" speech systems speech_tools.)
$auto = $audio->autocorrelation($LENGTH)
Returns an (unscaled) autocorrelation function - can be used to cause peaks when data is periodic - and is used as a precursor to LPC analysis.

Dasher is a zooming predictive text entry system, designed for situations where keyboard input is impractical (for instance, accessibility or PDAs).

Dasher is usable with highly limited amounts of physical input while still allowing high rates of text entry.

Dasher is Free software released under the GPL. Further documentation may be found in the Doc/ subdirectory.

lib378 is a library for predictive text input. The API is very simple and provides dictionary autocompletion and both partial and full matching.
The project can be used to get text input from input devices with few keys (like cellphones).
Example:
#include < stdio.h >
#include < termios.h >
#include < unistd.h >
#include "378.h"
char mygetch ( void )
{
int ch;
struct termios oldt, newt;
tcgetattr ( STDIN_FILENO, &oldt );
newt = oldt;
newt.c_lflag &= ~( ICANON | ECHO );
tcsetattr ( STDIN_FILENO, TCSANOW, ?wt );
ch = getchar();
tcsetattr ( STDIN_FILENO, TCSANOW, &oldt );
return ch;
}
l378_DECLARE();
l378_KEYMAP = {
[a] = 2, [b] = 2, [c] = 2,
[d] = 3, [e] = 3, [f] = 3,
[g] = 4, [h] = 4, [i] = 4,
[j] = 5, [k] = 5, [l] = 5,
[m] = 6, [n] = 6, [o] = 6,
[p] = 7, [q] = 7, [r] = 7, [s] = 7,
[t] = 8, [u] = 8, [v] = 8,
[w] = 9, [x] = 9, [y] = 9, [z] = 9
};
static FILE* l378_dictionary;
int main( const int argc, const char *argv[] )
{
char c;
char* s = NULL;
if( !(l378_dictionary = fopen( "compressed.dict", "r" )) )
return -1;
printf( " 1 2 3n" );
printf( " C abc defnn" );
printf( " 4 5 6n" );
printf( " ghi jkl mnonn" );
printf( " 7 8 9n" );
printf( " pqrs tuv wxyznn" );
printf( " TAB 0 - n" );
printf( " auto _ nextnn" );
while( n != (c = mygetch()) )
{
switch( c )
{
//case 0:
// break;
case t:
if( (s = l378_match()) )
printf( "%sr", s );
continue;
case -:
break;
case 1:
printf( "ttttr" );
l378_popc();
break;
case 2:
case 3:
case 4:
case 5:
case 6:
case 7:
case 8:
case 9:
l378_pushc( c );
break;
default:
continue;
}
if( (s = l378_matche()) )
printf( "%sr", s );
else
printf( "%sr", l378_pattern );
}
printf( "n" );
fclose( l378_dictionary );
return 0;
}
// eof
Enhancements:
- The API was cleaned up.
- The compression algorithm was improved.
- Optional bz2 support was added.
- The cellphone example was updated.
- A sample English dictionary was added.
- Minor code fixes were made.

The Bioinformatics Benchmark System is an attempt to build a reasonable testing framework, tests, and data, to enable end users and vendors to probe the performance of their systems.

What we are trying to do is to create a framework for testing, and a core set of tests that all may download and use to probe specific elements of systems performance.

Moreover, the source to these tests are available under GPL, and are hosted on Bioinformatics.org and Scalable Informatics LLC The idea is to enable end users, consumers, systems developers, and others to easily build and use meaningful tests for measurement and tuning reasons.

Joe Landman from Scalable Informatics LLC conceived the idea and wrote the original codes. We are looking for additional benchmark code suggestions, tests, data sets, etc.

Current baseline tests are several NCBI BLAST runs, several HMMer runs, and a variety of others. We plan to include ClustalW, X!Tandem, various chemistry, dynamics, and related tests, as well as several others.

Tests such as LINPACK or HPL simply do not provide meaningful performance indicators or predictive models for high performance informatics. Unfortunately, nor do a number of more recent and focused tests.

This is a problem as LINPACK and HPL specifically test the performance on various matrix operations, where you have effectively regular memory access patterns, and specific mathematical operations.

These codes are most useful for comparison to codes with heavy floating point operations, and interleaved memory traffic. These codes were not designed for comprehensive systems benchmarking, where disk I/O, memory latency, and other factors all contribute to the performance issues.

The best tests are the ones that are most similar to the codes you will run on the machine. The tests themselves should be reasonable approximations to a real execution of your code, using real data. You may need to pare it back in order to get realistic run times.

You should have a reasonable subset of data sizes. A single test does not tell you how your system scales, and one of the reasons for the existance of this test is specifically to allow you to test the performance while you increase various aspects of the workload.

You rarely get a quiescent system in a cluster, so we would recommend that you try to run in as realistic an operating environment as possible. A baseline in a quiescent system is fine, but it may set your expectations unreasonably.
top

Fenris is a suite of tools suitable for code analysis, debugging, protocol analysis, reverse engineering, forensics, diagnostics, security audits, vulnerability research and many other purposes.
The main logical components are:
- Fenris: high-level tracer, a tool that detects the logic used in C programs to find and classify functions, logic program structure, calls, buffers, interaction with system and libraries, I/O and many other structures. Fenris is mostly a "whats inside" tracer, as opposed to ltrace or strace, tracers intended to inspect external "symptoms" of the internal program structure. Fenris does not depend on libbfd for accessing ELF structures, and thus is much more robust when dealing with "anti-debugging" code.
- libfnprints and dress: fingerprinting code that can be used to detect library functions embedded inside a static application, even without symbols, to make code analysis simplier; this functionality is both embedded in other components and available as a standalone tool that adds symtab to ELF binaries and can be used with any debugger or disassembler.
- Aegir: an interactive gdb-alike debugger with modular capabilities, instruction by instruction and breakpoint to breakpoint execution, and real-time access to all the goods offered by Fenris, such as high-level information about memory objects or logical code structure.
- nc-aegir: a SoftICE-alike GUI for Aegir, with automatic register, memory and code views, integrated Fenris output, and automatic Fenris control (now under development).
- Ragnarok: a visualisation tool for Fenris that delivers browsable information about many different aspects of program execution - code flow, function calls, memory object life, I/O, etc (to be redesigned using OpenDX or a similar data exploration interface).
- ...and some other companion utilities.
Code analysis is not limited to debugging, quality assurance or security audits. Understanding and handling file formats or communication protocols used by proprietary solutions, a problem that many corporations face when they decide to change their base software platform from one, obsolete or insufficient solution to another, perhaps more suitable, is a task that can consume long months and millions of dollars, especially when any misjudgment or misinterpretation is made.
Because of that, accurate and complete information about existing solutions has to be obtained and evaluated in a timely manner. This project is an attempt to fill the gap between currently used tools by providing a freely available program analysis utility, suitable for black-box code audits, algorithm analysis,
rapid reconnaissance in open-source projects, tracking down bugs, evaluating security subsystems, performing computer forensics, etc.
This program does not automate the process of auditing, and does not favor any particular use. Instead of that, it is intended to be a flexible and universal application that will be a valuable solution for many advanced users. While functional, it is probably not tested sufficiently, there are many issues to fix, several known bugs, some portability problems.
It is being released primarily to get user feedback, comments, and, most important, to request development support, as my resources are very limited, both in terms of available time and development platforms. This project is and will be distributed as a free software, regardless of projected use, accompanied by complete sources, under the terms and
conditions of GPL. Why do you might need this code? Well, there are few reasons...
Human beings are, so far, the best code analysts. Unlike computer programs, they have imagination, ability to build synthetic abstract models, and yet to observe and analyze smallest details at the same time. Functionality is often being described as "doing what the program is supposed to do", security as "doing what the program is supposed to do and
nothing more". While it might sound funny, that is the most general and complete definition we have. In most real-life scenarios only humans really know what are their expectations. Building strict formal models of our expectations does not necessarily mean that models themselves are flawless, and is very time-consuming. Then, even with such models,
validating the code is not always possible, due to its computational complexity. That is why real, live programs (not including some critical developments) do not have such models, do not follow any particular coding guidelines, and cannot be formally examined without human judgment.
Unfortunately, humans are also highly inaccurate and very expensive. They work slowly, and better results can be achieved by hiring better specialists and performing more careful audit. And after all, even the best expert can overlook something in complex, hard to read code. It is almost impossible for human to perform an accurate audit of a large, complex, heterogeneous project written e.g. in C - like Sendmail, BIND, Apache - and provide results in reasonable time.
Things get even worse when humans try to understand algorithms and protocols used by complex closed-source black box solutions. They are simply too slow, and not always able to make accurate guesses about dozens of complicated, conditional parameter passes and function calls before final action is taken.
While it might sound surprising, human-driven code audit is very similar to playing chess - it is a general analysis of possible states, way too many to be implicitly projected by our conscience, a result of experience, knowledge, some unparalleled capabilities of human brain, and luck. It is also a subject to false moves and misjudgment. And there are maybe just a few hundred excellent players.
As for today, freely and commercially available audit tools both use two opposite approaches. First approach tends to minimize human role by automating the review of source code. Source code analysis methods are good in spotting known, repeatable static errors in the code - such as format string vulnerabilities. On the other hand, static tools are not able to trace and analyze all possible execution paths of complex application by
simply looking at its source.
The reason for inability to follow all execution paths lies deeply in the foundations of modern computation theory, and one of its aspects is known as "the halting problem". Speaking in more general terms, in many cases (such as complex software, or even underlying operating system), the amount of medium needed to store all possible states of a complex program exceeds significantly the number of particles in the
universe; and the amount of time needed to generate and process them sequentially is greater than the lifetime of our universe, even having a machine that works with the speed of light.
This might be changed by the development of new computation models, such as quantum computing, or by creating mathematical models that allow us to make such problems non-polynomial - but for now, we are far from this point, and static analysis is restrained in many very serious ways, even though many software suppliers tend to market their products as the ultimate, 100% solutions. Subtle, complex, conditional dynamic errors, such as privilege dropping problems, input-dependent table overflows in C and many other issues usually cannot be detected without generating a completely unacceptable number of false positives.
This kind of software is highly dependent on coding style, and specific notation or development practices might render them less efficient - for example, automated audit utilities can usually detect problems like insecure call to strcpy() function, but will very likely not notice insecure manual copy in do-while
loop. The truth is, for programs that do not have previously built formal models, static auditing utilities look for known, common problems in known, common types of code in a very limited scope.
Another issue is the applicability of this approach to algorithm analysis tasks. In the domain of automated audit tools, this problem is "reduced" to building a formal model of program behavior, or, more appropriately, generating certain predictive statements about the code. While there are very interesting developments in this direction, such as the work of professor Patrick Cousot, it is very difficult to make any detailed, accurate and abstract enough run-time predictions for complex source code that has any immediate value in the analysis of unknown algorithm.
Last but not least, static analysis of sources can be deployed only when the source code is available, which does not have to be the case. This approach is a subject to many shortcomings, tricky assertions, and is a technique of strictly limited capabilities. This is, of course, not to dismiss this method - but to demonstrate that this much favored approach is not flawless and how much it needs to be accompanied with auxiliary methods.
The second approach to be discussed here is based on a dynamic run-time program analysis. This method is usually used to provide the user with information about actual program execution path, letting him make decisions on which path to follow and giving him free will to draw any conclusions and perform all the synthetic reasoning.
This method is
applied to a live binary executed in real-time and is based on monitoring syscalls (strace), libcalls (ltrace) or functions (xtrace); in certain cases, breakpoint debuggers, such as gdb, can be used, however it is usually not feasible to use them to perform anything more than in-depth analysis of a very small portion of program functionality. Usually, such analysis provides a very useful information on what is happening, and this information is provided in uniform, reduced-output form.
A careful auditor can analyze program behavior and find interesting or potentially dangerous run-time conditions. By monitoring how a given application interacts with external world, he (or she) can determine whether some other
conditions can be triggered and eventually explore them by examining sources or re-running the program. Advantages are enormous, as such software enables the auditor to spot very subtle errors in code that "looked good", to observe actual execution, not to try to figure it out, and to find or trace down not obvious or non-schematic vulnerabilities. Run-time trace tools are primarily used for fast reconnaissance tasks and for tracing down notorious errors that are not clearly visible in the source, significantly reducing the time of such operations.
There are, however, serious drawbacks related to this method. First of all, known tracing tools do not provide the complete information. They will detect strcpy() call, but wont report if exactly the same functionality has been implemented from scratch by the author of given program. And, in some cases, the amount of produced data
can be enormous, and because of its completely unstructured character, it makes the observation of overall execution vector almost impossible. Two most important problems are: correlating trace data with actual code, and determining what occurred in the "dark matter" between two lines of trace output.
There are some attempts to combine both approaches - run-time evaluation and source code analysis - such as Purify or many other commercial development support products. Unfortunately, they all feature a limited set of capabilities that need development-side or compilation-time support and are not really suitable for comprehending black box solutions or performing a general analysis. Most of them are targeted for dynamic memory debugging and code / memory profiling.
While not mentioned above, there is also another approach to black-box code - high-level decompiler. However, the complexity of modern compilers makes it very difficult to develop an effective C decompiler or similar utility, and there are only a few (two?) projects available to accomplish it, all of them not able to deal with too complex or optimized code. Finally, there is no guarantee that generated output code will be any help in comprehending the program. For now, this approach remains almost purely theoretical,
and I am not aware of any auditors using it extensively. Why? Well, heres an example of decompiled, mildly optimized code *with* some symbolic information: http://www.backerstreet.com/rec/ex386/hdgO.rec . One may argue it is less readable than cross-referenced disassembly.
This project, Fenris, is named after the monstrous wolf, son of the Norse god Loki. It is not the ultimate answer to all questions, not a solution for all problems, and under no circumstances is intended to replace other tools and techniques. On the other hand, it makes one step forward compared to other tools, trying to support the auditor and to make his work much more effective. This is accomplished by combining a number of techniques, including partial run-time decompiler, stateful analysis, code fingerprinting, I/O analysis, high-level visualization layer, traditional interactive debugger features and run-time code modification capabilities. The goal is to provide a very detailed trace information, and, at the same time, to provide data suitable to build a model of program behavior more quickly and in more convenient way.
Fenris is not supposed to find vulnerabilities or bugs, or to guess algorithms or describe protocols. It is supposed to report and analyze the execution path - detect and describe functional blocks, monitor data flow in the program, marking its lifetime, source, migration and destination, analyze how functions work and what conditions are evaluated.
At the end, it can deliver you an execution model of traced program (or arbitrarily chosen portion of it, if complete trace results in too much noise or irrelevant information), and hint you how this model can change in different conditions. Fenris does not need source codes of analyzed application, but obviously does not keep the auditor from using them.
For many users, Fenris might be a new tool or tools, for others - just a command-line replacement or addition to strace, ltrace, gdb or similar applications (theres a brief list of other nice tools in doc/other.txt). And thats the idea - to build a tool that is simple, reusable, but also precise and smart. It is supposed to have advantages over other tools, but not to be an ultimate replacement or the final solution. Some users can just use very specific features, such as automated function fingerprinting, and use companion tools instead of the main program.