Free con software for linux

Cons is a Software Construction System.

Cons is a system for constructing, primarily, software, but is quite different from previous software construction systems. Cons was designed from the ground up to deal easily with the construction of software spread over multiple source directories. Cons makes it easy to create build scripts that are simple, understandable and maintainable. Cons ensures that complex software is easily and accurately reproducible.

Cons uses a number of techniques to accomplish all of this. Construction scripts are just Perl scripts, making them both easy to comprehend and very flexible. Global scoping of variables is replaced with an import/export mechanism for sharing information between scripts, significantly improving the readability and maintainability of each script.

Construction environments are introduced: these are Perl objects that capture the information required for controlling the build process. Multiple environments are used when different semantics are required for generating products in the build tree. Cons implements automatic dependency analysis and uses this to globally sequence the entire build. Variant builds are easily produced from a single source tree. Intelligent build subsetting is possible, when working on localized changes. Overrides can be setup to easily override build instructions without modifying any scripts. MD5 cryptographic signatures are associated with derived files, and are used to accurately determine whether a given file needs to be rebuilt.

While offering all of the above, and more, Cons remains simple and easy to use. This will, hopefully, become clear as you read the remainder of this document.

Why Cons? Why not Make?

Cons is a make replacement. In the following paragraphs, we look at a few of the undesirable characteristics of make--and typical build environments based on make--that motivated the development of Cons.

Build complexity

Traditional make-based systems of any size tend to become quite complex. The original make utility and its derivatives have contributed to this tendency in a number of ways. Make is not good at dealing with systems that are spread over multiple directories. Various work-arounds are used to overcome this difficulty; the usual choice is for make to invoke itself recursively for each sub-directory of a build. This leads to complicated code, in which it is often unclear how a variable is set, or what effect the setting of a variable will have on the build as a whole. The make scripting language has gradually been extended to provide more possibilities, but these have largely served to clutter an already overextended language. Often, builds are done in multiple passes in order to provide appropriate products from one directory to another directory. This represents a further increase in build complexity.

Build reproducibility

The bane of all makes has always been the correct handling of dependencies. Most often, an attempt is made to do a reasonable job of dependencies within a single directory, but no serious attempt is made to do the job between directories. Even when dependencies are working correctly, makes reliance on a simple time stamp comparison to determine whether a file is out of date with respect to its dependents is not, in general, adequate for determining when a file should be rederived. If an external library, for example, is rebuilt and then ``snapped into place, the timestamps on its newly created files may well be earlier than the last local build, since it was built before it became visible.

Variant builds

Make provides only limited facilities for handling variant builds. With the proliferation of hardware platforms and the need for debuggable vs. optimized code, the ability to easily create these variants is essential. More importantly, if variants are created, it is important to either be able to separate the variants or to be able to reproduce the original or variant at will. With make it is very difficult to separate the builds into multiple build directories, separate from the source. And if this technique isnt used, its also virtually impossible to guarantee at any given time which variant is present in the tree, without resorting to a complete rebuild.

Repositories

Make provides only limited support for building software from code that exists in a central repository directory structure. The VPATH feature of GNU make (and some other make implementations) is intended to provide this, but doesnt work as expected: it changes the path of target file to the VPATH name too early in its analysis, and therefore searches for all dependencies in the VPATH directory. To ensure correct development builds, it is important to be able to create a file in a local build directory and have any files in a code repository (a VPATH directory, in make terms) that depend on the local file get rebuilt properly. This isnt possible with VPATH, without coding a lot of complex repository knowledge directly into the makefiles.

con:cern project is a workflow engine based on an extended case handling approach.
A process is described as a set of activities with pre- and postconditions. An activity is executed when its preconditions are met. It manipulates the process item, thereby creating postconditions. The process flow is determined at runtime. This approach is superior to the conventional process flow approach, especially if high flexibility and modularity are required.
Main features:
- complex process with exceptions and special cases
- execution sequence is dependent on multiple factors
- possibility of manual intervention of process flow
- content-based dependence amongst activities
- strong requirements to modularity
- strong requirements to flexibility
- loose process coupling
Interestingly, processes often turn out to be more complex than initially anticipated. con:cerns flexibility allows to restrict yourself to implementing the normal process flow. Special cases and exceptions can be manually dealt with at run-time, or can be gradually retrofitted.
When you can break systems down to pre conditions, post conditions, transfer functions, and the algorithms that implement them you can go a long way towards reliable systems and specs.
Enhancements:
- bugfix escalation timeout
- bugfix reenlistment after escalation

Readonly is a Perl module that offers the facility for creating read-only scalars, arrays, hashes.

SYNOPSIS

use Readonly;

# Read-only scalar
Readonly::Scalar $sca => $initial_value;
Readonly::Scalar my $sca => $initial_value;

# Read-only array
Readonly::Array @arr => @values;
Readonly::Array my @arr => @values;

# Read-only hash
Readonly::Hash %has => (key => value, key => value, ...);
Readonly::Hash my %has => (key => value, key => value, ...);
# or:
Readonly::Hash %has => {key => value, key => value, ...};

