Skip to main content.


This is the archive for November 2008

Sunday, November 30, 2008

It took about 2 full days just to prepare the packages, the ground for the packages, test them, repackage also the modules that were impacted by the changes and so on, but now it's done.

Well, almost. Still need to make a new release of the SDL module. Will do in a couple of hours.

It seems that open source is all about releases; and in part it's true. OTOH, for a developer there are but a few things as distressing and time consuming as making a release (with downloadable packages). And I still have to do house cleaning stuff as SVN tagging, spreading the news to the packagers in the various distro and the like...

Next time I must repeat the mantra: "Making a release takes a week... making a release takes a week..."

For the curious; if you're asking yourself why this release is called Vulture, it's because it fed on Condor.

Wednesday, November 26, 2008

Ok, so we'll have a bugfix release to consolidate some very relevant bugfixes we have performed in this couple of weeks.

Also, we'll go for a major number, as one bugfix introduced a binary incompatibility. To be correct, it was not a bugfix; I just had some unclean interface (the relatively obsolete UserData class) that leaded me to write an unclean code in a secondary module (sdl_image binding). I can't resist fixing unclean things, and I thought that if this can lead me to write unclean code, it would certainly drive others in the same errors. Although UserData was the main mean to do reflection before, while it is now just a residual quick-but-not-dirty resource to write a binding quickly, it has still a role, so it will stay in 0.9. If it has to be cleaned, better now than later.

The release is scheduled by the next saturday.

Monday, November 24, 2008

It wasn't originally my intention to release a bugfix version before 0.9, which is due for mid-january. The point is that I nailed down a couple of nasty bugs really fast, and I took the occasion to add a couple of interesting things that I was going to add in 0.9 anyhow. Also, if I didn't make any relevant mistake, the code is currently binary-compatible with 0.8.12, and so other modules and applications compiled with it doesn't need re-compilation. So, I'd like to consolidate the bugfixes before changing definitely the inner 10,000 lines composing the core of the system to prepare them for the final round of 0.9->1.0.

I wonder if I should call it or 0.8.14...

Saturday, November 15, 2008

Being hit once by your own decision is part of the life game, but being hit twice is more than I can stand. In the initial development of Falcon, I thought that the protection provided by the special path for load/import directive was enough to distinguish Falcon modules from system modules. I was right, but there was another aspect I didn't take into account: that Falcon modules may need to dynlink those unprotected libraries.

Example: the SDL module. The Falcon module was called on POSIX and sdl.dll on Windows; on POSIX, system libraries as the SDL system, require a "lib" prefix, so the dynamic library needed by the Falcon module is "*". Pitifully, on Windows it's not the same; SDL system is driven by SDL.dll. The Falcon module loader is anyhow able to load the proper falcon module on "load sdl" command, but the OS dynamic linker resolves the request of the module for the system SDL.dll into... a request to load itself!

As a result, Falcon SDL module is temporarily named fsdl. When the same thing happened with ODBC module, I decide that in release 0.9 we'll have a sensible suffix attached to falcon module names, for example "sdl_fm.dll", so that we can "load sdl" without confusing the module loader nor the system dynamic linker.