The 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. The goal of this package is to provide
reusable software components that address many of the portability and
maintenance 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.
sysconftool is a development utility that helps to install application
configuration files. sysconftool allows an existing application to be
upgraded without losing the older version's configuration settings.
sysconftool is a script that is used by applications to update configuration
files when a new version of the application is installed. sysconftool reads
the new application configuration files, reads any older versions of those
files that are already installed, then replaces the old versions with the
new ones, but preserving any custom changes contained in the old versions.
For more information on sysconftool, and why applications need it, see
the installed manual pages: sysconftool(1) and sysconftool(7). With most
versions of the man command: "man 1 sysconftool" and "man 7 sysconftool".
TIJmp is a memory profiler for java. TIJmp is made for java/6 and later, it
will not work on java/5 systems. If you need a profiler for java/5 or earlier
try the jmp profiler.
TIJmp is written to be fast and have a small footprint, both memory- and cpu-
wise. This means that the jvm will run at almost full speed, until you use
tijmp to find some information.
TIJmp uses C code to talk to the jvm and it uses swing to show the tables
of information. So tijmp is written in C (using jvmti and jni) and Java.
TIJmp runs in the same jvm as the program being profiled. This means that it
can easily get access to all things jvmti/jni has to offer.
TIJmp is distributed under the General Public License, GPL.
Usage:
java -Dtijmp.jar=%JAVAJARDIR%/tijmp.jar -agentlib:tijmp <your-class>
TkCVS is a Tcl/Tk-based graphical interface to the CVS, and Subversion
configuration management systems. It will also help with RCS. The user
interface is consistent across Unix/Linux, Windows, and MacOS X. TkDiff
is included for browsing and merging your changes.
It shows the status of the files in the current working directory, and
has tools for tagging, merging, importing, exporting, checking in/out,
and other user operations. TkCVS also aids in browsing the repository.
For Subversion, the repository tree is browsed like an ordinary file
tree. For CVS, the CVSROOT/modules file is read. TkCVS extends CVS with
a method to produce a "user friendly" listing of modules by using special
comments in the CVSROOT/modules file.
xwpe is a X-window programming environment designed for UNIX systems.
It is similar to 'Borland C++' MS-DOS programming IDE environment.
xwpe supports many compilers, linkers, and debuggers, so you are not tied to
any particular set of tools. There is both a curses and X11 interface
(the later with mouse support).
Errors that occur while compiling and linking a program can be examined in
the sources -- the cursor will jump to the corresponding line in the
source file. Programs composed of more than one source file, can be
managed with the project-option. Your program may be run and debugged from
within xwpe -- allowing the user to set breakpoints and watch variables.
Note: there are both English and German language version of the man pages,
and help files. The German language version will be installed if
"GERMAN_LANG" is set during ``make install'' of the port.
SWIG is a software development tool that connects programs written in C and C++
with a variety of high-level programming languages. SWIG is used with different
types of target languages including common scripting languages such as
Javascript, Perl, PHP, Python, Tcl and Ruby. The list of supported languages
also includes non-scripting languages such as C#, Common Lisp (CLISP, Allegro
CL, CFFI, UFFI), D, Go language, Java, Lua, Modula-3, OCAML, Octave and R. Also
several interpreted and compiled Scheme implementations (Guile, MzScheme/Racket,
Chicken) are supported. SWIG is most commonly used to create high-level
interpreted or compiled programming environments, user interfaces, and as a tool
for testing and prototyping C/C++ software. SWIG is typically used to parse
C/C++ interfaces and generate the 'glue code' required for the above target
languages to call into the C/C++ code. SWIG can also export its parse tree in
the form of XML and Lisp s-expressions.
libasyncns is a C library for Linux/Unix for executing name service queries
asynchronously. It is an asynchronous wrapper around getaddrinfo(3),
getnameinfo(3), res_query(3) and res_search(3) from libc and libresolv.
In contrast to GNU's asynchronous name resolving API getaddrinfo_a(),
libasyncns does not make use of UNIX signals for reporting completion of name
queries. Instead, the API exports a standard UNIX file descriptor which may be
integerated cleanly into custom main loops.
In contrast to asynchronous DNS resolving libraries like libdenise, skadns,
adns, libasyncns is just an asynchronous wrapper around the libc's synchronous
getaddrinfo() API, which has the advantage of allowing name resolution using
techniques like Multicast DNS, LDAP or NIS using standard libc NSS (Name
Service Switch) modules. libasyncns is compatible with IPv6 if the underlying
libc is.
libasyncns is very tiny, consisting of just one header and one source file. It
has no dependencies besides libc.
libasyncns is a C library for Linux/Unix for executing name service queries
asynchronously. It is an asynchronous wrapper around getaddrinfo(3),
getnameinfo(3), res_query(3) and res_search(3) from libc and libresolv.
In contrast to GNU's asynchronous name resolving API getaddrinfo_a(),
libasyncns does not make use of UNIX signals for reporting completion of name
queries. Instead, the API exports a standard UNIX file descriptor which may be
integerated cleanly into custom main loops.
In contrast to asynchronous DNS resolving libraries like libdenise, skadns,
adns, libasyncns is just an asynchronous wrapper around the libc's synchronous
getaddrinfo() API, which has the advantage of allowing name resolution using
techniques like Multicast DNS, LDAP or NIS using standard libc NSS (Name
Service Switch) modules. libasyncns is compatible with IPv6 if the underlying
libc is.
libasyncns is very tiny, consisting of just one header and one source file. It
has no dependencies besides libc.
IRONSIDES is an authoritative DNS server that is provably invulnerable to
many of the problems that plague other servers. It achieves this property
through the use of formal methods in its design, in particular the language
Ada and the SPARK formal methods tool set. Code validated in this way is
provably exception-free, contains no data flow errors, and terminates only
in the ways that its programmers explicitly say that it can. These are very
desirable properties from a computer security perspective.
IRONSIDES is not a complete implementation of DNS. In particular, it does
not support zone transfers or recursive queries. It does, however, support
a sufficient number of DNS records to be useful as an authoritative DNS
server for an enterprise.
Unbound is designed as a set of modular components, so that also
DNSSEC (secure DNS) validation and stub-resolvers (that do not run as
a server, but are linked into an application) are easily possible.
Goals:
* A validating recursive DNS resolver.
* Code diversity in the DNS resolver monoculture.
* Drop-in replacement for BIND apart from config.
* DNSSEC support.
* Fully RFC compliant.
* High performance, even with validation enabled.
* Used as: stub resolver, full caching name server, resolver library.
* Elegant design of validator, resolver, cache modules.
o provide the ability to pick and choose modules.
* Robust.
* In C, open source: The BSD license.
* Smallest as possible component that does the job.
* Stub-zones can be configured (local data or AS112 zones).
Non-goals:
* An authoritative name server.
* Too many Features.