Free invoke software for linux

C/Invoke is a library for connecting to C libraries at runtime. This differs from the typical method of interfacing with C, which involves writing static definitions which are then compiled to a machine-dependant format. C/Invoke provides a runtime facility to build descriptions of C functions and to call them, passing them appropriate data and retrieving results.
C/Invoke provides a central repository of code to handle the platform-dependant details of marshaling C parameters and return values. Currently C/Invoke has been ported to GCC (GNU/Linux, *BSD) on the x86 and amd64 architectures, Microsoft Windows on x86, and Mac OS X on PowerPC. The development team is interested in adding more ports as they gain access to more diverse hardware.
Audience
The main audience of C/Invoke are users of high-level programming languages who wish to interface with C. At the moment, most languages can be extended with C libraries only by authoring modules in C using language-specific APIs. There are many problems with this approach; writing extension modules requires knowledge of the C language instead of the language the application is being written in, the APIs needed to implement the modules are often involved and complex, and the resulting libraries must be built and maintained on many different platforms.
However, once C/Invoke is integrated into a language, the situation changes dramatically; users of Lua (for example) can interface to C by writing Lua code alone. This means that the advantages of Lua (or other high-level languages) such as portability and ease of use can be combined with the low-level power of C. To call a C function, one merely declares a C prototype in the high-level code, similar to the P/Invoke functionality of Microsofts .NET Framework. A subroutine is then created in the high-level environment which hooks into a proxy generated to correctly call the given C function.
There are two ways to integrate C/Invoke into a language. One is to use the existing extension module interface of the language in the normal manner. This is the preferred method to integrate with a language which is already established and which would be hard to modify, such as Perl, Python, Ruby, Tcl, etc. The other way would be to link C/Invoke directly into the language runtime and make the declarative C services part of the syntax of the language.
The C/Invoke developers are always looking for volunteers to integrate with an existing language, or programming language authors who are interested in using C/Invoke directly.
Enhancements:
- Support for the SPARC architecure was added, and many bugs were fixed in the Lua language binding.

Funkee is a cross-platform scripting host built on top of the Java Virtual Machine and the Groovy scripting language. Funkee is geared toward people who want to test code snippets, and toward those who need to write and run scripts quickly.
As of release 0.5, Funkee adds support for BSF -- the Bean Scripting Framework. It has been tested with Jython and Rhino (1.5R3), bringing the number of supported scripting languages to at least three, including Python, JavaScript/ECMAScript, and Groovy.
To add support for your favorite BSF-friendly language, just drop the languages JAR file into your .funkee directory, restart the application, and start writing scripts!
Funkee still favors Groovy, in that Java and Groovy can be used to define classes that can be referenced by any of the supported scripting languages.
Funkee now supports XML-RPC Web Services as both a client and a server. For security reasons, the server component doesnt start without user intervention.
XML-RPC server scripts only need to be dropped into the "xmlrpc" subdirectory off the users funkee home directory in order to be picked up. Example code will be added to this page Real Soon Now.
In order to create a client, scripts currently need to invoke:
funkee.getRPC("http://some.host.name:8080/")
after which they can use the remote service as though it was a local object.
When executed, Funkee displays a smiley face in the upper-right corner of your screen. In the background, it also creates a subdirectory named ".funkee" in your home directory, and unpacks a default set of scripts. (MS Windows users: your home directory is probably under "C:Documents and Settings") You can then invoke Groovy scripts in your .Funkee directory by using the smiley.
To execute Funkee, you need the Java Runtime Environment 1.4 or better. Funkee has been tested against JRE 1.4.2 and JRE 1.5.0 on MS Windows and Linux.
To launch Funkee on MS Windows, double-click the Funkee.jar file. On UNIX, type "java -jar funkee.jar" at the command shell.
Main features:
- Its cooler.
- JAR files dropped into the .Funkee directory are automatically read and made available to scripts at startup.
- Funkee keeps an internal cache of compiled Groovy scripts and classes, which it verifies against the scripts in the .funkee directory. When a Groovy script needs to be recompiled, it gets done transparently at runtime (this includes Groovy objects!).
- Funkee now supports a LOT more scripting languages than just Groovy.
Groovy scripts in Funkee are invoked by events. This means that the behavior of the application is completely configurable by the end user. The names of the scripts, the events that trigger them, and the value of the param variable that gets passed in are as follows:
sys_drop.groovy
param: java.awt.datatransfer.Transferable
Invoked when the user drops something on the smiley.
sys_hyperlink.groovy
param: javax.swing.event.HyperlinkEvent
Invoked when the user clicks a hyperlink in the speech window (after a sayHTML() command.) This is a good script to customize shortly after installing -- usually youll want to shovel the URL from the event to your preferred web browser.
sys_mouseclicked.groovy
sys_mousepressed.groovy
sys_mousereleased.groovy
sys_mouseentered.groovy
sys_mouseexited.groovy
sys_mousepopup.groovy
param: java.awt.event.MouseEvent
Invoked when the user makes the corresponding gesture with the mouse over the smiley.
sys_mousewheelmoved.groovy
param: java.awt.event.MouseWheelEvent
Invoked when the user moves the mouse wheel over the smiley.
Enhancements:
- The UI was completely rewritten and is now based on JRCF.
- Both text and graphical targets are now provided for script outputs.

