Free visual turing machine software for linux

Virtual Drum Machine is a simple drum machine.
It works for little endian/linux kind of machines. You may let it work on others machines, but you probably will get troubles with it.
You definitely need oss (or maybe alsa) for sound output, and a posix-like operating system. To let it work on a big endian machine should be painful.
You write a rhythm, then you compile it, then you are able to play it to your sound card or save it to a file.
The Virtual Drum Machine is made of
- the Rhythm Compiler,
- the runtime library.
The Virtual Drum Machine is in the public domain. Who needs a license? money makers? Protection against robbery? let me laugh... Read any text of law, you will see where the robbers reside.
A simple file would look like :
void main_rhythm(void)
{
tempo = 120;
- a
. b
. b
.
- a
.b
- a
.
. b
. b
- a c
. b
}
Install:
Do a "./configure" in the drums directory, then "make", then "make install", it should be alright. You can listen to some examples in the examples/ directory.
Who yo use it?
Write a rhythm. Compile it with "rc". Run the produced program. You are done.
See the examples/ directory to get the point.
When you run an example, try "-h" to get the available options.
It should be self-explanatory.
The rhythm compiler has several options. By running "rc --help", all should be clear.
Technical Details:
The compiler will parse the input file line by line.
If a line starts with "*" or "." (not counting leading white spaces), the whole line is seen as a rhythm line, and is transformed into C code. If not, it is passed as is to the C file.
Beware! You MUST NOT start any C code line by "*" or "."!
You can create as much functions as you want, write any C code you want. But remember that a line starting by "*" or "." is seen as a rhythm line and is translated by "rc" into C code.
You must provide a "void main_rhythm(void)" function, that will be called by the library. It is the starting point of your rhythm. It can be "void main_rhythm(int argc, char *argv[])" too, with common meaning for those parameters (non-C coders will have trouble with the Virtual Drum Machine).
You can change the tempo (ex. "tempo=100;") or the volume (ex "vol=0.4;") at any time. Each sample comes with its own volume and panning (ex. "a.vol = 0.1;" "a.pan=-0.8;"). Volumes range from 0 to what you want. 1 is for the normal volume. Panning ranges from -1 (left) to 1 (right). 0 is center. All values are double. You can use "volume" instead of "vol", and "panning" instead of "pan". There is no global panning, if you want all left, set all samples to left.
To run in stereo mode, dont forget "-s" when running the generated program. It is mono by default.
You absolutely need to compile and run the examples, and read them to get the point out of it!
The "rc.conf" file contains configuration informations. You specify the sample by "sample" followed by its name (the one you will use in your rhythm files), then the file that will be played. The name of the sample must start by a letter, followed by letters and/or numbers (it must be a valid C identifier, without "_" though). The configuration file contains the install directory, used by "rc" to compile your rhythms. Take a look at the one that is provided to see how to use it.
The sound files are simple wav files. They all should be of the same rate, which can be specified to the generated program, using the "-f" option (44100 is the default). (The library only handles very basic wav files, if yours dont work, you probably will have to modify the library for the program to handle it.)
When you add a sample, you must modify "rc.conf" for the changes to appear. The samples are hard-linked to the produced program, so if you change "sample a /some/dir/file1.wav" by "sample a /one/other/dir/file2.wav" in the configuration file, the previously generated programs will still use "/some/dir/file1.wav". You will have to compile them again to take the changes into account.
Enhancements:
- The code has been modified to let gcc 4 compile it.

Virtual Machine Manager software (virt-manager for short package name) is a desktop user interface for managing virtual machines. The project presents a summary view of running domains and their live performance & resource utilization statistics. A detailed view presents graphs showing performance & utilization over time. Ultimately it will allow creation of new domains, and configuration & adjustment of a domains resource allocation & virtual hardware. Finally an embedded VNC client viewer presents a full graphical console to the guest domain.

The application logic is written in Python, while the UI is constructed with Glade and GTK+, based on mockups provided by UI interaction designers. The libvirt Python bindings are used to interacting with the underlying hypervisor. This enables the application to be written independant of any particular hypervisor technology. Initially Xen was the primary platform supported, however, since libvirt 0.2.0 and virt-manager 0.3.1 it is possible to manage QEMU and KVM guests too. It is expected that support for additional hypervisors / virtualization products will expand even further over time as additional libvirt drivers are written.
The "Virt Install" tool (virtinst for short package name) is a command line tool which provides an easy way to provision operating systems into virtual machines. It also provides an API to the virt-manager application for its graphical VM creation wizard.

