The development for ChaiScript has officially moved to github.

It's important to share something about the development process we have at ChaiScript.

• We never make a commit unless the commit passes all unit tests.
• We never commit a new feature without an accompanying unit test.

What does this mean to you, the user? Mainly it means that even though we have not pushed out an official release in nearly a year, git master branch always represents a stable release.

If you want the latest and greatest version, with confidence that it will be stable, simply grab the tar (or zip) ball from github. Also, with github doing the hosting for us, it's very easy for anyone to fork the project and submit pull requests back to us. So if you've been waiting to contribute to ChaiScript, the wait is over, go ahead and fork and flaunt your stuff.

As far as the general state of the project, the changes since the last official release are almost too numerous to count.

1. In many ways the code has been simplified. This has resulted in some runtime speedups and some runtime loses.
2. Documentation is moving to doxygen for all official docs. This will eventually result in far better organized docs with more clear examples. This documentation process will be completed before the next official release is made.
3. boost::function is supported as a first class object during dispatch and casting. This means you can pass a ChaiScript function object to a C++ function expecting a boost::function<> and the code will Just Work. This is pretty cool and results in a lot of neat potential uses. More examples to follow as the docs are updated.
4. A huge amount of work went into allowing introspection into ChaiScript functions. You can now query functions to see how many parameters and of what types they expect. Or if the function is overloaded, you can query how many overloads there are and pull apart each one. If the function is a ChaiScript function (as opposed to one written in C++) you can walk through its eval tree and modify the eval of the function if you desire.
5. Many more unit tests have been added checking type conversions and other aspects of the system. This has resulted in several dozen small bug fixes in corner cases.

Anyone looking to make contributions right now should look at function serialization. We can parse functions and walk them, but we cannot write them back out yet. Other interesting possibilities include JSON or YAML support on some level.

Personally, besides documentation, I will be working on making C++ POD types intrinsic to the system. Currently every type and every operation that exists is a C++ function callback. This makes the overhead much greater than it needs to be for simple operations like 4+5. We made the decision to build the system like it is for flexibility but have decided that ultimately the project needs the performance (both compile time and runtime) of having POD types built in. Initial investigation shows about a 30% compile time improvement and about a 30% runtime improvement for loops once these changes are made.