Free implementations definition 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.

Procinfo NG is a ground-up rewrite of the procinfo program. Procinfo NGs goal is to make the code more readable (and reusable) and to restore broken functionality of the original program.
The original program was written for Linux 1.0, and updated through 2.2. This version is for 2.6.
Enhancements:
- Updates were made to match what some Linux distributions have done to procinfo-18.
- Support for MSI and XEN interrupts were added.
- Some non-x86 architectures are handled.
- Assorted bugs and 80-character console nonsense were fixed.

XML::NodeFilter is a generic XML::NodeFilter Class.

SYNOPSIS

use XML::NodeFilter;

my $filter = XML::NodeFilter->new();

$your_iterator->set_filter( $filter );

"Filters are objects that know how to "filter out" nodes. If a NodeIterator or a TreeWalker is given a NodeFilter, it applies the filter before it returns the next node. If the filter says to accept the node, the traversal logic returns it; otherwise, traversal looks for the next node and pretends that the node was rejected was not there."

This definition is given by the DOM Traversal and Range Specification. It explains pretty well, what this class is for: A XML::NodeFilter will recieve a node from a traversal object, such as XML::LibXML::Iterator is one and tells if the given node should be returned to the caller or not.
Although I refere only to XML::LibXML here, XML::NodeFilter is implemented more open, so it can be used with other DOM implementations as well.

The Spec And The Implementation

The DOM Traversal and Range Specification just defines the contstants and accept_node() for a node filter. The XML::NodeFilter implementation also adds the what_to_show() function to the class definition, since I think that it is a filters job to decide which node-types should be shown and which not.

Also XML::NodeFilter adds two constants which are not part of the specification. The first one is FILTER_DECLINED. It tells the traversal logic, that it should apply another filter in order to decide if the node should be visible or not. While the spec only defines the traversal logic to have either one or no filter applied, it showed that it leads to cleaner code if more filter could be used in conjunktion. If a traversal logic finds a single filter that returns FILTER_DECLINED, it should be handled as a synonym of FILTER_ACCEPT. While FILTER_ACCEPT is finite and would cause all other not to be executed, FILTER_DECLINED gives one more flexibility.

The second extension of the specification is the SHOW_NONE symbol. It was added for operational completeness, so one can explicitly switch the node type filter off (means all node types are rejected). This will cause the two calls of what_to_show have a different result:

$filter->what_to_show( undef ); # will set SHOW_ALL
$filter->what_to_show( SHOW_NONE ); # will not set SHOW_ALL

Infact SHOW_NONE is a NULL flag, that means it can be added to any list of flags without altering it.

$filter->what_to_show( SHOW_ELEMENT | SHOW_TEXT | SHOW_NONE );

is therefore identical to

$filter->what_to_show( SHOW_ELEMENT | SHOW_TEXT );

SHOW_NONE is espacially usefull to avoid numerically or even more ugly unintialized values while building such flag lists dynamically.

Template Numerical Toolkit (TNT) is a collection of interfaces and reference implementations of numerical objects useful for scientific computing in C++.
The toolkit defines interfaces for basic data structures, such as multidimensional arrays and sparse matrices, commonly used in numerical applications. Template Numerical Toolkits goal is to provide reusable software components that address many of the portability and maintennace problems with C++ codes.
TNT provides a distinction between interfaces and implementations of TNT components. For example, there is a TNT interface for two-dimensional arrays which describes how individual elements are accessed and how certain information, such as the array dimensions, can be used in algorithms; however, there can be several implementations of such an interface: one that uses expression templates, or one that uses BLAS kernels, or another that is instrumented to provide debugging information.
By specifying only the interface, applications codes may utilize such algorithms, while giving library developers the greatest flexibility in employing optimization or portability strategies.
TNT Data Structures
- C-style arrays
- Fortran-style arrays
- Sparse Matrices
- Vector/Matrix
TNT utilities
- array I/O
- math routines (hypot(), sign(), etc.)
- Stopwatch class for timing measurements
Libraries that utilize TNT
- JAMA: a linear algebra library with QR, SVD, Cholesky and Eigenvector solvers.
- old (pre 1.0) TNT routines for LU, QR, and Eigenvalue problems