The "Virt Clone" tool (virtinst for short package name) is a command line tool for cloning existing inactive guests. It copies the disk images, and defines a config with new name, UUID and MAC address pointing to the copied disks.
The "Virtual Machine Viewer" application (virt-viewer for short package name) is a lightweight interface for interacting with the graphical display of virtualized guest OS. It uses GTK-VNC as its display capability, and libvirt to lookup the VNC server details associated with the guest. It is intended as a replacement for the traditional vncviewer client, since the latter does not support SSL/TLS encryption of x509 certificate authentication.

Joeq is a virtual machine and compiler infrastructure designed to facilitate research in virtual machine technologies such as Just-In-Time and Ahead-Of-Time compilation, advanced garbage collection techniques, distributed computation, sophisticated scheduling algorithms, and advanced run time techniques.
Joeq is entirely implemented in Java, leading to reliability, portability, maintainability, and efficiency. It is also language-independent, so code from any supported language can be seamlessly compiled, linked, and executed -- all dynamically.
Each component of the virtual machine is written to be independent with a general but well-defined interface, making it easy to experiment with new ideas.
Joeq is released as open source software, and is being used as a framework by researchers on five continents on topics ranging from automatic distributed virtual machines to whole-program pointer analysis.
Joeq is a virtual machine and compiler infrastructure designed to be a platform for research in compilation and virtual machine technologies. We had three main goals in designing the system. First and foremost, we wanted the system to be flexible. We are interested in a variety of compiler and virtual machine research topics, and we wanted a system that would not be specific to researching a particular area.
For example, we have interest in both static and dynamic compilation techniques, and in both type-safe and unsafe languages. We wanted a system that would be as open and general as possible, without sacrificing usability or performance.
Second, we wanted the system to be easy to experiment with. As its primary focus is research, it should be straightforward to prototype new ideas in the framework. With this in mind, we tried to make the system as modular as possible, so that each component is easily replaceable. Learning from our experience with Jalapeno, another virtual machine written in Java, we decided to implement the entire system in Java.
This makes it easy to quickly implement and prototype new ideas, and features like garbage collection and exception tracebacks ease debugging and improve productivity. Java, being a dynamic language, is also a good consumer for many of our dynamic compilation techniques; the fact that our dynamic compiler can compile the code of the virtual machine itself means that it can dynamically optimize the virtual machine code with respect to the application that is running on it. Javas object-oriented nature also facilitates modularity of the design and implementation.
Third, we wanted the system to be useful to a wide audience. The fact that the system is written in Java means that much of the system can be used on any platform that has an implementation of a Java virtual machine. The fact that Joeq supports popular input languages like Java, C, C++, Fortran, and even x86 binary code increases the scope of input programs. We released the system on the SourceForge web site as open source under the Library GNU Public License.
It has been picked up by researchers on five continents for various purposes, among them: automatic extraction of component interfaces, static whole-program pointer analysis, context-sensitive call graph construction, automatic distributed computation, versioned type systems for operating systems, sophisticated profiling of applications, advanced dynamic compilation techniques, system checkpointing, anomaly detection, secure execution platforms and autonomous systems. In addition, Joeq is now used as the basis of the Advanced Compilation Techniques class taught at Stanford University.
Joeq supports two modes of operation: native execution and hosted execution. In native execution, the Joeq code runs directly on the hardware. It uses its own run-time routines, thread package, garbage collector, etc. In hosted execution, the Joeq code runs on top of another virtual machine. Operations to access objects are translated into calls into the reflection library of the host virtual machine.
The user code that executes is identical, and only a small amount of functionality involving unsafe operations is not available when running in hosted execution mode. Hosted execution is useful for debugging purposes and when the underlying machine architecture is not yet directly supported by Joeq. We also use hosted execution mode to bootstrap the system and perform checkpointing, a technique for optimizing application startup times.
Joeq system consists of seven major parts:
- Front-end: Handles the loading and parsing of input files, such as Java class files, SUIF files, and binary object files.
- Compiler: A framework for performing analyses and optimizations on code. This includes the intermediate representation (IR) of our compiler.
- Back-end: Converts the compilers intermediate representation into native, executable code. This code can be output to an object file or written into memory to be executed. In addition, it generates metadata about the generated code, such as garbage collection maps and exception handling information.
- Interpreter: Directly interprets the various forms of compiler intermediate representations.
- Memory Manager: Organizes and manages memory. Joeq supports both explicitly-managed and garbage-collected memory.
- Dynamic: Provides profile data to the code analysis and optimization component, makes compilation policy decisions, and drives the dynamic compiler.
- Run-time Support: Provides runtime support for introspection, thread scheduling, synchronization, exception handling, interfacing to external code, and language-specific features such as dynamic type checking.

