Welcome to GeniusDex * WEB
This website contains various write-ups, articles and other pages about the various things I fill my spare time with. You can find an overview of the most recently changed articles just below this introductory message.
Most of the time i'm working on IRC related things. I'm an author of Anope, an IRC services package, and various other open-source projects. More information about these projects and other IRC related stuff can be found via the Coding and IRC links at the top of this page.
Anope Progress / IRC Cantus
Today we have released Anope 1.7.20. The bugtracker is nearly empty -- the one bug remaining is probably fixed but we're waiting on full confirmation -- and we're confident that the current codebase of the 1.7 series is pretty stable.
The next step is to fix up all documentation and other documents included in the release so that they are all up-to-date and do not give old instructions to people. Once this is done we can pack up a first release candidate for 1.8.0. Basically this means that 1.8.0 will finally hit the streets in the upcoming 2-3 months.
What will happen once 1.8 is the new stable branch? We will be working on Anope2, a rewrite in C++. The core of this rewrite will not be exclusive to Anope: any project building some sort of u:lined service should be able to use this core. The core will be developed together with the people from Denora. This helps to assure that the core does not get Anope specific, and it reduces the development effort required per developer to a doable level.
The core has been labeled IRC Cantus. There is not much official for that yet, apart from a very early web page with the logo on it. Once there is more info available I will post more updates on IRC Cantus.
On quitting and SVG drawing
I stumbled over this blog today about the GNOME quitting system and some ideas for it. It's all rather technical at the start, but at the end I found some text I do like:
It would be better if they (the applications) were to save the file temporarily someplace else, and then restart in the same place they were before; including the undo/redo buffer reestablished. In this way logging out becomes a non-destructive operation. You don't loose your state, but you also don't have to commit to a particular version of a file.
I do agree that it would be very nice if your state remains intact over a reboot. This way, you can turn off your computer just as easy as getting into standby without worrying about losing work. Ofcourse standby would be faster to get into and out of, but completely powering off your machine has it's own advantages as well.
A few months ago I came over a blog post about vector drawing with OpenGL. It sure sounds interesting to move all SVG processing to the GPU so the CPU can be busy doing 'actual' work instead of caring about how things are displayed. The speed gain seems to be pretty big: using the GPU to draw 100 bezier curves is about 20 times faster than doing it in software; note also that nearly all of the CPU time used earlier is free now since the GPU does the work.
This also could be a solution for something that annoyed me slightly during the beta 1 days of KDE 4. When resizing a fully SVG-themed game, updating the screen took a considerable amount of time. During this there was not really much to see or do. I do not know if this is already fixed in recent versions, but if the GPU could render it in a fraction of a second while the CPU continues to care about it's own business this problem would be virtually non-existent.
It will sure be interesting to see a SVG rendering library utilising the GPU to do it's job. I'm not aware of any library doing this yet, but I do think that in not too long there will be an attempt at doing this properly. If anyone spots such a library, let me know.
NWERC 2007
It's time for another programming contest this weekend: the ACM 2007 Northwest European Programming Contest, or NWERC 2007 for short. The R in NWERC is for Regional instead of Programming; I didn't make that up ;)
I'll be competing with the same team as the BAPC where we reached the fifth spot. I'm counting on a place in the upper half at least, hopefully somewhere in the upper regions of the entire competition. The problem set will be available afterwards, probabaly from the NWERC site.
For the BAPC, the problems sets can be found on the BAPC site at http://www.bapc.nl/?p=problems.
Using dlsym() in C++
I've spent quite some time on this problem, and it keeps popping up every time I'm coding with dynamically loadable modules in C++. The POSIX-interface to use dynamically loadable modules (libdl) defines a number of C functions to work with these modules: dlopen() and friends.
These functions are all nice in that they work nicely when used in C++ with one major exception: dlsym(). This function is used to find a symbol inside a dynamically loaded module. The symbol which is looked up can be any symbol: a pointer, a variable, a function, etc. The way to return a pointer to some unknown type is by using a void pointer.
Returning a void pointer might seem logical for this, but there is one big problem: it can return either a variable or a function. There is no issue when type-casting a void pointer to a pointer to some other type. Type-casting a void pointer (which is in essence a variable) to a function pointer is not that straightforward: function pointers can be fundamentally different.
Imagine a system where there are separate memories for code and for data. Because the system works with loads of code but small amounts of data, the code memory will need 32 bits pointers while the data memory only needs 16 bits pointers. The void pointer returned by dlsym() will be a pointer to data: it will be 16 bits. When this is actually a function, it has to be type-casted to a function pointer, but that requires a 32 bits pointer. There is no way that all 32 bits can be retrieved from the 16 bits of information we got from dlsym().
It is because of the above example that the behavior of type-casting between data-pointers and function-pointers is undefined in C. Most compilers nevertheless provide working behavior for this though, and it is exactly this behavior that the dlsym() function requires. In the revised C99 standard, it is mentioned as a common extension to the language.
When it comes to C++, the C++ Standard Core Language Defect #195 is exactly about this issue: converting between function and object (data, variable) pointers. They've worked out a (not yet officially accepted) proposal to fix this issue: on implementations which can provide this sort of casts it works and on implementations which cannot provide a cast between function and object pointers the cast would either be undefined or throw an error or warning during compile time.
With the default warning levels, most compilers do not complain about casting an object pointer to a function pointer. I, however, tend to code with certain strict checking flags on to catch some small mistakes or ambiguities that might get in my code. When compiling the module code of IRC Cantus , about which i will blog soon, this means that I will get a warning every time i use dlsym():
g++ -W -Wall -g -pedantic -g -O2 -export-dynamic -I../include -c cantus.cpp
g++ -W -Wall -g -pedantic -g -O2 -export-dynamic -I../include -c argument.cpp
g++ -W -Wall -g -pedantic -g -O2 -export-dynamic -I../include -c config.cpp
g++ -W -Wall -g -pedantic -g -O2 -export-dynamic -I../include -c log.cpp
g++ -W -Wall -g -pedantic -g -O2 -export-dynamic -I../include -c log_facilities.cpp
g++ -W -Wall -g -pedantic -g -O2 -export-dynamic -I../include -c main.cpp
g++ -W -Wall -g -pedantic -g -O2 -export-dynamic -I../include -c module.cpp
g++ -W -Wall -g -pedantic -g -O2 -export-dynamic -I../include -c modulesupport.cpp
modulesupport.cpp: In member function ‘void module::Instance::open()’:
modulesupport.cpp:85: warning: dereferencing type-punned pointer will break
strict-aliasing rules
modulesupport.cpp: In member function ‘void module::Instance::close()’:
modulesupport.cpp:109: warning: dereferencing type-punned pointer will break
strict-aliasing rules
g++ -W -Wall -g -pedantic -g -O2 -export-dynamic -I../include cantus.o argument.o
config.o log.o log_facilities.o main.o module.o modulesupport.o -o cantus -ldl
This warnings obviously ruin the clean, warning-less output I would get without these issues ;) For now there is no way to get this to compile without warnings without dropping some of the warning reporting flags, which is obviously not what I want. There seems to be no solution to this problem at all; people I ask about it do not come any further than joking about the choice of wording for type-punned...
CodeCup 2008
Today the first test competition of the CodeCup 2008 will be held. The CodeCup is a yearly programming competition where you have to write a program which plays a multiplayer (usually 2 players) game. The games are usually variations on board games.
This year's game is Alquerque, a variation on checkers. You start with a board filled with white and black squares and have to take turns in capturing each other's pieces. The first to catch all of the opponents pieces or trap the opponent wins.
The final competition will be played on January 19th, so there's plenty of time to come up with a decent solution. You can submit programs in C, C++, (Free)Pascal, Java (1.5) and Python.