Free scope 2 software for linux

IComplete is a command line program, which lists possible completions for a certain position in a source code, reusing the excellent Exuberant-ctags program.
Currently it only works with C/C++ source code, and partly with Java and probably C# sources.
IComplete is meant to be editor-independent, so you can use it as an API browser for the command line, no matter which editor you prefer.
However, I provide an integration plugin for Vim, which helps speeding up your coding sessions, especially with new APIs.
Main features:
- Automatic generation of a tags file for the current source file by building a tree of included files.
- Listing members (also inherited ones) of a class
- For QString s; s. only non-static members are suggested, for QString:: only static ones.
- Listing all function signatures of overloading methods
- Recognizes return values of methods.
- QWidget w; w.rect().topLeft(). // List completions for a QPoint
- Uses the scope of the cursor position
- Recognizes, if you are inside a method-definition and completes also private or protected variables for this class. For a global scope, only public members are suggested.
- Works in both console and graphical vim
- Uses a cache system for increased speed.
Installation:
./configure
make
su
make install
Enhancements:
- The Vim plugin has finally been converted to reuse the new omnifunc.
- Placeholder support has been added.

Smolt is a basic hardware profiler. Smolt is intended to be a profiler to get automated information from users. This should make it easier for our developers to do what they need to do.
How can you help? Well look at the code and make it better. Its still in the very early stages but has good potential.
Legacy Clients
If youre interested in running smolt on FC-3, 4 or 5 please see the Clients page.
Scope
Smolt has a very small scope targeting just Fedora and Fedora based OSs. For more information please see Scope.
Use
Fedora Core 6 and newer (rawhide) can simply "yum install smolt" for the client. To send your profile simply type "smoltSendProfile". Firstboot functionality is also available by installing smolt-firstboot.
Main features:
- Public stats server
- First Boot integration
- Statistical information (more to come)

GDHCPD project is an easy to use GTK+ frontend for ISC DHCPD.
Main features:
- dynamic scopes
- hosts
- ranges
- settings

OpenMONI is a semi-transparent on-desktop system monitor for OpenBSD. It does not require anything additional on a standard OpenBSD installation (any port or package).
It is fully scriptable, and has a simple, easy-to-understand Lisp-like scripting language (OML). You can fully control OpenMONIs behaviour and style from OML. OpenMONI comes with a pack of OML scripts ready to use.
Main features:
- Weather plugin - far from OK. Though works in most cases. (disabled)
- Centralized depend, subdepend, recurse and nothing targets.
- README.TXT
- Centralized definitions for graphics context members. (in omls/x.oml)
- Less compilcated desc_table implementation.
- MEMLEAK fixed : destroying fifo structure doesnt leak memory any more.
- OpenMONI survives the absence of init.oml - using default init values.
- Transparency & round corner radius setup via init.oml.
- BUGFIX : now oml requires the descriptor table. It wasnt required if
- it had been compiled only with MATHSUPPORT - in most cases at least FILESUPPORT
- is compiled in.
- Simple experimental net IO support added.
- 1024 Kb is written now as 1Mb in the netscope label.
- Scope oml doesnt abort if the net interface could not be openend.
- At least the background calculation supports other than 24 bit depth.
- BUGFIX : Some WM doesnt set up a background image for the RootWindow => we cant grab it.
- Standalone oml interpreter can use the netload support.
- BUGFIX : unsupported function now returns NIL if nessecarry.
- execute keyword introduces.
- several MEMLEAKS fixed.
- If charging level is less than x%, the info is printed in warningcolour.
- Destroyed values go into the cache.
- random keyword.
Enhancements:
- Many bugs have been fixed.
- Several memory leaks have been plugged.
- Multiple color depth support has been added.
- New options appeared in init.oml, like "hide on taskbar", "allow wm to decorate window", and others.
- Arithmetic operators are now capable of handling several operands.

OpenSign is a java applet for signing text in a webbrowser using PKCS-12 key-files or keys accessible through Microsoft CryptoAPI CSPs in a Win32 environment.
The applet is based on code kindly provided by IT-Practice and everyone is encouraged to submit code, suggestions or bugfixes through the mailinglists. OpenSign is a FREE software and it is licensed under the GNU LGPL licence.
OpenSign is a client side applet which generates xmldsig signatures. It is NOT in the scope of this project to develop a serverside validation service for the signatures.
OpenSign also has an option to work as a logon in the application layer. In this case OpenSign is referred as OpenLogon.
Enhancements:
- This release enables access to certificates accessed through CryptoAPI on Microsoft Vista when running in protected mode.
- It also introduces certificates available through the Sun Java control panel as a new keystore.

AtExit is a Perl module that can perform exit processing for a program or object.

SYNOPSIS

use AtExit;

sub cleanup {
my @args = @_;
print "cleanup() executing: args = @argsn";
}