High Level Virtual Machine is a toolkit for developing virtual machines for dynamic languages.
The High Level Virtual Machine is:
- Based on LLVM (Low Level Virtual Machine). LLVM is HLVMs sister project. HLVM gains tremendous capability from LLVM in the areas of code generation, bytecode storage, runtime execution, etc.
- Aimed at supporting dynamic languages such as Ruby, Python, Perl, Jython, Haskell, Prolog, etc.
- A complete compiler developers toolkit for creating new languages easily. To write a new compiler, language designers simply write a plugin that describes the language to HLVM and how to translate the grammar productions into HLVMs comprehensive Abstract Syntax Tree (AST). After that, HLVM handles all aspects of code generation, bytecode storage, XML translation, JIT execution or interpretation, and native compilation.
- A language interoperability framework. Because all front end compilers generate code in the same AST, they can interoperate. Use of the runtime library for common constructs (e.g. "string") allow even complex data types to be shared between languages. Users of HLVM can write complex programs in multiple languages and be assured the result can be executed efficiently.
- A code management system including code revisioning, interface versioning, automated recompilation, separation of workspaces, etc.
- Currently under development. Project started April 20th, 2006. Stay tuned to this web site for future developments.

Yet Another Time Machine is a command line Ogg Vorbis and MPEG audio player with the ability to control the tempo of playback without changing the pitch.
Primary usage would be to listen (for example) to audio books at 150% tempo. This is still understandable and saves time, hence the name of the program.
The following audio encoding formats are supported:
- Ogg Vorbis
- Ogg Speex
- MPEG
- All formats supported by libsndfile (FLAC, WAV, AIFF, ...)
Enhancements:
- Version 0.4 adds support for libsndfile.
- There is also an undocumented gem, you can use < and > to slow down or speed up by 10%, and hitting SPACE can be used to pause playback.

Visual REGEXP project can easily design and debug regular expressions by providing a graphical visualization of the expression and its matches on a sample of your choice.
Version restrictions:
- some regexp can consume a lot of CPU time. This seems to be caused by the use of -all, -inline and -indices flags together.
- when a subexpression is not matched (empty match), the last character of the previous match are coloured. This is due to a problem in Tcl (bug submitted to Scriptics).
Enhancements:
- new version done by Martin Lemburg. Many thanks, Martin.
- it is now a tcl 8.5a4 starpack
- GUI layout changed to be based on a paned window
- GUI code looks different, to be more ergonomic
- the informational labels (replacements & matches) are now sunken
- there are now additional the "first" and "last" navigation buttons
- there is a new option to navigate through matches or matches and submatches
- the displayed count of matches is changed to display the current and the count of matches used for navigation (probably changes, if the new navigation option is changed)
- the replace widget is disabled on startup
- the tcl console is added to the help menu
- the key bindings inside the regexp text widget changed a bit to allow for expanded regexp (-expanded or (?x)) to contain tabs and newlines. Tabs are created with Control-Tab and newlines with Control-Return. Additional with Control-C|V|X (not c|v|x) it is possible to use the clipboard like with Control|Shift-Insert, Shift-Delete.

Visual Automata Simulator is a tool for simulating, visualizing and transforming finite state automata and Turing Machines.
Visual Automata Simulator is a DFA, NFA and TM simulator.
Main features:
- Creates, simulates and transforms DFA and NFA machines
- Creates and simulates TM
- Batch tests for TM: useful features to test a bunch of files quickly!
- Easy-to-use GUI interface (multi-documents)
- Smart links between objects
- Machines can be drawn using the mouse - and resized at any time
- Multiple machines can be created in a single document
- Multiple documents can be opened at the same time
- Documents can be saved and reloaded from disk
- Debug mode to see exactly how the machine is working (each step has a different color)
- MacOS X GUI compliant.
Enhancements:
- FA and TM machine can be exported to EPS file
- integrated update manager
- preferences: can specify the character used to define an epsilon transition
- fixed a bug where epsilon transition were not considered when starting directly from a state instead of following a non-epsilon transition.