Free ast software for linux

Starlink::AST::PGPLOT is a AST wrapper to the PGPLOT library.

SYNOPSIS

use Starlink::AST::PGPLOT
The main methods which need to be registered with the AST package are shown below,
$status = _GFlush();
$status = _GLine( @x, @y );
$status = _GMark( @x, @y, $type );
$status = _GText( $text, $x, $y, $just, $upx, $upy );
( $status, $xb, $yb ) = _GTxExt( $text, $x, $y, $just, $upx, $upy );
( $status, $chv, $chh ) = _GQch();
( $status, $old_value ) = _GAttr( $attr, $value, $prim );
( $status, $alpha, $beta) = _GScales();

This file implements the low level graphics functions required by the rest of AST, by calling suitable PGPLOT functions (the FORTRAN PGPLOT interface is used).

This file can be used as a template for the development of similar modules to support alternative graphics systems.

Parse::Java is a Perl module that acts like a parser for Java code.

SYNOPSIS

use Parse::Java;

my $ast = Parse::Java->parse_file(MyClass.java);

Parse::Java parses Java code into an Abstract Syntax Tree which can be used for many things like writing compilers and stuff.

As this module is currently under development it isnt yet able to parse much Java. Whats in the t/*.t basically works but not much else.

The lexer should also more or less work fine except expansion of unicode escapes uNNNN.

INTERFACE

This module uses an object-oriented interface.

CLASS METHODS

parse_file ( $path )

Parses the contents of the file $path. Returns an AST representing the code.

parse_string

Parses the source in $string. Returns an AST representing the code.

detokenize ( $ast )

Walks the AST and replaces all Parse::Java::Token-objects with their stringified value.

INSTANCE METHODS

_set_input ( $source )

Sets the input to the lexer.

_next_token

Returns a list with the next token from the stream and its value.

xmms-cube is a port of the Winamp plugin in_cube. xmms-cube plugin allows you to play Gamecube streamed audio files.
Supported types include:
- DSP
- GCM
- HPS
- IDSP
- SPT
- SPD
- MSS
- MPDSP
- ISH,
- YMF
- ADX
- ADX
- RSD
- RSP
- AST
- AFC

Scheme2Js is a Scheme to Javascript compiler. While some effort has been spent on being as close as possible to R5rs, we concentrated mainly on efficiency.
Usually Scheme2Js produces Javascript code, that is comparable to hand-written code. In order to achieve this performance, Scheme2Js is not completely R5rs compliant. In particular it lacks support for continuations, exact numbers and it treats tail recursion only partially.
Scheme2Js provides several flags, that allow to modify the result:
- --no-js-dot-notation disallows access to JavaScript fields with the dot-notation. This flag disables accesses of the form x.y like in document.getElementById. It is however still possible to access the is a valid expression using the js-field function.
- --mutable-strings: in order to improve the performance of string-operations and to ease the interface between Scheme and JavaScript code, the default implementation maps Scheme strings to JavaScript strings. Contrary to Scheme strings, JavaScript strings are however immutable. This flag maps strings to a JavaScript class, that represents Scheme strings, that are mutable. The resulting code might be slightly slower, and it is more difficult to interface with Javascript code.
- --encapsulate-parts encapsulates the program into an anonymous function. Only global variables are outside of this anonymous function. On one hand this introduces one function call to the anonymous function. But on the other hand most Javascript implementations should run faster with this optimization: usually hashtables are used to represent scopes in JavaScript. By using an anonymous function the programs variables are separated into their own smaller hashtable which (in theory) accelerates accesses to these variables. More importantly the variables are stored in their own hashtable, and not in the global hashtable, which is accessible by the global variable. It is extremely easy to indirectly modify the contents of global variables. Inlining or other common optimizations are hence impossible to do on global variables. By storing the programs variables in an anonymous function these optimizations become again possible.
- --optimize-var-number reduces the number of variables used in the resulting JavaScript code. The code may run faster, but is more difficult to debug, as the variable names are lost and the same variable might be used several times.
- --optimize-while: with this flag Scheme2Js optimizes common while loops. The unoptimized while loops are often of the form:
while(true) {
if(test)
resVar = res;
else {
modify_loop_variable;
continue;
}
break;
}
This optimization looks for these patterns and moves the test into the while loop:
while(!test) {
modify_loop_variable;
}
resVar = res;
This optimization has been implemented only recently and is therefore not yet activated by default.
- --verbose prints some information.
- --no-inlining disables all function inlining (constants might still be inlined).
- --inline-globals lets Scheme2Js inline global functions and constants. This might have two unwanted side-effects: for one, global variables are often used to transfer data between different modules. Some inlined functions are lost if there is no reference to them anymore. If global functions are to be used outside a module, one should not use this flag. (This behavior is likely to change in future versions of Scheme2Js.)
- --unresolved-is-js: if a variable is unbound, the compiler will assume the variable comes from another module, or from JavaScript. See Section Scheme - Javascript for a more detailed discussion of the JavaScript Scheme interface.
- --js-this provides the this variable within Scheme functions. This way, Scheme procedures can be used as methods of JavaScript objects.
- --no-tailrec disables the tailrec to while-loop optimization. If you suspect a bug in the compilers way of translating tail-recs, you could try this flag.
- --no-optimize-calls disables Scheme2Js inlining of binary or unary operations. For instance sci_plus(3, 5) is optimized to (3+5). This optimization is quite important, and theres usually no reason to disable it.
- --no-optimize-consts disables the pre-constant calculation. Unless disabled (with this flag), compound constants are precalculated and their occurrences replaced by a reference to a variable holding the constant. This makes repeated accesses to these constants faster, but introduces new variables.
- --no-optimize-boolify disables the boolify optimization. JavaScripts and Schemes boolify are not equivalent: JavaScript considers false, 0, null and undefined to be false, whereas Scheme only has #f. The unoptimized boolify therefore always adds the test against false: if (test !== false) ... If Scheme2Js can see, that the test itself is a boolean, it can remove the unnecessary !== false test. This flag disables this optimization.
- --d STAGE prints a dot-file (see graphviz) of the AST after stage STAGE. Possible stages are: expand, tree, symbol, node-elim1, tail, inline, constant-propagation, rm-unused-vars, capture, node-elim2, while, (tt "statements"), node-elim3. Usually one doesnt need this flag, unless for debugging purposes.
- --print-locs prints the original locations as comments to the JavaScript file. These locations are currently the character-offset from the beginning of the file.
Enhancements:
- This release adds trampolines.

Template::Alloy::Parse is a Perl module with common parsing role for creating AST from templates.

The Template::Alloy::Parse role is reponsible for storing the majority of directive parsing code, as well as for delegating to the TT, HTE, Tmpl, and Velocity roles for finding variables and directives.

ROLE METHODS

parse_tree

Used by load_tree. This is the main grammar engine of the program. It delegates to the syntax found in $self->{SYNTAX} (defaults to alloy) and calls the function found in the $SYNTAX hashref. The majority of these syntaxes use methods found in the $DIRECTIVES hashref to parse different DIRECTIVE types for each particular syntax.

A template that looked like the following:

Foo
[%- GET foo -%]
[%- GET bar -%]
Bar

would parse to the following AST:

[
Foo,
[GET, 6, 15, [foo, 0]],
[GET, 22, 31, [bar, 0]],
Bar,
]

The "GET" words represent the directive used. The 6, 15 represent the beginning and ending characters of the directive in the document. The remaining items are the variables necessary for running the particular directive.
parse_expr

Used to parse a variable, an expression, a literal string, or a number. It returns a parsed variable tree. Samples of parsed variables can be found in the VARIABLE PARSE TREE section.

my $str = "1 + 2 * 3";
my $ast = $self->parse_expr($str);
# $ast looks like [[undef, +, 1, [[undef, *, 2, 3], 0]], 0]
parse_args

Allow for the multitudinous ways that TT parses arguments. This allows for positional as well as named arguments. Named arguments can be separated with a "=" or "=>", and positional arguments should be separated by " " or ",". This only returns an array of parsed variables. To get the actual values, you must call play_expr on each value.

dump_parse_tree

This method allows for returning a string of perl code representing the AST of the parsed tree.

It is mainly used for testing.

dump_parse_expr

This method allows for returning a Data::Dumper dump of a parsed variable. It is mainly used for testing.

parse_*

Methods by these names are used by parse_tree to parse the template. These are the grammar. They are used by all of the various template syntaxes Unless otherwise mentioned, these methods are not exposed via the role.

Template::Alloy::Operator is a Perl module that provides the regexes necessary for Template::Alloy::Parse to parse operators and place them in their appropriate precedence.

It also provides the play_operator method which is used by Template::Alloy::Play and Template::Alloy::Compile for playing out the stored operator ASTs.

ROLE METHODS

play_operator

Takes an operator AST in the form of

[undef, +, 1, 2]

Essentially, all operators are stored in RPN notation with a leading "undef" to disabiguate operators in a normal Alloy expression AST.

define_operator

Used for defining new operators.

See Template::Alloy for more details.

Cocom project is a toolset that is oriented towards the creation of compilers, cross-compilers, interpreters, and other language processors.
It consists of reusable packages (collection and memory management framework), a Sprut internal representation description (AST-to-AST) translator, a Nona code selector description translator (generator generator similiar to BEG, Twig, Burg, and Iburg), an MSTA syntax description translator (yacc-compatible parser with better error reporting), an OKA pipeline hazards description translator, and SHILKA keywords description translator (similiar to gperf but faster).
Enhancements:
- Ammunition.
- Package arithm works with numbers with bases upto 35. New tests.
- Earley parser is able to use rules costs to chose the translation with minimal cost. Some bugs are fixed. New tests.
- MSTA has an additional error recovery with minimal cost. New tests.
- Dino.
- Minor changes in the language (few new operators and special method `destroy).
- New functions.
- New package to work with sockets.
- Many fixed bugs.
- The sped up interpreter (upto 50%).
- Comparison tests with perl, python, tcl, awk.
- Many new tests.
- Improved documentation.
- OKA. The problem of possible incorrect automata generation because of wrong distribution of units to automata and the construction `exclusion has been fixed.
- Cocom and Dino have an additional distribution format `rpm.