delegate.c implements an abstract function pointer by capturing a user-specified callback signature -- delegate() -- and exposing it through a simple interface -- invoke(). It provides something loosely approximating lambda expressions; or even more analogous, C# delegates. It includes a wrapper to support libevent callbacks to functions not matching the required libevent callback signature.
The goal of dzo is to treat application database objects the same way the application's source code is treated, with respect to development, revision control, and deployment. Dzo uses a text file that contains native create statements for all database objects and compares them against the actual database-schema. As a result, dzo creates the SQL statements needed to update the database schema (or you can let dzo execute the SQL statements directly). If your application lives in a Tomcat or Java EE application server, dzo has a servlet that controls the deployment process, inspects and executes the necessary database changes, and finally deploys the application. Dzo currently works with HSQLDB, MySQL, Oracle, PostgreSQL, and SQL Server (more to come).
eLua (Embedded Lua) aims to introduce the programming language Lua to the embedded software development world. Lua is the perfect example of a minimal yet fully functional language. The aim of the project is to have a fully functional Lua development environment on a microcontroller (Lua interpreter, modules appropriate for microcontroller environments, and editor) without the need to install a specific toolchain on the PC side.
ftracer is a simple user space implementation of a Linux kernel style function tracer. It allows you to trace every call in instrumented user applications. It is useful for debugging and performance analysis due to its fine grained time stamp. This allows you to do control flow oriented debugging without any special instrumentation. So if the program does something unexpected, it's easily possible to look at the function calls before that, and use that to deduce the cause of the problem. ftracer relies on gcc generating a call on top of every function call. The tracing slows every function call down (about 3x). The tracing is per thread and does not create a global bottleneck. It supports a dump function in C, directly callable by the program or on exit, and a gdb function to dump from gdb.