Free code generation software for linux

Traffic Control - Next Generation (tcng) is a revision of the Linux network traffic control infrastructure that aims to make the configuration language less cryptic, and provide better interfaces for software and hardware accelerators.
The goal of this project is to revise the network traffic control infrastructure of Linux to overcome shortcomings of the existing architecture, and to make it more extensible.
In particular, we try to resolve the following issues that are present in other similar programs:
Create a more user-friendly configuration language
Provide interfaces for straightforward interaction with network management
Allow seamless integration of hardware accelerators
The code consists of two major components, the traffic control compiler tcng and the traffic control simulator tcsim. Both are described in some more detail below. Since tcng and tcsim share many support files (e.g. the whole regression test system), they are both contained in a single package, called tcng.
This site contains the source code and information directly related to tcng. Pointers to sites with information on traffic control in general can be found in the links section below.
This project started at the beginning of 2001 at EPFL ICA, continued until mid-2002 at Bivio Networks (tm), and has now become one of my spare time activities.
Enhancements:
- the "mtu" parameter in TBF is now optional
- tcsim now uses KVERSION[NUM] instead of KFULLVERSION[NUM] to avoid breaking if EXTRAVERSION contains multiple dots or other surprises (reported by Eduardo Grosclaude)
- scripts/runtests.sh now runs commands with LANG=C, to avoid localized error messages (reported by Eduardo Grosclaude)

Dragon is a powerful parser generator. It produces a consequent, object-oriented, integrated scanner and parser solution. Dragon parser generator also scales for very large grammar defintions. Since dragon parses LR(1) grammars, the generation algorithm is quite CPU intensive.
Using LR(1) instead of LALR decreases efficiency of the parser, but avoids some reduce/reduce conflicts in some cases. Dragon provides a very clean and structured way for the integration of application specific context code. Dragon combines the lexical and syntactical analysis and the corresponding code generation.
Enhancements:
- The switch option -y was added to switch between a dynamically allocated parse table or a static parse table.
- An escape feature was added for special token definitions.

CodeWorker is a versatile Open Source, licensed under GNU Lesser General Public License, parsing tool and a source code generator devoted to generative programming.
Generative programming is a software engineering approach interested in automating the production of reusable, tailor-made, adaptable and reliable IT systems.
In laymans terms, CodeWorker lets you generate code by parsing existing languages, or by creating and parsing your own language. Once a language file has been parsed, CodeWorker provides several techniques for generating code.
The tools scripting language drives the parsing and source code generation process. The scripting language syntax is derived from the C family of languages, making it familiar to most programmers.
The template syntax is like like JSP, ASP, or Velocity. It has variations for parsing, code generation, or functional programming, giving the developer a number of options for organizing CodeWorker projects.
Parsing
CodeWorker can be trained to parse almost any language and provides two distinct methods for creating parsers:
- the extended-BNF notation is declarative, and is a derivative of BNF (the Backus-Naur Form defines the grammar of a language) extended with regular expressions, predefined non-terminals and useful directives. Something close to javacc or to ANTLR in the JAVA world except a separate parser class is not necessary with CodeWorker. This means that parsing scripts can be tested without having to compile a separate parser class.
- Reading tokens is procedural and a somewhat obsolete now that CodeWorker handles BNF parsing scripts smoothly.
While parsing files, CodeWorker feeds nodes into a parse tree. A tree is a convenient structure to represent a hierarchical set of nodes, as in XML for instance.
The parse tree is populated by the parsing task, and used by the source code generation script to generate code, text or binary data.
Source Code Generation
CodeWorker can parse a language and use the resulting parse tree to generate source code via template-based scripts. One example is database DDL (Database Definition Language). CodeWorker has been used to parse DDL and generate large portions of a Java application.
CodeWorkers source code generation can occur in three ways: generation, expansion or translation.
- generation uses a script, much like JSP or PHP, to produce an output file. Only certain areas, called protected areas in the vocabulary of CodeWorker, are preserved in the file.
- expansion is used when small portions of an existing file need to be generated. The points where code is to be inserted are called markers in the vocabulary of CodeWorker, and code is inserted at the markers. The Class Wizard of Visual C++ generates code using this principle.
- translation mode is used when both parsing and source code generation are required to produce a file. Here are the description of two main families of use:
- source-to-source translation: a file must be rewritten in a different syntax. For example, a LaTeX file might have to be translated in HTML.
- program transformation: a source file has to change for optimizing, refactoring, instrumenting or rewriting selected portions. For example, a script could add a trace at the beginning of each function body of a JAVA or C++ source code. To do that, parsing discovers function bodies, and source code generation will insert the code that implements the trace.
Enhancements:
- Concepts of Aspect-Oriented Programming were added to code generation with joint points, advices, and point cuts.
- It allows a better separation of concerns inside a code generation process, leading to improved reading and maintenance of large and complex template-based scripts.
- A new BNF directive was added: #readPythonString.
- Some bugfixes and updates were made in the Eclipse plugin.

