Skip to main content.

Archives

This is the archive for July 2011

Tuesday, July 26, 2011

As a part of the redesign of the new Falcon engine, I have cleaned the dependencies of the Falcon interactive mode to readline (GNU/GPL) and editline (BSD). For who doesn't know, these are two libraries that allow history navigation and a bunch of other features at a console prompt, which came pretty handy while trying code snippets and expressions in the interactive mode.

Readline is widely available, embedded in bash and a bunch of other important system tools all over the POSIX world. Editline is a son of a lesser God, but it still does the job fine, and has a more detailed, extensible API. Unluckily, readline has superior support for internationalization, while utf-8 and wchar_t structures have been introduced in editline only recently, and they are supported only through the system-wide setlocale() facility. Finally, editline is hardly portable outside Posix world (but that's a minor problem, as MS-Windows console has now a "reduced" but still useable console line editor burned in).

We'll have to improve the editline support. I think we can find volunteers helping out in this task, and then sending the patches upstream.

Monday, July 25, 2011

The problem with symbols in a programming language is in the fact that they represent a value, but are NOT a value. You can take them as flexible pointers to values, and this means that the real values must be stored somewhere else.

There is also another problem: symbols are themselves data, and so, they themselves must reside somewhere. Since values and symbols are never in a 1:1 relationship, you need a way to ensure the following conditions at the same time:

  • The value of a variable (named by a symbol) must stay alive at least as long as the symbol is accessible.

  • Symbols must stay alive as long as there is some grammar element or code referencing them.

  • Values, symbols and their container must be collected as soon as possible when they are not used anymore. In short, they must not leak.




Sunday, July 17, 2011

I think it's pretty natural to make some silly mistake when you dig into a very deep, complex and obscure programming structure. Especially if this structure is relatively new.

However, the last couple of errors I nailed (completing the HyperClass system in the new engine) are disturbing me a bit.
Here are the updated references.

Comments are welcome.

The Docbook source.
The PDF version.

Wednesday, July 13, 2011

I am preparing an illustrative article indicating the most interesting elements of the new engine for a media launch (mainly through on-line open-source focused magazines). I am taking the occasion to write a little more than needed for the articles, so that the extra material can be used for an official guide to the VM/Engine, or possibly even a book.

This is the first part, covering the introduction and the basics of the new VM. I know there are developers at #falcon that wanted to know a bit about the working principles of the new engine to lend a hand, so they may find this guide useful.

I'll put more material up in the next days.
The Docbook source.
The PDF version.

Tuesday, July 12, 2011

Ammitedly the model is complex, but not convoluted.

The compiler generates FalconClass instances out of the language "class" keyword. A user, from C++ code, might synthesize a FalconClass as well, but that's usually not what you'll want to do.

If one of the base classes declared in the inheritance at language level (or added in the inheritance list if synthesized from C++) is not a FalconClass instance, then a HyperClass holding the master FalconClass and its dependencies is created. Instance of the two things are different both at creation and at runtime, but they are seen by the engine as the same thing (actually, any user class is seen exactly the same by the engine).

Friday, July 08, 2011

It's been a while since I last wrote an entry on my blog. This depends on the fact that I switched occupation, and now I am working on a very delicate and complex project.

As the people in the #falcon IRC channel know , the point is that the project involves -- heavily -- Falcon, to the point that, since this week, I am programmatically dedicating 4 hours per day to Falcon (while, in precedence, I was able to dedicate no more than one day per week to it).

Things are getting interesting on the development side, both in terms of speed of development and of technology that is being put into Falcon.

For this reason, I decided to keep a diary about how the development is progressing.

In this moment, some developers are writing a Falcon module for blog writing, so at some point we'll switch to the proper area for project blogging in the Falcon site, but in the meanwhile, I don't want my considerations about the development of the new engine to get lost. So, I will be reporting about the progress of the development here, starting from today, and resuming what has been done during this first week of full-immersion into Falcon.