## Register subroutines to be called when this program exits

$_ = atexit(&cleanup, "This call was registered first");
print "first call to atexit() returned $_n";

$_ = atexit("cleanup", "This call was registered second");
print "second call to atexit() returned $_n";

$_ = atexit("cleanup", "This call shouldve been unregistered by rmexit");
rmexit($_) or warn "couldnt unregister exit-sub $_!";

if (@ARGV == 0) {
## Register subroutines to be called when this lexical scope is exited
my $scope1 = AtExit->new( &cleanup, "Scope 1, Callback 1" );
{
## Do the same for this nested scope
my $scope2 = AtExit->new;
$_ = $scope2->atexit( &cleanup, "Scope 2, Callback 1" );
$scope1->atexit( &cleanup, "Scope 1, Callback 2");
$scope2->atexit( &cleanup, "Scope 2, Callback 2" );
$scope2->rmexit($_) or warn "couldnt unregister exit-sub $_!";

print "*** Leaving Scope 2 ***n";
}
print "*** Finished Scope 2 ***n";
print "*** Leaving Scope 1 ***n";
}
print "*** Finished Scope 1 ***n" if (@ARGV == 0);

END {
print "*** Now performing program-exit processing ***n";
}

The AtExit module provides ANSI-C style exit processing modeled after the atexit function in the standard C library (see atexit(3C)). Various exit processing routines may be registered by calling atexit and passing it the desired subroutine along with any desired arguments. Then, at program-exit time, the subroutines registered with atexit are invoked with their given arguments in the reverse order of registration (last one registered is invoked first). Registering the same subroutine more than once will cause that subroutine to be invoked once for each registration.

An AtExit object can be created in any scope. When invoked as a function, atexit registers callbacks to be executed at program-exit time. But when invoked as an object-method (using the $object->method_name syntax), callbacks registered with an AtExit object are executed at object-destruction time! The rules for order of execution of the registered subroutines are the same for objects during object-destruction, as for the program during program-termination.

