Free vcg software for linux

VCG TriMeshInfo is a tool designed to inspect 3D models and retrieve many types of topological and geometrical information from them.
It can be used to automate the process of decoding 3D mesh inherent properties and ease data classification and retrieval.
For each analyzed dataset, the following data are extracted:
- Number of Vertices (Unreferenced vertices are listed separately)
- Number of Faces
- Number of Edges
- Number of Connected Components
- Number of Boundaries
- Number of Isolated Vertices (i.e. Unreferenced)
- Manifold
- Genus (Computed only for Manifold Datasets)
- Orientability
- Orientation
- Regularity (We consider as regular those meshes generated through regular subdivision. Each non boundary vertex of a regular mesh has 6 incident edges, if there are only 5 incident edges the mesh is said to be semi-regular, irregular in all other cases)
- Number of Duplicated Vertices
- Self-Intersection (Currently computed only for Datasets with less than 3M faces)
Enhancements:
- This release included a major rewrite of the core component for computing geometrical and topological features of the analyzed mesh.
- Important changes included speeded up self-intersection tests, more robust (and correct) computation of topological genus and volume, and more flexible output with an HTML output option.

B::Graph is a Perl compiler backend to produce graphs of OP trees.

SYNOPSIS

perl -MO=Graph,-text prog.pl >graph.txt

perl -MO=Graph,-vcg prog.pl >graph.vcg
xvcg graph.vcg

perl -MO=Graph,-dot prog.pl | dot -Tps >graph.ps