Glib::CodeGen is a code generation utilities for Glib-based bindings.

SYNOPSIS

# usually in Makefile.PL
use Glib::CodeGen;

# most common, use all defaults
Glib::CodeGen->parse_maps (myprefix);
Glib::CodeGen->write_boot;

# more exotic, change everything
Glib::CodeGen->parse_maps (foo,
input => foo.maps,
header => foo-autogen.h,
typemap => foo.typemap,
register => register-foo.xsh);
Glib::CodeGen->write_boot (filename => bootfoo.xsh,
glob => Foo*.xs,
ignore => ^(Foo|Foo::Bar)$);

# add a custom type handler (rarely necessary)
Glib::CodeGen->add_type_handler (FooType => ≥n_foo_stuff);
# (see the section EXTENDING TYPE SUPPORT for more info.)

This module packages some of the boilerplate code needed for performing code generation typically used by perl bindings for gobject-based libraries, using the Glib module as a base.

The default output filenames are in the subdirectory build, which usually will be present if you are using ExtUtils::Depends (as most Glib-based extensions probably should).

PHP HTML Form Generation and Validation Class is a PHP class for easy HTML form generation and validation.

If youre a web developer you know that designing HTML forms and writing the PHP code for their validation is a really dull task. And if youre like me you mustve looked around the web to see what you can find in order to ease this task.

I made this class first of all because being addicted to coding, I just had to. But what had me really thinking, after looking at some of others people work was: "cool, but what if I have to put the label on top of the text box and not to the left of it? or what if I have to put three controls in a row?" because the vast majority of the HTML form processors Ive seen were just adding the controls one beneath the other and as a webdeveloper I can tell you, besides the login window, I was never asked to build a form where all the controls are just one beneath the other... Now, I am sure that in some of them there were workaround for these things but I wanted it really simple. Oh, and another thing: I wanted the error messages generated by the form validation to be wherever I wanted not just on top, not just on bottom. I want them wherever I feel like theyre looking ok!

So thats why this PHP class is as straightforward as it gets: it provides an easy and intuitive way of handling both HTML form design - based on templates, where you can design your form any way you want, and basic server-side form validation. As this is a BETA version, currently there are only a few validation rules available but you can easily write custom validation rules, both for server-side and client-side.

It provides all the basic controls available in an HTML form plus a date picker control.

In order for the date control to work you must also download the PHP Date Picker Class from the downloads section and configure the PHP Form Generation and Validation Class by setting the datePickerPath property to point to the date picker class!

Youll get a better picture of what Im trying to say by downloading the class and running the example and browsing through the documentation

Suggestions, comments and requests are welcomed.

The code is heavily documented so you can easily understand every aspect of it.

