Skip to main content.

Archives

This is the archive for July 2011

Saturday, July 30, 2011

I have been enlightened by a Great Truth(TM) today. Programming (without adjectives) may be something else, but Good Programming (TM(tm)) is all about giving names to things, or, I may say, "dubbing".

I've been struggling to reintroduce auto-operators (+=, ++, postfix ++ & family) in the Organic Virtual Machine for a couple of days; and a couple of "my" days, so, something 16 work hours per day.

Thursday, July 28, 2011

After a couple of days of work, I have found that the only sensible way to allow dynamic loading of modules is that to create references for static data and let those to be separately managed by the garbage collector.

Consider strings, arrays of flat items or even user-defined classes that might go in the static data of a dynamically loaded module. If some item is take from by the user of the loaded module and sent around, it must stay alive as long as needed. If necessary, it must even keep alive the module that is hosting it, otherwise it should just stay around even after the module has died. I wouldn't love to keep a plugin around just because it has returned "OK" from inside a function it exposes, and that OK is kept somewhere for future records...

Adding the requirement that anything that goes or may ever go outside the dynamic module boundaries must reference the module back would be a nightmare. It may make sense for (some) classes and functions (and I think we can lower this requirement to the external/native code ones) but it's totally unreasonable for i.e. strings. Also the reverse requirement, that is, that a module must stays alive 'till all the data born from it are gone is pretty heavy.

So, the only sensible way to handle plugin-based dynamic (dischargeable) modules is that of making their static data references as soon as the module is linked dynamically in a virtual machine. When the module is gone, the reference items might still be around and keeping alive the related data.

For this reason, re-introducing the references was in order before completing the module loading system.

In the process, I also improved the usability of references that was somewhat limited in the old engine. Here follows a talk about it in our #falcon chan at irc.freenode.net:

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.




Thursday, July 21, 2011

One of the main reasons to rewrite the Falcon engine was to fully support Functional programming at parser level.

There are some extensions, or we may call them "dialect", that greatly rely on functional programming, up to the level of writing entire modules of several hundred lines in functional sequences. Of course, it is necessary to have full compiler support into those long sequences, so that an error in the sequence body gets pinpointed and the compilation can proceed in search for further errors.

Wednesday, July 20, 2011

Well, the A register still exists; but now it's completely ruled out from the inner (new) function management, and it doesn't play any role in the call frame.

I took the occasion to get rid of other minor details in the generation of the call frame and in return routine.

As a result, I achieved another 5-10% performance increase in the non-optimized recursive fib test with respect to the old engine. Now it's consistently 20%-33% faster than ever before. And the VM model is now even simpler and more linear.

Tuesday, July 19, 2011

Today, I have completed the OOP model constructs in the Falcon new engine. Some details (for instance, Class states, or a direct way to generate a sub-classed prototype via a single call) remain yet to be dealt with, but they are largely things that I can complete later or that I can leave to be completed by the other developers in the project.

What I want to talk about in this entry is 1) the findings about the engine that I have discovered, and 2) the short term plan.

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).
A funny thing about the orgainc VM is that it has several way to do things:
* You can push a PStep to the code stack. -- that's the most direct way.
* You can push a PCode, which is a list (in reverse order) of PSteps to be evaluated by the VM in "one step".
* You can push a Statement, which is a special PStep (with a little of self-awareness).
* You can push a SynTree, or a derived class, which is a list of statements to be executed in the given order.
* Finally, you can "call a function", which is generally performed in a single step. If the function is a Falcon source function, then the VM pushes a new call frame in the call stack, adds the syntree which embodies the function code to the code stack and starts executing that.
* Or, if you really want to go fancy, you can add your own call stack frame and push psteps, pcodes, statements or syntrees that will be interpreded as executed in a new function.

Sunday, July 10, 2011

After a bit of experiment and talk with ppl on the channel, we have approved the idea to introduce a typed prototype programming in Falcon. While blessed dictionaries (or a kind of object we could introduce in this version) are a "random" collection of data and behavior, prototypes a-la-falcon shall be classes whose structure is mutable in runtime. The difference with respect to classes is that prototypes can be altered, and the difference with respect to typeless objects (i.e. blessed dictionaries) is that the structure of data and behavior is shared across all the instances of a prototype.

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.