This module is a backend to the perl compiler (B::*) which, instead of outputting bytecode or C based on perls compiled version of a program, writes descriptions in graph-description languages specifying graphs that show the programs structure. It currently generates descriptions for the VCG tool (http://www.cs.uni-sb.de/RW/users/sander/html/gsvcg1.html) and Dot (part of the graph visualization toolkit from AT&T: http://www.research.att.com/sw/tools/graphviz/). It also can produce plain text output (which is more useful for debugging the module itself than anything else, though you might be able to make cut the nodes out and make a mobile or something similar).

OPTIONS

Like any other compiler backend, this module needs to be invoked using the O module to run correctly:

perl -MO=Graph,-opt,-opt,-opt program.pl
OR
perl -MO=Graph,-opt,obj -e BEGIN {$obj = ["hi"]}; print $obj
OR EVEN
perl -e use O qw(Graph -opt obj obj); print "hi!n";

Obj is the name of a perl variable whose contents will be examined. It cant be a my() variable, and it shouldnt have a prefix symbol ($@^*), though you can specify a package -- the name will be used to look up a GV, whose various fields will lead to the scalar, array, and other values that correspond to the named variable. If no object is specified, the whole main program, including the CV that points to its pad, will be displayed.

Each of the the opts can come from one of the following (each set is mutually exclusive; case and underscores are insignificant):

-text, -vcg, -dot

Produce output of the appropriate type. The default is -text, which isnt useful for much of anything (it does draw some nice ASCII boxes, though).

-addrs, -no_addrs

Each of the nodes on the graph produced corresponds to a C structure that has an address and includes pointers to other structures. The module uses these addresses to decide how to draw edges, but it makes the graph more compact if they arent printed. The default is -no_addrs.

-compile_order, -run_order

The collection of OPs that perl compiles a script into has two different layers of structure. It has a tree structure which corresponds roughly to the synactic nesting of constructs in the source text, and a roughly linked-list representation, essentially a postorder traversal of this tree, which is used at runtime to decide what to do next. The graph can be drawn to emphasize one structure or the other. The former, compile_order, is the default, as it tends to lead to graphs with aspect ratios close to those of standard paper.

-SVs, -no_SVs

If OPs represent a programs compiled code, SVs represent its data. This includes literal numbers and strings (IVs, NVs, PVs, PVIVs, and PVNVs), regular arrays, hashes, and references (AVs, HVs, and RVs), but also the structures that correspond to individual variables (special HVs for symbol tables and GVs to represent values within them, and special AVs that hold my() variables (as well as compiler temporaries)), structures that keep track of code (CVs), and a variety of others. The default is to display all these too, to give a complete picture, but if you arent in a holistic mood, you can make them disappear.

-ellipses, -rhombs

The module tries to give the nodes representing SVs a different shape from those of OPs. OPs are usually rectangular, so two obvious shapes for SVs are ellipses and rhombuses (stretched diamonds). This option currently only makes a difference for VCG (ellipse is the default).

-stashes, -no_stashes

The hashes that perl uses to represent symbol tables are called stashes. Since every GV has a pointer back to its stash, its virtually inevitable for the links in a graph to lead to the main stash. Unfortunately stashes, especially the main one, can be quite big, and lead to forests of other structures -- theres one GV and another SV for each magic variable, plus all of @INC and %ENV, and so on. To prevent information overload, then, the display of stashes is disabled by default.

-fileGVs, -no_fileGVs

Another kind graph element that can be annoying are the pointers from every GV and COP (a kind of OP that occurs for every statement) to the GV that represents the file from which that code came (used for error messages). By default, these links arent shown, to keep them from cluttering the graph. Also, perls internal interfaces changed in a recent version, so in perl 5.005_63 or later you cant see the fileGVs at all.

-SEQs, -no_SEQs

As it is visited in the peephole optimization phase, each OP gets a sequence number, which is currently used by anything (except the peephole optimizer, to avoid visiting OPs twice). If you want to see these, ask for them. (COPs have their own sequence numbers too, but theyre more interesting to look at -- for instance, theyre used to bound the lifetimes of lexicals).

-types, -no_types

B::Graph always gives the type of each OP symbolically (entersub), but it can also print the numeric value of the type field, if you want. The default is no_types.

-float, -no_float

Almost every OP has an op_next and an op_sibling pointer, and B::Graph colors them distinctively (pink and light blue, respectively). Because of this, it isnt strictly necessary to anchor the arrow on a line in the OPs box saying op_next. The float option lets the graph layout engine start these arrows wherever it wants, which can sometimes lead to a more pleasing layout, at the expense of being less obvious. The default is not to float.

-targlinks, -no_targlinks

Lexical (my()) variables and temporary values used by individual OPs are stored in pads, per-code arrays linked to the CV. OPs store indexes into these arrays in the op_targ field, but B::Graph can often also draw links directly from the OP to the SV that stores the name of the variable. These links dont correspond to any real pointers, however, and they can make the graph more complicated, so they are disabled by default.

IDS::Algorithm::MM is a Perl module created to learn or test using a first-order Markov Model (MM).

SYNOPSIS

A usage synopsis would go here. Since it is not here, read on.
In section 4.2 in Kruegel and Vignas paper, they ignored the probability information that the MM provided, and produced a binary result. In effect, they were using the constructed MM as a {N,D}FA.

Someday more will be here.

Ideally, we would be using the algorithm from stolcke94bestfirst. Constructing a DFA rather than a NFA in effect has performed most of the state merging that stolcke93hidden do.

Consider also a java or C/C++ implementaion: http://www.ghmm.org/ http://www.run.montefiore.ulg.ac.be/~francois/software/jahmm/

Useful information: http://www.cs.brown.edu/research/ai/dynamics/tutorial/Documents/HiddenMarkovModels.html http://www.comp.leeds.ac.uk/roger/HiddenMarkovModels/html_dev/main.html L R Rabiner and B H Juang, `An introduction to HMMs, IEEE ASSP Magazine, 3, 4-16.

printvcg

printvcg(filehandle)

Print in a form usable by VCG for printing the DFA.

If the filehandle is specified, print there; otherwise, print to STDOUT.
This code was stolen from DFA, and does not know about the probabilities.
load(filehandle)

Load a MM from a file; this is the inverse of "print", and the format we expect is that used in $self->print.

test(tokensref, string, instance)

Test the string of tokens and calculate the probability of the string being seen. At each stage, we get a p in [0,1]. The result is the product of these probabilities.
Note that if a transition cannot be made, we return a 0 probability.

add(tokensref, string, instance)

The collection of tokens (in the list referenced by tokensref) is a complete example of a list that should be accepted by the DFA.

string and instance are IDS::Test framework arguments that we ignore because we do not need them.

WE add the transition from the last token to the (ACCEPT) state.

add_transition(from, token)

Add a transition from one state to another when the specified token is received. It is not an error to try to add an existing transition. In that event, this function quietly returns. If no such transition exists, we look for a transition on the token; if so, we add an edge to the destination node for the existing edge. Finally, if there is no other choice, we create a new state and add the edge.

generalize()

Reduce the number of states in the model.

Our building a DFA rather than a NFA has in effect performed most of the state merging that would have occurred.

XXX We should still be doing some checks for additional merge possibilities.
XXX A proof that the DFA is effectively the NFA with merged states would be useful.

KProf is a visual tool for developers, which displays the execution profiling output generated by code profilers.
The output of profilers being usually difficult to read (beyond the flat profile information), KProf presents the information in list- or tree-views that make the information very easy to understand.
Main features:
- Flat profile view displays all function / methods and their profiling information.
- Hierarchical profile view displays a tree for each function / method with the other functions / methods it calls as subelements.
- Object profile view, for C++ developers, groups the methods in a tree view by object name.
- Graph view is a graphical representation of the call-tree, requires GraphViz to work.
- Method view is a more detailed look at an individual method - cross referenced.
- Recursive functions carry a special icon to clearly show that they are recursive.
- Right-clicking a function or method displays a pop-up with the list of callers and called functions. You can directly go to one of these functions by selecting it in the pop-up menu.
- The flat profile view provides an additional filter edit box to filter the display and show only the functions or methods containing the text that you enter.
- Function parameters hiding if the function name is unique (i.e. no different signatures)
- C++ template abbreviation (template parameters can be hidden)
- Automatic generation of call-graph data for GraphViz and VCG, two popular graph image generators.
- Diff mode support to compare two profile results.

Autodia::Handler::Torque Perl module contains an AutoDia handler for Torque xml database schema.

This provides Autodia with the ability to read Torque Database Schema files, allowing you to convert them via the Diagram Export methods to images (using GraphViz and VCG) or html/xml using custom templates or to Dia.

SYNOPSIS

use Autodia::Handler::Torque;

my $handler = Autodia::Handler::dia->New(%Config);

$handler->Parse(filename); # where filename includes full or relative path.

Description

The Torque handler will parse the xml file using XML::Simple and populating the diagram object with class, superclass, and relationships representing tables and relationships.

The Torque handler is registered in the Autodia.pm module, which contains a hash of language names and the name of their respective language.

An example Torque database schema is shown here - its actually a rather nice format apart from the Java studlyCaps..

< ?xml version="1.0" encoding="ISO-8859-1" standalone="no" ? >
< !DOCTYPE database SYSTEM "http://db.apache.org/torque/dtd/database_3_0_1.dtd" >
< database name="INTERPLANETARY" >
< table name="CIVILIZATION" >
< column name="CIV_ID" required="true" autoIncrement="true" primaryKey="true" type="INTEGER"/ >
< column name="NAME" required="true" type="LONGVARCHAR"/ >
< /table >

< table name="CIV_PEOPLE" >
< column name="CIV_ID" required="true" primaryKey="true" type="INTEGER"/ >
< column name="PEOPLE_ID" required="true" primaryKey="true" type="INTEGER"/ >

< foreign-key foreignTable="CIVILIZATION" >
< reference local="CIV_ID" foreign="CIV_ID"/ >
< /foreign-key >
< foreign-key foreignTable="PEOPLE" >
< reference local="PEOPLE_ID" foreign="PEOPLE_ID"/ >
< /foreign-key >
< /table >

< table name="PEOPLE" >
< column name="PEOPLE_ID" required="true" autoIncrement="true" primaryKey="true" type="INTEGER"/ >
< column name="NAME" required="true" size="255" type="VARCHAR"/ >
< column name="SPECIES" type="INTEGER" default="-2"/ >
< column name="PLANET" type="INTEGER" default="-1"/ >
< /table >
< /database >