MLton is a whole-program optimizing Standard ML compiler. MLton project generates standalone executables with excellent runtime performance, supports the full SML 97 language, and has a complete basis library.
It also has a fast C FFI, source-level time and allocation profiling, and many useful libraries.
Supports the full SML 97 language as given in The Definition of Standard ML (Revised).
- If there is a program that is valid according to The Definition that is rejected by MLton, or a program that is invalid according to the Definition that is accepted by MLton, it is a bug. For a list of known bugs, see UnresolvedBugs.
A complete implementation of the Basis Library.
- MLtons implementation matches latest Basis Library specification, and includes a complete implementation of all the required modules, as well as many of the optional modules.
Generates standalone executables.
- No additional code or libraries are necessary in order to run an executable, except for the standard shared libraries. MLton can also generate statically linked executables.
Compiles large programs.
- MLton is sufficiently efficient and robust that it can compile large programs, including itself (over 140K lines). The distributed version of MLton was compiled by MLton.
Support for large amounts of memory (up to 4G).
Array lengths up to 231 - 1, the largest possible twos-complement 32 bit integer.
Support for large files, using 64-bit file positions.
Enhancements:
- MLton is now released under the BSD license, not the GPL.
- There is substantially improved documentation based on the MLton wiki. x86/MinGW and HPPA/Linux are supported.
- There are improvements to the FFI, ML Basis annotations, and new libraries: the ckit and SML/NJ library.

GMediaRender is a UPnP media renderer for POSIX-compliant systems, such as GNU/Linux or UNIX. It implements the server component that provides UPnP controllers a means to render media content (audio, video and images) from a UPnP media server.

MediaServer / AV

UPnP A/V is a three-tier system, consisting of Servers, Renderers and Controllers. With an A/V UPnP controller you can instruct a UPnP A/V Renderer (such as GMediaRender) to play multimedia content (pictures, music tracks, radio broadcasts, movies, ..) available from a UPnP A/V Server.

UPnP A/V components are available both as stand-alone consumer electronics devices, as well as are software-only implementations. Listed below are some software implementations which run on GNU/Linux.

Splint is a tool for statically checking C programs for security vulnerabilities and programming mistakes.
Splint does many of the traditional lint checks including unused declarations, type inconsistencies, use before definition, unreachable code, ignored return values, execution paths with no return, likely infinite loops, and fall through cases.
More powerful checks are made possible by additional information given in source code annotations. Annotations are stylized comments that document assumptions about functions, variables, parameters and types.
In addition to the checks specifically enabled by annotations, many of the traditional lint checks are improved by exploiting this additional information.
As more effort is put into annotating programs, better checking results. A representational effort-benefit curve for using Splint is shown in Figure 1.
Splint is designed to be flexible and allow programmers to select appropriate points on the effort-benefit curve for particular projects.
As different checks are turned on and more information is given in code annotations the number of bugs that can be detected increases dramatically.
Problems detected by Splint include:
- Dereferencing a possibly null pointer
- Using possibly undefined storage or returning storage that is not properly defined
- Type mismatches, with greater precision and flexibility than provided by C compilers
- Violations of information hiding
- Memory management errors including uses of dangling references and memory leaks
- Dangerous aliasing
- Modifications and global variable uses that are inconsistent with specified interfaces
- Problematic control flow such as likely infinite loops, fall through cases or incomplete switches, and suspicious statements
- Buffer overflow vulnerabilities
- Dangerous macro implementations or invocations
- Violations of customized naming conventions.

PolyGen project is a program for generating random sentences according to a grammar definition, that is following custom syntactical and lexical rules.

Formally, it is an interpreter of a language itself designed to define languages, where to interpret means executing a source program in real time and eventually outputting its result. Here, a source program is a grammar definition.

The execution consists of the exploration of such grammar by selecting a random path, and the result is the sentence built on the way.