# You can use the read-only variables like any regular variables:
print $sca;
$something = $sca + $arr[2];
next if $has{$some_key};

# But if you try to modify a value, your program will die:
$sca = 7;
push @arr, seven;
delete $has{key};
# The error message is "Modification of a read-only value
attempted"

# Alternate form (Perl 5.8 and later)
Readonly $sca => $initial_value;
Readonly my $sca => $initial_value;
Readonly @arr => @values;
Readonly my @arr => @values;
Readonly %has => (key => value, key => value, ...);
Readonly my %has => (key => value, key => value, ...);
# Alternate form (for Perls earlier than v5.8)
Readonly $sca => $initial_value;
Readonly my $sca => $initial_value;
Readonly @arr => @values;
Readonly my @arr => @values;
Readonly %has => (key => value, key => value, ...);
Readonly my %has => (key => value, key => value, ...);

This is a facility for creating non-modifiable variables. This is useful for configuration files, headers, etc. It can also be useful as a development and debugging tool, for catching updates to variables that should not be changed.
If any of the values you pass to Scalar, Array, or Hash are references, then those functions recurse over the data structures, marking everything as Readonly. Usually, this is what you want: the entire structure nonmodifiable. If you want only the top level to be Readonly, use the alternate Scalar1, Array1 and Hash1 functions.

Please note that most users of Readonly will also want to install a companion module Readonly::XS. See the "CONS" section below for more details.

This package provides a complete http client library. It currently implements most of the relevant parts of the HTTP/1.0 and HTTP/1.1 protocols, including the request methods HEAD, GET, POST and PUT, and automatic handling of authorization, redirection requests, and cookies.

Furthermore the included Codecs class contains coders and decoders for the base64, quoted-printable, URL-encoding, chunked and the multipart/form-data encodings. The whole thing is free, and licenced under the GNU Lesser General Public License (LGPL) (note that this is not the same as the GPL).

Following are the kits and documentation for the HTTPClient Version 0.3-3. If you have any problems, bugs, suggestions, comments, etc. see the info on debugging and reporting problems. An older version of these pages are also available in Japanese, thanks to the kindly efforts of Yuji Kumasaka.

Using the HTTPClient should be quite simple. First add the import statement import HTTPClient.*; to your file(s). Next you create an instance of HTTPConnection (youll need one for every server you wish to talk to). Requests can then be sent using one of the methods Head(), Get(), Post(), etc in HTTPConnection.

These methods all return an instance of HTTPResponse which has methods for accessing the response headers (getHeader(), getHeaderAsInt(), etc), various response info (getStatusCode(), getReasonLine(), etc), the response data (getData(), getText(), and getInputStream()) and any trailers that might have been sent (getTrailer(), getTrailerAsInt(), etc). Following are some examples to get started.
To retrieve files from the URL "http://www.myaddr.net/my/file" you can use something like the following:
try
{
HTTPConnection con = new HTTPConnection("www.myaddr.net");
HTTPResponse rsp = con.Get("/my/file");
if (rsp.getStatusCode() >= 300)
{
System.err.println("Received Error: "+rsp.getReasonLine());
System.err.println(rsp.getText());
}
else
data = rsp.getData();

rsp = con.Get("/another_file");
if (rsp.getStatusCode() >= 300)
{
System.err.println("Received Error: "+rsp.getReasonLine());
System.err.println(rsp.getText());
}
else
other_data = rsp.getData();
}
catch (IOException ioe)
{
System.err.println(ioe.toString());
}
catch (ParseException pe)
{
System.err.println("Error parsing Content-Type: " + pe.toString());
}
catch (ModuleException me)
{
System.err.println("Error handling request: " + me.getMessage());
}

This will get the files "/my/file" and "/another_file" and put their contents into byte[]s accessible via getData(). Note that you need to only create a new HTTPConnection when sending a request to a new server (different protocol, host or port); although you may create a new HTTPConnection for every request to the same server this not recommended, as various information about the server is cached after the first request (to optimize subsequent requests) and persistent connections are used whenever possible (see also Advanced Info).

To POST form data from an applet back to your server you could use something like this (assuming you have two fields called name and e-mail, whose contents are stored in the variables name and email):
try
{
NVPair form_data[] = new NVPair[2];
form_data[0] = new NVPair("name", name);
form_data[1] = new NVPair("e-mail", email);

// note the convenience constructor for applets
HTTPConnection con = new HTTPConnection(this);
HTTPResponse rsp = con.Post("/cgi-bin/my_script", form_data);
if (rsp.getStatusCode() >= 300)
{
System.err.println("Received Error: "+rsp.getReasonLine());
System.err.println(rsp.getText());
}
else
stream = rsp.getInputStream();
}
catch (IOException ioe)
{
System.err.println(ioe.toString());
}
catch (ModuleException me)
{
System.err.println("Error handling request: " + me.getMessage());
}

Here the response data is read at leisure via an InputStream instead of all at once into a byte[].

