Forum

I have just made another release of the Voodoo Compiler.

The new release, version 0.4.1, addresses a couple of issues with code generated for the Netwide Assembler and code generated through the code generation API.

It also contains a new test case that uses the code generation API.

I know it has only been a few days since the release of version 0.3.0 of the Voodoo Compiler, but I didn't want to keep this from you:

Voodoo Compiler v0.4.0 has been released, and it supports AMD64!

Other new features include:

- Default target architecture configurable with configure script

- configure sets default target architecture based on host architecture

- Support for the Yasm assembler

Also, I have expanded the test cases included with the distribution. They should now cover the whole Voodoo language.

The AMD64 code generator probably does not generate the very best code, but it works and it passes all the test cases. I have factored out the common code among the i386 and amd64 code generators into a separate class.

Now that the compiler officially supports multiple architectures (with different word sizes, even!) I think it is time to start thinking about the features that should be in the 1.0.0 release ...

I have just released a new version of muhttpd: version 1.1.3.

This releases fixes a few minor bugs in the #includes and in the documentation.

I have just released version 0.3.0 of the Voodoo Compiler.

Major new features in this release are:

- An API for generating code directly from Ruby programs

- A new code generator that creates ELF object files (in addition to the existing code generator that generates NASM assembly code)

- Makefile targets for installing the compiler

- Documentation (rdoc documentation for the Ruby API and a manpage for voodooc)

Next, I will be working on a code generator that generates AMD64 code. A framework for plugging in new code code generators is already in place.

A friendly netizen calling himself "jfk" was kind enough to report a bug in muhttpd: new connections are handled by forking a new process (as is usual on Unix), but muhttpd handled connections in the parent process while continuing to listen in the child process, instead of the other way around.

The result of this is that, on each connection, the pid would change, making things like stopping muhttpd by killing a pid stored in a file not work.

The bug has been fixed in the new release: 1.1.2

Thanks, jfk.