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.

Saturday, November 29, 2008

僕の夜 (Boku no yoru)
町匂う風 (Machi niou kaze)
余を撫でる (Yo wo naderu)

La mia sera
vento che sa di città
mi accarezza

This Evening of mine
Wind carrying the city scent
is caressing me

(Multilingual haiku in 5-7-5).

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

Look at this code:

GarbageString *str = new GarbageString( vm, (const wchar_t *) Sys::dynlib_voidp_call( fa->m_fAddress, bufpos, bufsize ), -1 );
vm->retval( str );

It sounds equivalent to this:

const wchar_t *ws = (const wchar_t *) Sys::dynlib_voidp_call( fa->m_fAddress, bufpos, bufsize )
GarbageString *str = new GarbageString( vm, ws, -1 );
vm->retval( str );

But for Visual C 2005 it's not so equivalent. In release build the second one crashes; the reason is in the fact that dynlib_voidp_call() mangles with some registers via assembly, apparently, but a wise compiler should not rely on register persistence across foreign function calls. Also, the problem is in the ws variable. It seems its value gets lost between the return from dynlib_voidp_call and the call on the next line. Be warned...
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.

Wednesday, November 05, 2008

From today's chat in (Sun OS distro) official channel.

<evocallaghan> World is d00med !
<jonnymind> Or maybe, world is unrealized.
<jonnymind> Ya know, Unreal is more popular here in Europe.
<cypromis> witcher
<cypromis> the world is witcherised
<cypromis> lol
<cypromis> and everybody is moving to second life anyway
<cypromis> Life 2.0
<cypromis> and that before Life 1.0 even reached alpha stage