Skip to main content.

Thursday, September 25, 2014

Monday, January 21, 2013

I am facing a fairly big dilemma on whether to always enable the parallel programming support on the scripts side of the new engine of Falcon or not. Doing that costs some 50% performance on the mean case, but not doing that has heavy consequences. Also there might be solutions combining the bests of both worlds that I simply overlooked, that is, a way to perform the heavy operations needed to ensure item write visibility consistency across agents that are not so heavy as the simple, but effective, way I am using now.

I wrote the following post in the Falcon Programming Language Goolge group; I am repeating it here on my blog to show it also to those ones that have no access to that resource.

Hey ppl,

I need an informed opinion from the community on how to clear a problem, and I don't want to have just one mind set on this. I need more brains on this problem, so, if you can think on this and possibly spread the challenge, you'll be doing some great favor to all the future users of our language.

Sunday, September 30, 2012

Update: completed with VM stacks.

I have reshaped the draft a bit, and added relevant parts
for what concerns:

  1. The management of group runnable context limits

  2. The message queue structure

  3. The environment wait handlers management

I think that the general description part is now complete, maybe excluding some detail about process termination. The parts concerning the context stack(s), the items and the execution of the PSteps is still to be imported and fixed from the older VM description, but it can be maximally cut & pasted in place.

You can get the fourth draft here.

Wednesday, August 15, 2012

I have written down a first draft (very rough) of the falcon 1.0 organic VM specification. It's missing the stuff that I have wrote in the "Introduction to the Organic VM", I will transcribe and update it asap, and a new section about the memory model, but it provides a nice overall discussion of the high level design of the new virtual machine. Here it is.

When it will be complete, I'll move it to the Falcon documentation site.

Comments are welcome.

Saturday, May 26, 2012

I am pretty into ancient literature, exp. oriental ancient literature. So, I am doing a bit of personal researches on the book of Tao and other ancient masterpieces, and being totally fascinated.

One of the most interesting things about the Dao-de-jing (known as the Tao-teh-ching because of the outdated but still common Wade-Gilles transliteration) is that the translations into western languages are flawed by basics misunderstandings about the ancient Chinese language; more or less, serious western studies of the Chinese language started 100 years ago, and they were sort of amateur-like for many years.

Long story short, there's a wealth of ancient oriental literature waiting to be discovered anew if you just care to scratch the surface a bit, and see what's behind; and even one of the most studied books of all the times, the Dao-de-jing, makes no exception.

Sunday, March 25, 2012

... And after more or less one year since we started the new engine development, we finally have completed the whole of the engine logic. The last entity needed to have a somewhat complete engine, where everything can built upon, that is, the module serialization, has been achieved a few hours ago.

Tuesday, October 25, 2011

We're dealing with a pretty critical element of the Falcon new engine: the serialization process. Serialization is extremely important in the new engine because it actually serves many purposes.

  • Storage of built-in type values on static streams.

  • Saving and restoring of pre-compiled source code modules.

  • Assistance in creation of stateful programs across multiple sessions (game save/load, session data on web base applications).

  • Cooperative programming and live data sharing across network nodes.

Tuesday, August 02, 2011

The new engine has now partial capability of load submodules and supports import/from statements in all flavors.

What's still missing in the module loading process:

  • Precompiled module serialization-deserialization.

  • Binary module load (but it's a cut-&-paste from old engine).

  • Namespace definition.

  • Macrocompilation.

But as usual, this element of the new engine is already more powerful that the corresponding one we previously had in the old engine, being able to finely address sources or other module generation devices, differentiating module URIs from module logical names since before the load starts and making the load/import relationship explicit at any step of the process. This makes possible some progress that were not feasible with the old engine, as, for instance, a finer control of plugin modules (and their dependencies) and the import/in self statement that shall allow to copy the global namespaces of other modules (creating module "collections").

Also, this second target makes the new engine structurally complete. This means that now the new engine, for how still experimental and rudimentary, is able to stand alone and test itself. Every part of the "main loop" is complete; everything else that must be done from now on is just "gap filling" work. The overall structure of the engine, the modules, the garbage collecting system, the symbol integration and sharing, the item model and anything that's vital to the Falcon Programming Language is either completed, advanced, or drawn, however is not anymore "on paper". It's here.

This also means that "outsiders" might now be able to work on the new engine to help complete it. So, from now on, we should be able to proceed faster.

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.