Acovea implements a genetic algorithm for finding the "best" options for compiling programs with the GCC C and C++ compilers.
ACOVEA (Analysis of Compiler Options via Evolutionary Algorithm) implements a genetic algorithm to find the "best" options for compiling programs with the GNU Compiler Collection (GCC) C and C++ compilers.
"Best", in this context, is defined as those options that produce the fastest executable program from a given source code. Acovea is a C++ framework that can be extended to test other programming languages and non-GCC compilers.
I envision Acovea as an optimization tool, similar in purpose to profiling. Traditional function-level profiling identifies the algorithms most influential in a programs performance; Acovea is then applied to those algorithms to find the compiler flags and options that generate the fastest code.
Acovea is also useful for testing combinations of flags for pessimistic interactions, and for testing the reliability of the compiler.
Modern software is difficult to understand and verify by traditional means. Millions of lines of code produce applications containing intricate interactions, defying simple description or brute-force investigation.
A guided, deterministic approach to testing relies on human testers to envision every possible combination of actions -- an unrealistic proposition given software complexity. Yet, despite that complexity, we need answers to important questions about modern, large-scale software.
What sort of important questions? Consider the GNU Compiler Collection. I write articles that benchmark code generation, a task fraught with difficulties due to the myriad options provided by different compilers. For my benchmarks to have any meaning, I need to know which combination of options produces the fastest code for a given application.
Finding the "best" set of options sounds like a simple task, given the extent of GCC documentation and the conventional wisdom of the GCC developer community. Ah, if it were only so easy! The GCC documentation, while extensive, is also honestly imprecise.
I appreciate this style of documentation; unlike many commercial vendors, who make absolute statements about the "quality" of their products, GCCs documenters admit uncertainties in how various options alter code generation. Indeed, code generation is entirely dependent on the type of application being compiled and the target platform. An option that produces fast executable code for one source code may be detrimental to the performance of another program.
"Conventional wisdom" arrives in my inbox whenever I publish a new article. Ranging from the polite to the insistent to the rude, these e-mails contain contradictory suggestions for producing fast code.
In the vast majority of cases, such anecdotal assertions lack any formal proof of their validity, and, more often than not, the suggested "improvement" is ineffective or detrimental. It has become increasingly obvious that no one --myself included -- knows precisely how all these GCC options work together in generating program code.
I seek the Holy Grail of Optimization -- but exactly what is optimization? Understanding the problem is the first step in finding a solution.
Optimization attempts to produce the "best" machine code from source code. "Best" means different things to different applications; a database shovels chunks of information, while a scientific application is concerned with fast and accurate results; the first concern for an embedded system may be code size.
And it is quite possible that small code is fast, or fast code accurate. Optimization is far from being an exact science, given the diversity of hardware and software configurations.
An optimization algorithm may be as simple as removing a loop invariant, or as complex as examining an entire program to eliminate global common sub-expressions. Many optimizations change what the programmer wrote into a more efficient form, producing the same result while altering underlying details for efficiency; other "optimizations" produce code that uses specific characteristics of the underlying hardware, such as special instruction sets.
Memory architectures, pipelines, on- and off-chip caches -- all affect code performance in ways that are not obvious to programmers using a high-level language. An optimization that may seem to produce faster code may, in fact, create large code that causes more cache misses, thus degrading performance.
Even the best hand-tuned C code contains areas of interpretation; there is no absolute, one-to-one correspondence between C statements and machine instructions. Almost any sequence of source code can be compiled into different -- but functionally equivalent -- machine instruction streams with different sizes and performance characteristics.
Inlining functions is a classic example of this phenomena: replacing a call to a function with the function code itself may produce a faster program, but may also increase program size. Increased program size, may, in turn, prevent an algorithm from fitting inside high-speed cache memory, thus slowing a program due to cache misses.
Notice my use of the weasel word "may" -- inlining small functions sometimes allows other optimization algorithms a chance to further improve code for local conditions, producing faster and smaller code.
Optimization is not simple or obvious, and combinations of algorithms can lead to unexpected results. Which brings me back to the question: For any given application, what are the most effective optimization options?
Enhancements:
- Minor changes in the non-free license.
- Support has been added for the latest versions of libcoyotl and libevocosm.