As another example, if you want to upload a document to a URL (and the server supports http PUT) you could do something like the following:
try
{
URL url = new URL("http://www.mydomain.us/test/my_file");

HTTPConnection con = new HTTPConnection(url);
HTTPResponse rsp = con.Put(url.getFile(), "Hello World");
if (rsp.getStatusCode() >= 300)
{
System.err.println("Received Error: "+rsp.getReasonLine());
System.err.println(rsp.getText());
}
else
text = rsp.getText();
}
catch (IOException ioe)
{
System.err.println(ioe.toString());
}
catch (ModuleException me)
{
System.err.println("Error handling request: " + me.getMessage());
}

Long Range ZIP is a compression program that can achieve very high compression ratios and speed when used with large files. It uses the combined compression algorithms of lzma for maximum compression, lzo for maximum speed, and the long range redundancy reduction of rzip.
It is designed to scale with increases with RAM size, improving compression further. A choice of either size or speed optimizations allows for either better compression than even lzma can provide, or better speed than gzip, but with bzip2 sized compression levels.
Enhancements:
- Blocks to be compressed by lzma are now scanned by lzo in advance to find incompressible data and bypass attempting to compress them.
- This speeds up substantially attempting to compress incompressible files, and should fix the "lzma getting stuck on an incompressible block" bug.
- Basic Darwin support was added.
- Compression mode was stratified for lower levels of lzma compression.

JDBC is a Perl 5 interface to Java JDBC (via Inline::Java).

SYNOPSIS

use JDBC;

JDBC->load_driver("org.apache.derby.jdbc.EmbeddedDriver");

my $con = JDBC->getConnection($url, "test", "test");

my $s = $con->createStatement();

$s->executeUpdate("create table foo (foo int, bar varchar(200), primary key (foo))");
$s->executeUpdate("insert into foo (foo, bar) values (42,notthis)");
$s->executeUpdate("insert into foo (foo, bar) values (43,notthat)");

my $rs = $s->executeQuery("select foo, bar from foo");
while ($rs->next) {
my $foo = $rs->getInt(1);
my $bar = $rs->getString(2);
print "row: foo=$foo, bar=$barn";
}

This JDBC module provides an interface to the Java java.sql.* and javax.sql.* JDBC APIs.

JavaDesktopEngines aim is to produce a piece of software that is at the same time:
Shared virtual machine
It allows to launch different java programs inside the same VM. The VM will always be alive, so no more startup overhead and less memory used.
It uses our JDSVM(Java Desktop Shared Virtual Machine), which in turn is based on Javagroups great Echidna Project
Xml Rpc local server
This way it is possible for programs, even written in languages different from java, to access "services" exposed by the engine.
Plugin host
It has been built with a pluggable architecture in mind, so that it is possible to develop new "services" for the engine.
Linux/Windows service (next release)
It is run as a service, so that its "services" will always be available for other programs.
For those of us who make heavy use of java tools its always been quite frustrating to have to open lots of resource eager VMs just to launch very useful but simple programs. Moreover, VM starting for simple utilities is a real waste of time.
Weve all appreciated the difference when launching a compilation from inside an IDE. In this case javac is launched as a process inside an already active VM, and the difference is evident.
JDE in the beginning was born to try to address these problems. Having an always active VM where it is possible to launch processes in, means faster process start and less resources used. A lot of time is saved by from not loading again and again the VM.
Theres nothing new in this. Some very good related projects are alive and kicking on the net, some of them focusing on a complete Java desktop enviroment, some on just a shared VM. JDE positions itself a bit differently, as it can be seen as a java engine exposing pluggable services (shared VM being just one of these).
There are several approaches to implementing a shared VM, all of them with pros and cons. Weve chosen to use the great code from the Echidna Project for now.
The entrypoint of JDE is an XML-RPC server accepting calls for services. Everything needed from JDE can be obtained by making a call to it.
The main service exposed by JDE is obviously the java process launching one. By making a call, it is possible to launch a java process insisde the VM. Having an XML-RPC server allows us to use any language with xmlrpc capabilities to launch java programs. The package includes a simple python script, that can be easily used as launcher (see our simple tutorial for details).
Included is also a "Manager", a simple swing application with active process listing and process launching capabilities.
Hopefully, this one will evolve as far as there will be more services in JDE to be the reference manager for the engine.
Included plugins:
1) Java process Launcher. The one this project was started for. You can launch java processes inside the living VM.
2) Scripting engine. Via a simple xmlrpc call you can launch a script on the engine and get back results. The nice thing, as usual, is that being xmlrpc based, you can use it as a service called by anything written in any language. Currently supported scripting language is BeanShell. More will be available soon via BSF.
3) Fast editor Based on jEdit Syntax Package 2.2.1, a simple, fast and useful editor with only some of the nice features jEdit has got us used to.
Enhancements:
- This release should be a bit more robust when killing processes that make use of System.exit(0) without "dispose()".
- An icon for the GUI manager has been added, as well as a bat file for Windows systems.