Otk Tests are tests for the Open Tool Kit project.
Otk is a portable widget library for making graphical user interfaces for C programs. It emphasizes simplicity for the application programmer without eliminating capability. Based on OpenGL, Otk supports Linux, Unix, and other OSs neutrally and efficiently. It is simple and compact, and it strives for easy compilation and linking to other applications.
In seeking to address several issues associated with earlier graphics APIs, Otk explores some interesting methods, such as window-relative layout instead of pixel-based layout.
Enhancements:
- This package of Otk test programs includes scripts to automatically compile and invoke them sequentially.
- The scripts enable quickly testing OTK_LIB functionality.
- The package will be handy for continued regression testing whenever otk_lib is changed or updated.
- It checks that OTK and applications compile will on various platforms, and exercises most features to test for proper operations.

UniPackage is an alternative to distribution-specific packaging systems like dpkg and RPM. UniPackage is a simple system that works on any Linux distribution.

UniPackage packages are tar.bz2 archives which contain a self-contained "AppDir" which can be moved anywhere in the filesystem without disturbing the applications installation. In most cases, this packaging does not require changes to the applications code.

The issue of dependencies is avoided by bundling all required libraries in the AppDir. However, to conserve memory, applications will default to using existing libraries already installed on the system if they are available.

Disk space is conserved by transparently decompressing the applications "bin" and "lib" directories upon execution of the application (new to v0.5.2).

Creating Packages

In the following example, we will show how to create a package for MPlayer.

1. Extract the UniPackage tarball somewhere on your system (if youre reading this, then obviously youve done that).

2. Download the MPlayer source archive (the .tar.bz2) and extract it somewhere on your system (anywhere is fine).

3. Change your working directory to where you extracted UniPackage.

4. UniPackage makes use of recipes to compile programs, similar to in GoboLinux (www.gobolinux.com). A recipe is a simple bash script that contains the commands necessary to compile a program. For most programs, the Recipe.Standard recipe should
work fine. However, for more complex programs you may need to either create a recipe or find one that someone else has created.

Included with UniPackage is an example of a "complex" recipe for creating an MPlayer package - Recipe.MPlayer. If you have a look through the recipe, you will see that its not
really complex. It just sets up a few extra directories, downloads and extracts fonts/codecs/skins which are specific to MPlayer. You can modify the recipe as much as you like to get the desired compilation result.

Once you have created/found your recipe, you invoke the CreatePackage script to create your package. CreatePackage requires a few arguments, and running CreatePackage without any arguments will give you a concise overview of what you
need to supply to it.

To create our MPlayer package, we invoke CreatePackage by typing:

./CreatePackage /usr/local/src/MPlayer-1.0pre5 MPlayer-1.0pre5 gmplayer Recipe.MPlayer "--enable-gui"

To break down the arguments:

Arg1: Path to the programs source files /usr/local/src/MPlayer-1.0pre5

Arg2: Name of the program (arbritrary, use whatever you like) MPlayer-1.0pre5

Arg3: Name of the binary which will launch the compiled program gmplayer

Arg4: Filename of the recipe you wish to use (MUST be in the current directory).
Recipe.MPlayer

Arg5: Any additional commands you would like to send to the configure script when compiling (this is just exported to the recipe as a variable so even if the program does not use a configure script, you can still specify options which the recipe will
insert into the right place).

If there are no additional options you wish to specify, you must still provide the argument, but just use empty quotes: ""

