Free implementations software for linux

Fast MD5 Implementation in Java is a heavily optimized implementation of the MD5 hashing algorithm written in Java.
Fast MD5 Implementation in Java includes an optional native method for even greater speed improvements.
How Fast Is It?
Short answer:Much faster than any other Java implementation that I have tested and (surprisingly) even faster than the native, non-Java MD5 implementation on some systems.
Long answer:First of all, it is important to note that the term "fast" is used here in relative terms. The implementation of the MD5 message digest algorithm available on this page is written in Java and is fast compared with other implementations written in Java, both because it is heavily optimized by itself and because there is an optional native method that makes it even faster when the platform supports it. How it compares to a sensible implementation written in a language, such as C, that is compiled directly to machine code, is heavily dependent upon how good of a job the JIT compiler in your JVM does in compiling the code or whether you are able to use the optional native method.
Enhancements:
- Martin West contributed a bug fix and some code refactoring to make all targets work out of the box in the Ant build file. Previously, the "dist" target did not work if the "docs" directory was not present.

Suffix tree implementation library is a C library, an implementation of the suffix trees algorithm to store/retrieve key/data pairs.
The main advantages are a linear indexing time, little memory usage, and very fast retrieving.
It has been developped on FreeBSD/gcc but should be fairly portable.
The source code "testsfx.c" show an example of how to use the library both for inserting, retrieving, and deleting data. There arent many functions and comments should be enough to give you an idea of how to use the library. (read the header of the source file)
You should edit sfxdisk.h to suit your needs: you can change the alphabet size and the offset type. It should be OK to use "long long" 64 bits ints instead of long, in fact I tested it succesfully but havent gone to the point of filling more than 2 GB of data (needless to say you need a 64 bits filesystem).
Two "tools" come with the library (new with version 1.2): dumpsfx and loadsfx. dumpsfx is used to dump the database: dumpsfx [-s separator] if you want to output the result as readable text or dumpsfx < file.sfx > -h to output it for reloading with loadsfx.
dumpsfx outputs on stdout and loadsfx reads from stdin. loadsfx < suffix tree file to create > < dumped_file
Enhancements:
- removed an useless offset incrementation in STwritenode

Objective Modula-2 programming language is a hybrid between Smalltalk and Modula-2 based on the object model and runtime of Objective-C.
The design is an example how native Cocoa/GNUstep support can be added to static imperative programming languages without implementing a bridge.
Objective Modula-2s scope encompasses the design of the Objective Modula-2 programming language and the implementation of a compiler to implement it. The initial compiler will generate Objective-C source code.
Enhancements:
- This code is used to verify ideas and concepts which come up in the course of defining the language.
- It is in an early stage, incomplete and subject to frequent changes.

UMMF::UML::MetaMetaModel is an implementation of the UML Meta-Meta-Model (M3).

SYNOPSIS

use UMMF::UML::MetaMetaModel;
my $factory = UMMF::UML::MetaMetaModel->factory;
my $model = $factory->create(Model);
$factory->create(Class, name => Foo, namespace => $model);
...

This package implements a meta-meta-model (M3) for generating the UML metamodel (M2).

UMMF::UML::MetaMetaModel is not an implementation of the MOF; It is actually a subset of the 1.5 Meta-model, as described in UML Spec. 1.5., p.2-13, but with a flattened package namespace.

It is the "Backbone" for generating the meta-model.

The UML 1.5 Meta-model is described in UMMF::UML::MetaModel package, in the ad-hoc language imported by UMMF::UML::Import::MetaMetaModel.

This meta-model is then used to generate the Perl (or Java) code for the classes in UMMF::UML::MetaModel::*.

The same exporters and importers can be used to process M* layers.

Thus, one description of the meta-model can generate multiple implementations.

NNTP Client Lib is a Java implementation of RFC 997 for newsreaders, with support for authentication and logging.
NNTP Client Lib is meant to be used by newsreader implementations as some NNTP commands irrelevant for newsreaders are not implemented. Support for MIME or any other article encoding is not included.
If you want to quickly see nntpClientLib working, run NewsDemo . Note that this prints every message to System.err; you can edit NewsDemo.java and choose any other PrintStream.
KNOWN ISSUES:
- The POST and AUTHUSER commands havent been tested (yet).
TODO List:
- FIX NNTPConnectionImpl.disconnect() NullPointerException if host is unreachable.
- Add SSL support.
Enhancements:
- A new logging system and code cleanup.

