Skip to main content.

Friday, April 19, 2013

Our Hangout with Kunal and Vasudev from India.
We talked about their experience, how to organize the new documentation and new exciting features in the upcoming Falcon 1.0.


Sunday, April 14, 2013

As we're wrapping up the Alpha 1.0, we'll be doing some hangout to talk about ... our things :D.

This is a first Hangout we had last night (this time, in English).

Friday, April 05, 2013

I thought it would be a good idea to have weekly or periodic net meetings to be shown on the net, to talk about Falcon, but also about coding, and about anything us coders like to talk about (music, animes... :D).

I did a preliminary test, and I liked it. Here's our first try (sorry, in Italian):


Wednesday, April 03, 2013




Too precious not to incorporate it...

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.

Monday, December 10, 2012

The parallel scheduler as designed in the Falcon Organic Virutal Machine specification is complete, at least as a proof of concept.

I will merge the work in the new_engine branch in hours, and this starts the last development cycle leading directly to the release of Falcon 1.0 alpha.

The work from now on starts going in the release code. As we proceed into finalizing the code, it's time to start working on the test suite and documentation.

Things that must be done prior issuing the alpha are mainly:

  • Review symbol/variable relationship to simplify it.

  • Add asynchronous item R/W.

  • Review the module loading API to simplify it and make it more organic with the new VM.

  • Finish the garbage collector (mostly already in place; mainly, it's a matter of finalizing the API).

  • Finish the grammar for the parser (a couple of advanced constructs are still to be ported).

  • Bring in the relational programming model (actually, it's a matter of a couple of extra grammar rules).

  • Port the old modules.



The engine as it stands now it's way faster than the old 0.9 series, and it's currently at par or superior to LUA and optimized python 2.7 in many aspects. There are still things we can work on to make it even a tad faster, but the introduction of asynchronous item R/W might reduce the performance of about 10-20% on some symbol access (I think I can have local variables free of this burden), but we gain transparent, simple and powerful parallel programming constructs which can counterbalance this loss hands down.

One thing that must be fixed in this final review is the way modules are loaded in the virtual machine. Up to date, the new engine module loading scheme was loosely related with the old 0.9 engine, where the modules could be compiled or saved through a separate set of functions. In the original Falcon, module compilation and serialization could have been performed even through a separate library, and when I coded the new engine I tried to retain this separation.

However, the introduction of the fully reflective code, which is the DNA of our organic machine, definitely requires a different approach. Even if non of the code usually compiled in a module currently requires that, any element that can be serialized might require the help of the virtual machine to complete some parts of its serialization. Prior to the introduction of the parallel scheduler, this help was part of an interactive process of the upper application using the Falcon engine, a VM and a single context. Now that we have multiple processes, each with its own multiple context, things must be handled a bit differently (and more transparently for the host application).

The following scheme shows the main entities involved in module serialization:

Module Space Scheme

A "module space" is a set of modules that, once deserialized or injected in the virtual machine, form a common space for global variables and exported symbols. They can be organized in a hierarcy, so that a plugin module compiled or loaded by a Falcon program can live in its own module space, and once the plugin is unloaded, all the sub-modules it references can be disposed with it, without polluting the global symbol space of the application.

However, loading modules might require to run some code. Their main function is usually (but not necessarily) to be run prior their loader can receive them. Also, while currently it's never the case, some of the code in the module might require the virtual machine to perform some operation to help in the storage/restoring of the element.

For this purpose, we can now use a specific Process entity which can be executed by the module space to complete the deserialization.

The module space uses a private module loader, which can use a compiler to load source Falcon files, a FAM loader to load pre-serialized modules, or a dynamic library loader to load modules stored in system dynamic libraries.

Also, it will use a storer to serialize the module (via a ClassModule handler) to a stream, in case compiled modules are to be saved transparently as FAM modules.

Specularly, the FAM loader will use a restorer to read the serialized FAM modules.

Both the storer and the restorer might (atm theoretically) require the virtual machine to execute some code; this was previously performed by configuring a VMContext with the operations to be performed, and then notifying the storer/restorer owner about the need to run that code. With an asynchronous, automated Process entity around, this might actually change into something more transparent, and the invocation of code might be done directly by the storer/restorer classes, while the owner could just wait on the process for the storage/restoring (and eventually, for the call of the main() function of a module) to be complete.

Doing this will simplify the API and, leveraging the existing multithreaded Falcon engine, it should even result in being a tad faster thanks to the exploiting of I/O dead times in the parallel environment.

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.

Friday, September 28, 2012

I have developed a much more detailed and stable document, on which I am finishing the parallel programming part of the new FOM.

The specification explains the detail of the shared resources and messages primitives that the organic machines presents. In this way, it's also a good documentation of the code I am writing, as it explains the relations between the objects that can be found in the virtual machine code.

You can download it here.

Thursday, August 16, 2012

I am currently working on some iOS app in need of localization, and the lack of support from XCode is simply blinding.

To be more precise, the support offered is more damaging and backfiring on the programmer than being actually of any help.

I wrote a small falcon script that substitutes the ominous "genstrings" tool in generating a Localizable.strings file, which takes care of recycling previously translated strings, merging new strings found in the development files and eventually purging old unused strings.

It's a simple little toy you can download it here.

(And yes, it works with the currently available Falcon packages for mac OSX).

EDIT: I have also come out with some interesting "best practice" advises that I might share on the blog in a few hours.

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.


Friday, July 13, 2012

At times, I feel proud to share my ancestry with Dante. Here is Ulysses, which tells Dante how he instilled in his crew the will to sail forth unknown seas past the Gibiltair strict, which, at that time, was considered "the end of the world":

"O frati," dissi, "che per cento milia
perigli siete giunti a l'occidente,
a questa tanto picciola vigilia

d'i nostri sensi ch'è del rimanente
non vogliate negar l'esperïenza,
di retro al sol, del mondo sanza gente.

Considerate la vostra semenza:
fatti non foste a viver come bruti,
ma per seguir virtute e canoscenza".

"Oh brothers", I said, "you, that moving forth across
hundred thousands perils came to the West,
to this border so tiny,

of what's still left to see
don't take away anything from our senses
of what lies behind the sun, of the uninhibited world

And remember your seed:
you weren't made to live as beasts
but to follow virtue and knowledge".

「我が友よ」、といった、「君たち幾千危険に向いて、
西の方へ着てして
この小さな限界に

我々の意識から残った物の
あの日の裏の、人間がないの土地の
経験を取らないでくれよ

出原をわすれるなよ:
獣のように生きるために作くられたわけがなくて、
作られた理由のは偉さと知識を遅うためなんだよ!」と

When I re-read this words, I still can feel the pride to be a Tuscan, an Italian, a Human.





Saturday, June 16, 2012

I came out with a good plan to implement pointer-to-item symbols in the Falcon new engine, so I am writing them down to implement them in the next day.

First a bit of context: falcon always used a special item, containing a pointer to another item, to implement the reference-to-item construct. This construct is visible at script level through the $ operator (explicit reference), and is used internally for assignment expansion (a,b,c = vector_of_three_data), pass-by-reference, variable closure and a few more things. The presence of this construct requires every operation to "dereference" its input, causing an extra if-and-ptr-deref practically at each single variable fetch. Performance killing apart, this construct is making me sweat in the implementation of the new dynsyms and varying code constructs; so I decided to get rid of it once and for all.

This requires that every symbol points to a value (an item), instead of being "calculated" as a physical location in a special vector (the globals vector or the local stack); a value that, in some case, can change depending on the context (the same local symbol will point to different items depending on the frame stack where it is accessed).

Traditional solution to this problem was lazy binding of symbols, but this requires a map scan at each access, in the most naive implementations; better solutions have been developed, but they are all sub-optimal with respect to the access by vector base + displacement we use for local variables.

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.

Wednesday, May 23, 2012

I couldn't let go untold the 20th anniversary of the death of Giovanni Falcone, a just man, or just a man, who fought mafia and payed his obedience to his duty with his life; and with him, in a blast of fire ignited by 500 kilos of TNT, his wife Francesca Morvillo, and the men of his armed escort, Vito Schifani, Antonio Montinaro And Rocco Dicillo.

In this photo, Falcone is with his best friend, colleague and companion in his fight against mafia, Paolo Borsellino, who knew in the moment Falcone was killed that he was a dead man walking. Yet, he called for his confessor and then went on fulfilling his duty, till the next 19 July, when some 200 kilos of TNT were used to blast him and his escort away.

Falcon and Borsellino

Every Italian knows that it wasn't properly the mafia to kill this men; very dense evidences, we might even call them proofs, point to the fact that the two were killed as they found out the links between criminal organizations and major political parties, and through them, to the government-run most important institutions of our country. A set of common interests that was born soon after WW2, through the intense activity of both the Italian and American secret services. But here the trails get fuzzy and misty, and that's not the topic of my post.

This is also the tenth anniversary of the writing of the first line of the Falcon Programming Language. I was back from a hard day of underpaid work, while my pocket radio was playing the recordings of the police radio frequencies as the bomb blew 10 years before. I still remember the voice of the show host, on the brink of crying in the recall of the event, explaining that the code name for Falcone was "big personality", as it was a bit more than a tad overweight, and nice enough to accept jokes about this. And the recorded dialog was something like:

"They hit a big personality. I repeat, a big personality was hit."

And the policeman on the other side, his voice down to a broken whisper: "Received."

As I recalled his famous quotes, "I have no fear of dying. Who has no fear dies just once; who has fear dies thousands times every day", and especially "A man can die, but ideas don't", I took the decision to do something on my way back home from the train station. And so I sat all night long and had a first toy compiler running by the next morning.

I am going to have a sip of wine tonight to cheer at the 10th year of Falcon, at the 20th year of the death of a just man, and at the 20th year of an idea of justice and rightfulness being born.

Tuesday, May 01, 2012

Lately, in the Falcon Programming Langauge IRC channel (#falcon on irc.freenode.net) I presented the idea of a concept-relation programming paradigm, which would superseed some fuzzy logic, constraint programming and logic programming constructs.

The idea is based on a first try where I modeled the analysis of complex systems through networks of "emergence", connected by possibly recursive causal relationships, as described by Edgard Morin in its masterwork "The Method".

Here I publish a first draft of the idea extended to generic networks of arbitrary concept bound by arbitrary relations.