"--enable-gui"

And thats it. The program should compile, and be packaged up into a nice
bzip2-compressed tarball.

To distribute the package, just have your users download the tarball and instruct them to extract its contents to wherever they like (I like to place my packages under /Applications but its entirely up to the user).

All configuration files (if applicable) will be contained within the extracted package directory. Regardless of where the user extracts the tarball, the program should still be able to find all required config files, libraries etc just fine.

To run the program, the user just navigates to the directory and executes the "AppRun" script. If they use Rox-Filer, all they need to do is click on the directory in Rox to launch the program.

CSudoku is a command line Sudoku solving program. CSudoku project solves the popular 9x9 versions of Sudoku using Donald Knuths Dancing Links algorithm.

It was created as a fun exercise in computer programming and not necessarily to be a program useful to anyone in particular.

There are many other Sudoku solving programs that are more refined and have many more features than this program would ever dream of having.

Installation:

1. unpack csudoku-1.0.tar.gz
2. cd csudoku-1.0/src
3. run make

Usage:

To run the sudoku program you will first need to install it using the steps as outlined above. Now, assuming you are in the directory csduoku-1.0/src, invoke the command:

./sudoku < infile

where infile is an input file containing 1 or more 9x9 Sudokus. For the format of the infile you can check out the file top95. In fact you can use the top95 file to test the program. By invoking the command:

./sudoku < ../top95

you should see some input and output details and at the end under "Overall Statistics" it should read

...
95 out of 95 were valid
0 has no solution(s)
95 had unique solution(s)
0 had multiple solution(s)
...

If this was done successfully you can now use the program to solve whatever Sudoku puzzle is giving you trouble. Enjoy!

TPIE is a software environment (written in C++) that facilitates the implementation of external memory algorithms.

The goal of theoretical work in the area of external memory algorithms (also called I/O algorithms or out-of-core algorithms) has been to develop algorithms that minimize the Input/Output communication (or just I/O) performed when solving problems on very large data sets.

The area was effectively started in the late eighties by Aggarwal and Vitter and subsequently I/O algorithms have been developed for several problem domains.

Installation:

Place "tpie_082902.tgz" in the directory in which TPIE is to be installed, "cd" into that directory, and execute the command

tar xzf tpie_082902.tgz

or

gunzip -c tpie_082902.tgz | tar xvf -

This will produce a directory "tpie_082902" with subdirectories "doc", "include", "lib", "lib/src", and "test". Enter the directory "tpie_082902". You must now configure TPIE for your particular system. To do this, use the command

./configure

The configuration program will produce the various Makefiles and configuration files required to build TPIE on your system. When this is done, invoke your version of GNU "make":

make all

to build the complete TPIE system. This will build the components of TPIE that must be tailored to your system.This includes: the TPIE run-time library "tpie_082902/lib/libtpie.a", the test and sample programs in directory "tpie_082902/test", and certain header files in
"tpie_082902/include".

You should now have a complete TPIE system, consisting of the directories "include", "doc", "lib", "lib/src", "test".

dao-zero is a tiny Java bean used to reduce the source of a persistence tier based on Springs iBatis support. The usual way to use iBatis in Spring is to write code and invoke the iBatis API explicitly.

dao-zero invokes the iBatis API for the developer automatically, without the need to write implementation code. It will implement DAO interfaces automatically and invoke iBatis SQL mapped statements for you. You can use it to replace your DAO bean class directly.

mangleme provides an automated broken HTML generator and browser tester.

mangleme is an automated broken HTML generator and browser tester, originally used to find dozens of security and reliability problems in all major Web browsers (Mozilla / Firefox / Netscape, Konqueror / Safari, MSIE, lynx, [e]links, w3m, elvis, etc), as reported on BUGTRAQ.

A trivial utility to automatically check for HTML parsing flaws. Generates
a basic set of badly mangled tags on request, with auto-refresh back to the
script, so that you can point a browser to it once, and let it run until
it crashes.

Put it in your cgi-bin directory or any other Apache folder with ExecCGI option enabled, then visit the URL http:// / /mangleme.cgi.

When the browser crashes, error-log should be examined for the last matching entry generated by mangle.cgi; extract the hexadecimal value, then invoke remangle.cgi?hex_value from the browser again. If it crashes, youve reproduced the problem, and can save the remangle.cgi page using wget or such.