Skip to main content


Seems the package handling is more complicated than I supposed to, but, I've got a working version. It's gotta be reviewed first before I'll post more details, anyway, this is a major step forward (I've implemented ten different Package systems previously until I got it hopefully right). Stay tuned ;)

LaTeX and packages

I've been working lately on two main projects: The new package managment for niven and a LaTeX package.


Writing a package for LaTeX isn't that complicated, the problem is the lack of good documentation - most books I found describe how to use LaTeX and don't mention even commands like \ifx. I used the following two books:

  • LaTeX2e for class and package writers

These two cover most of the subjects that are needed to write a simple package. The second one really just a reference, while the first book gives you examples how to add for example options to your package. Both are really worth reading - my LaTeX package offers now both support for technical books and "normal" books which are meant for print (for a pet project - from time to time, I'm writing on a book).


niven's package system is currently in its 8th revision, this one is a fairly good looking one though :). When finished, it will be able to load and store any kind of object that the user defines into packages. Packages are the only way to serialize data in niven, and they provide a container for objects. They also provide means to distribute the content easily. The current system is different from the other ones as it stores object instance information in a wrapper object and not in the object itself - i.e. you access objects via ObjectHandle<Type> and not via Type*. This sounds complicated first, but it turns out to be rather easy when you use it. Packages have an advantage over storing the content in plain files (let's say, .jpg) as they store type information and dependencies, meaning it's possible that one package is linked to another package. A good example is a map where several objects use the same texture, no need to store it several times. So much for now, as soon as I get the 8th revision ramped up and working I'll get back to you.

AnkhSVN and the WiX Toolkit

Recently, I tried AnkhSVN again - and it worked. For some time, the builds had problems, but the latest build works fine again. Read on to see what AnkhSVN is. Another thing that is working again: Niven's MSI based installer - again, read on for more details.


AnkhSVN is a Visual Studio add-in that allows you to use SVN directly from within the Visual Studio. Click on the screenshot below to see how it integrates into the IDE.

AnkhSVN in action

With AnkhSVN, you don't have to switch back and forth to the explorer when working on a SVN repository except for larger tasks like branching. But for everyday work, it safes you a lot of time and really works out of the box. Go and get it ;) !


WiX is Microsoft's OpenSource toolkit for creating Microsoft Installer installations. Basically, you have a bunch of XML files which contain the UI, your product information and the source files, compile it and finally link it into a distributable MSI file. WiX works great, Niven's original installer was based on it but not updated for some time. Today, I took a look at the new features and fixed the installer so it's working again:

Niven's MSI based installer

When I get a bit deeper into customizing the UI (at the moment, I can't figure out the right resolutions for the various pictures which leads to ugly artifacts) I'll post about it.

Thoughts on scripting

I mentioned script-driven classes, without going into detail what I mean with this. Read on for some thoughts on scripting. Note that nothing of this has been implemented, and it is mostly just ideas that I carry around without having time to implement them properly.

The script side

The scripts would run in some kind of ScriptVM, probably a stack-based machine. Calling script code from C++ would invoke populating the stack with the appropriate parameters, and invoking a script method. The script method names and their parameters would be stored in some global array inside the ScriptVM. When a script is called, the ScriptVM processes each of the compiled opcodes and operates on the script stack only. If another scipt function is invoked from a script, the operation would be the same as if it was called from C++.


The simpler side. Calling scripts would mean: The user knows what variables the script expects and what function. With a script function void func (int, int):

ScriptVM->stack->push<int> (param1);
ScriptVM->stack->push<int> (param2);


This way is more difficult. A possible solution is that when a C++ class is made scriptable, a new wrapper class is generated. For example, assume we have a C++ call void func(int,int);. The wrapper would look like this this:

extern "C" void scr_func (Stack& stack) 
    int p1 = stack->pop();
    int p2 = stack->pop();
    func (p1, p2);

So much for now, maybe I get some prototype working, then you'll get more ideas.