Skip to main content.


This is the archive for April 2009

Monday, April 27, 2009

There was a cute bug in last Falcon bleeding edge release ( that prevented to load modules in system that had name spaces in directory names. This was due to the new URI naming convention, which wasn't widespread enough in the engine. Thanks to the prompt report of some fellow user I've performed a complete re-release, and I also took the occasion to release a VS9 enabled package.
The Fibonacci(30) test is rating an impressing 0.90s with VS9; however, it's still a bit early to benchmark. Also, I had a test with Power Shell and VS9; everything seems fine now.

This new fixes a couple of nasty bugs in the module loading/addressing code; we're really squeezing bugs and the 0.9 branch is becoming stabler by the hour.

Thursday, April 16, 2009

Self commenting.

We're sorry, Mr. Obama...

Thursday, April 09, 2009

I am particularly proud if this interview on ComputerWorld Australia, and for three good reasons. First, this is the first interview that has been directly proposed to me by the journalist, rather than being us hunting for media exposure. Second, because I've been given full space to explain my reasons and motivations in depth, and I've been given also the possibility to pinpoint some interesting technical detail. There aren't technical details worth exploring a language by themselves, but the details I have explained are interesting because they show the care put in reaching the specific targets we wanted to achieve.

Third... because the article bears the best recent photo of mine that's around on the net!


Wednesday, April 01, 2009

Falcon 0.9.0 was deemed "bleeding edge" for various reasons, but mainly because it failed some tests on some architectures. Most notably, it was messing up all the threaded tests on Win32/Mingw, and it crashed at random (once every 5-10 launches) on tests 38a or 51a (with different errors as malloc asserts, bus errors, segfaults etc) on some old Fedora based virtual host.

The type of error (its errand behavior), the fact that it appeared in the only tests forcing GC from the VM (while forcing GC from outside, activating the -M memory collection switch, everything was fine), the fact that previous versions were totally immune led me to think there was some concurrency error in the new GC, or some randomic behavior due to concurrency in sending the items to the GC and collecting them.

I'll cut the story short: the problem was simply that the ItemList, on which the new CoreSlot (message broadcasters) are based, and that is also the inner core of the List class in the Falcon language, has an internal list of active iterators. The list marks the iterators, and the iterators, when they are inside a Falcon iterator instance, mark back their owner. But if the GC destroyed the list, the iterators were still considered valid, and when they were to be destroyed, they tried to unlink themselves from the owner list...

Unluckily, this rarely (if ever) crashed; instead, it seems that it just dirtied the heap on every platform I tried (including VS8 with memory tracing enabled), and that may have caused (or not) a memory corruption detection on subsequent tests.

Oh, well, at least I checked line per line the mempool code twice, and now I can be sure that the new GC code is absolutely stable and consistent everywhere. This old error helped me to nail a couple of problems in the code that may have become a nasty nuisance later on.