--
CIL (C Intermediate Language) is a high-level representation along
with a set of tools that permit easy analysis and source-to-source
transformation of C programs.
CIL is both lower-level than abstract-syntax trees, by clarifying
ambiguous constructs and removing redundant ones, and also higher-level
than typical intermediate languages designed for compilation, by
maintaining types and a close relationship with the source program.
The main advantage of CIL is that it compiles all valid C programs
into a few core constructs with a very clean semantics. Also CIL
has a syntax-directed type system that makes it easy to analyze and
manipulate C programs. Furthermore, the CIL front-end is able to
process not only ANSI-C programs but also those using Microsoft C
or GNU C extensions.
tla is an Arch CLI written in C.
Arch is a revision control system, i.e. a system that makes it easy to
track changes to computer files, mostly the source code to complex
software systems.
It has the following features that set it apart from other revision
control systems, such as CVS, Subversion or Bitkeeper:
- distributed repositories
- advanced merging capabilities
- low barrier of entry : everybody can easily publish their changes to
others projects. Repositories can be hosted on HTTP, FTP SFTP and
WebDav server.
- renames handled
- archive signing and integrity checking : a facility by which the
integrity of a publicly accessible archive can be verified.
Submitted and maintained by Laurent Cheylus <foxy ta free tod fr>
Embedding tests allows tests to be placed near the code its testing.
This is a nice supplement to the traditional .t files. It's like XUnit,
Perl-style.
This is a simple developer's tool for finding circular references in
objects and other types of references. Because of Perl's reference-count
based memory management, circular references will cause memory leaks.
Assertions are the explict expressions of your assumptions about the
reality your program is expected to deal with, and a declaration of
those which it is not. They are used to prevent your program from
blissfully processing garbage inputs (garbage in, garbage out becomes
garbage in, error out) and to tell you when you've produced garbage
output.
When you're writing unit tests for code that deals with tainted data,
you'll want to have a way to provide tainted data for your routines to
handle, and easy ways to check and report on the taintedness of your
data, in standard Test::More style.
When the code you're testing returns multiple lines, records or data
structures and they're just plain wrong, an equivalent to the Unix
"diff" utility may be just what's needed.
ok sturm@
"Module::Build" is a system for building, testing, and installing Perl
modules. It is meant to be a replacement for "ExtUtils::MakeMaker".
Developers may alter the behavior of the module through subclassing in a
much more straightforward way than with "MakeMaker". It also does not
require a "make" on your system, most of the "Module::Build" code is
pure-perl and written in a very cross-platform way.
ok sturm@
"ExtUtils::ParseXS" will compile XS code into C code by embedding the
constructs necessary to let C functions manipulate Perl values and
creates the glue necessary to let Perl access those functions.
ok sturm@
This module can build the C portions of Perl modules by invoking the
appropriate compilers and linkers in a cross-platform manner. It was
motivated by the "Module::Build" project, but may be useful for other
purposes as well. However, it is not intended as a general
cross-platform interface to all your C building needs.
ok sturm@
Class names in Perl often don't sound great when spoken, or look good
when written in prose. For this reason, we tend to say things like
"customer" or "basket" when we are referring to
"My::Site::User::Customer" or "My::Site::Shop::Basket". We thought it
would be nice if our classes knew what we would prefer to call them.
This module will add a "moniker" (and "plural_moniker") method to
"UNIVERSAL", and so to every class or module.
ok sturm@