The atexit function/method should be passed a subroutine name or reference, optionally followed by the list of arguments with which to invoke it at program/object exit time. Anonymous subroutine references passed to atexit act as "closures" (which are described in perlref). If a subroutine name is specified (as opposed to a subroutine reference) then, unless the subroutine name has an explicit package prefix, it is assumed to be the name of a subroutine in the callers current package. A reference to the specified subroutine is obtained, and, if invocation arguments were specified, it is "wrapped up" in a closure which invokes the subroutine with the specified arguments. The resulting subroutine reference is added to the front of the list of exit-handling subroutines for the program (atexit) or the AtExit object ($exitObject->atexit) and the reference is then returned to the caller (just in case you might want to unregister it later using rmexit. If the given subroutine could not be registered, then the value zero is returned.

The rmexit function/method should be passed one or more subroutine references, each of which was returned by a previous call to atexit. For each argument given, rmexit will look in the list of exit-handling subroutines for the program (rmexit) or the AtExit object ($exitObject->rmexit) and remove the first matching entry from the list. If no arguments are given, then all program or object exit-handlers are unregistered! The value returned will be the number of subroutines that were successfully unregistered.

At object destruction time, the DESTROY{} subroutine in the AtExit module iterates over the subroutine references in the AtExit object and invokes each one in turn (each subroutine is removed from the front of the queue immediately before it is invoked). At program-exit time, the END{} block in the AtExit module iterates over the subroutines in the array returned by the exit_subs method and invokes each one in turn (each subroutine is removed from the front of the queue immediately before it is invoked). Note that in both cases (program-exit, and object-destruction) the subroutines in this queue are invoked in first-to-last order (the reverse order in which they were registered with atexit).

OSCache is a high performance J2EE caching solution that can cache portions of JSP pages, entire HTTP responses (including dynamically generated images), and arbitrary Java objects.
OpenSymphony Cache can provide your J2EE application with huge performance gains and graceful error tolerance (e.g., in the event of a DB failure, cached content is served).
Fast in-memory caching
OSCache allows you to execute dynamic content periodically (eg every 30 minutes) rather than every request and store the result in memory. Each further request is served directly from the memory cache, resulting in dramatic speed increases.
The cache is keyed programmatically. This means you can calculate a cache key that works for your situation. For example an ecommerce site might use product ID as keys, or content site might use an article date and article ID combination.
The cache is stored in standard scopes that any JSP programmer is familiar with (application or session). The session scope allows you to have different cached content per user. This is one unlike any other caching system weve ever seen.
Persistent on-disk caching
OSCache can also write the cache to disk. This provides caching across server restarts, and caching of datasets that do not fit into memory. Caching can be configured to use memory or file caching, or a combination of both.
If you want to persist the cache to somewhere other than disk, you can plug in a custom PersistenceListener. This allows you to persist the cache to anywhere (for example to a database via JDBC or to LDAP via JNDI).
When using both disk caching and memory caching. It is possible to limit the cache size to avoid using too much memory but let disk cache unlimited, resulting in browser style complementary disk cache. When cached objects are removed from memory, they are still on disk. If the item is needed again and it is not expired the cache file will be used. This also gives fault tolerance if the server crashes.
Persistence can also be switched to overflow mode using the property oscache.persistence.overflow.only. This changes the default behavior (of persisting every cache entry when there is a listener) to only persist when the memory cache capacity has been reached.
Excellent Performance
Written with performance in mind.
Mulitple cache requests can be handled concurrently.
Only one requesting thread needs to update an expired cache entry even if multiple threads are requesting it simultaneously. Other threads can be configured to either receive the recently-expired object, or block until the cached object is updated. Similarly, when a new entry is being added to the cache, other threads requesting that entry will block until it is ready rather than run off and race to build the same object. In a high load environment this can provide enormous performance benefits.
Automatically takes advantage of JRE 1.4 or higher if available.
Clustering support
OSCache can easily be configured to cluster across multiple boxes. This provides both scalability and failover support without any changes required in your caching code.
Flexible Caching System
OSCache allows you to cache portions of JSP pages, arbitrary Java objects, and even entire servlet responses.
Cache capacity can be set allowing you to limit the number of cached objects.
Multiple caching algorithms are supported such as LRU (Least Recently Used), FIFO (First In First Out), or unlimited. It is also possible to plug in your own custom algorithm.
You are given a huge amount of control over the way cached objects expire. Objects can be cached indefinitely, expired once they reach a certain age, or expired based on a cron expression. Programmatic flushing is also possible, and if that is still not enough pluggable RefreshPolicies allow custom refresh strategies.
Cached objects can be grouped together however you like, allowing for powerful management of cached data. This is an extremely useful feature that is far more powerful than what other caching solutions typically offer (such as the flushing of cache keys that match a particular pattern).
Fully event driven! OSCache fires events for various happenings under the hood such as cache entry events (adding, updating, flushing and removing) and cache accesses (hit, stale hit and miss). It is easy to add your own event handlers.
Multiple caches can be created, each with their own unique configuration.
Simple JSP Tag Library
The tag library to perform and control the caching is very simple. See the Tag Reference for more information.
Caching Filter
A Servlet 2.3 Filter allows for caching of entire pages and generated binary files (like dynamically created images or PDF files).
Comprehensive API
For the ultimate control, OSCache can be used through its straightforward API. You can instantiate, configure and control multiple caches programmatically. It would be possible for example to create one small in-memory cache that held currency conversion rates and was updated daily at 2am, while another cache could be purely disk based and used for holding dynamically created images.
Exception Handling
OSCache provides a way for your site to gracefully tolerate errors. This is not error prevention, rather if an error occurs it should not stop your site from functioning. For example if your database goes down, normally your product descriptions will not be browsable. Using OSCache you can cache those descriptions so you can still browse them.
Cache Flushing
Flushing of caches can be controlled via JSP Tags, so these functions can easily be built into your administration interface.
There is programmatic control over what caches are flushed (eg all caches or just a particular scope).
Cached objects can be expired in a number of ways. Objects can be told to expire once they reach a certain age, or, through the use of cron expressions, on particular dates and/or times (eg it is trivial to make an object expire every weekday at 3am). If this is not enough, you can expire objects programmatically as required, or plug in your own custom RefreshPolicy class that can dynamically decide when an object should be flushed.
Entire groups of objects can be easily flushed from the cache. For example suppose you were caching product data as well as entire pages of your website. When a product was updated, you could flush not just the product object but also all the pages that contain information about that product. No more waiting for the cached objects to expire before the updated content shows up on your site!
Portable caching
Pure Java, this means it is platform independent.
OSCache is compliant with Servlet 2.3 and JSP 1.2 standards, which means it should work in the latest generation of servlet containers and application servers.
i18n Aware
The caching is i18n aware and supports all encodings.
Solid Reputation
Thousands of downloads, hundreds of users on the mailing list.
Comprehensive JUnit test suite that covers every aspect of OSCache, including a web stress test and various concurrent cache access scenarios. To back this up, the kind folks at Cortex have supplied us with a Clover license to provide detailed code coverage analysis of our unit tests.
We have solid issue tracking using JIRA to keep track of any feature requests, bug reports and development progress. JIRA is provided courtesy of Atlassian.
Enhancements:
- CRON expressions to expire content at specific dates and/or times.
- Pluggable EntryRefreshPolicy.
- Reduced memory consumption.
- Faster disk persistence.
- DiskPersistenceListener deadlocks are avoided if a process has no rights to delete the cache file.
- There is a new JSP tag _addgroups_, and an interface to get a list of the cache event listeners.
- The commons collection dependency has been removed.
- Java 1.3 support has been dropped.