libcontain library provides a large and growing number of fast and thread-safe containter objects written in C and C++.
The libcontain library now provides the following container types:
- a series of hash tables libcontain includes the hash table implementation from GNU glib and a hash implementation in C++ it inherited from the libhash library it originates from. This latter has been rendered thread-safe in the 0.2 release and implements a linear hashing algorithm. A single hash table implementation that will replace them both is on the drawing boards and is intended to be thread-safe and non-blocking.
- an array (vector) implementation
libcontain currently includes a non-blocking array implementation. However, this implementation presents a race-condition in concurrent calls to any of its writing functions if the array is in the process of being resized. There is currently no known non-blocking way to solve this race condition. Help is welcome in this area.
- a binomial tree
The binomial tree provided by libcontain does not provide any algorithmic logic in its implementation: it is a generic container that can be used as the basis for other container implementations, such as a heap or a map (as a matter of fact, the heap and the map are both based on this binomial tree)
- a heap
libcontain provides an automatically sorting heap implementation that (obviously) uses a heap sort to sort the elements it contains. Unfortunately, the heap implementation is not non-blocking (although bases on a non-blocking binomial tree implementation). It contains four levels of locks: a reader count and a write lock at the level of the nodes, and a reader count and a write lock at the level of the container. The locks are posed on the container for as short a time as possible so at to prevent the progress of the algorithm to block too long. If anyone knows of a non-blocking heap algorithm, input is more than welcome.
- a list
libcontain provides a non-blocking list implementation based on an algorithm by M.M. Micheal (also the inventor of Safe Memory Reclamation on which libmemory is based).
a map
The map implementation included in libcontain is based on the binomial tree implementation. Unlike some implementations based on binary trees, this implementation stores values in each node of the tree (not just the leaf nodes) and therefore allows a more memory-efficient way to store information than hashes and other map implementations. Also, the map implementation does not use a "less" function but uses a three-way comparison to compare keys (much like the helper function used by qsort). The implementation is almost (but not quite) non-blocking: for most intents and purposes, there are no real locks: read and write operations may be re-directed along a branch of the binomial tree if a node that they traverse is being deleted, but will not block for that. However, a remove operation will wait for another remove operation to finish if it traverses a node being removed.
- a queue
a non-blocking queue implementation is provided
- a stack
a non-blocking stack implementation is also provided
In future versions, the hash implementation will be replaced by a non-blocking one and the remaining problems with the existing containers will (hopefully) be solved. Help is also needed to write the architecture-dependant code for non-IA32 platforms such as Sparc.
Enhancements:
- The 0.2 release introduces number of important new features including a heap and a map, both based on a lock-free binomial tree. It also includes the required memory management to make the containters impervious to the ABA problem and thus truly thread-safe.

SPOPS::Manual::Configuration is a description of variables used in the SPOPS configuration process.

These are variables used in all SPOPS implementations. The name of the variable is the key used in the configuration hashref.

Here is a fairly minimal example of a configuration hashref:

1: my $spops = {
2: news => {
3: class => My::News,
4: isa => [ qw/ MyApp::Datasource SPOPS::DBI::Pg SPOPS::DBI / ],
5: rules_from => [ My::DiscoverField ],
6: code_class => [],
7: field_discover => yes,
8: base_table => news,
9: id_field => news_id,
10: increment_field => 1,
11: no_insert => [ news_id ],
12: no_update => [ news_id ],
13: },
14: };

VT6530 Terminal Emulator is a Java implementation of the proprietary terminal used with Tandem mainframes.
The Tandem VT6530 is a proprietary terminal used with their Non-Stop(TM) series of mainframes. These high-reliability machines are popular in the banking industry. If youve ever used an ATM to get cash, youve probably used a VT6530.
The terminal itself can operate in three different mode: conversation, block, and ANSI (VT100). Conversation mode is a simple scrolling text mode with the addition key buffering and text attributes. In block mode, text is displayed in a formated screen with special edit fields. ANSI mode is only used with OSS, Tandems UNIX wanabe operating layer.
Enhancements:
- Autotools support (./configure, make, make check, and make install).
- New telnet and ANSI terminal implementations.
- Linux, Cygwin, and HP NonStop (tandem OSS) builds are not quite running yet.