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):


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.

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.

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.

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.

Saturday, February 25, 2012

Uhm... not quite like this:



However, I introduced a concept in Falcon called "Mantra"; it's not visible at language level, at least not for now; it's a concept used in the engine. A Mantra is a basic entity that can be invoked, or better summoned in the engine or in a module. Namely, now it's either a Function or a Class. After searching a bit in the literature for a concept capturing this two concepts in one definition, I found nothing precise, so I picked this ... rather spiritual ... but adequate name.

Saturday, December 31, 2011

Wow, looking at the dates I see that more than 2 months have passed since my last article.

The effort to fire up my new business was quite distressing, and the complexity of the things that we're doing in Falcon required an effort that was beyond my expectation. In particular, I've been coding 12-16 hours straight a day since last Tuesday (it's Saturday) to complete the reflective syntax support; now the basics and the skeleton of the system is done, but I need some help to fill in the gaps, so I am describing the system here. This text will go also into the VM/Falcon specifications when we organize it.

One fast note; as a preliminary work for this step, I removed the PCode system. For those who didn't follow the development, PCode were a set of pre-ordered expression PSteps to be specially executed by the VM. In the beginning, that seemed an optimization, so that the PCode could run multiple Expression PSteps before returning the control to the VM for new code to run, but that required the expressions to behave differently from all the other psteps (by not removing themselves when their execution was complete, and by considering their CodeFrame host untouchable), and also would have required re-compilation of the Host pcode when the expressions were changed. In the meanwhile, I found a PStep execution pattern that doesn't require the explicit intervention of the VM, and that is even more efficient than the original PCode idea; so we removed the PCode, and now the expressions, the statements and in general all the PSteps share the same exact behavior and have very similar execution patterns.

Sunday, September 25, 2011

Falcon has an elected web application platform called "Nest" (Falcon Nest...) which we're intensely developing and that's becoming ready for production services by the hour.

Initially, the only modular element in the picture was a so called "Service", a type of standardized module that could have been interacting with other services in a page, and that would have had to be "configured" (actually, programmed) on-site. For instance, a "Form" could have been a service, as a whole "Wiki". The idea is quite interesting for self-contained entities as the "Login" service, where the rendering of the login form, the check of the authorization level and other related activities can be tracked to a single conceptual entity; or, in simple database-table editing, where the form must just read and then store data in the required record; you just need, and most of the time just want, a very simple way to perform some consistency checks before storing data in the database, and then you're done.

Thursday, September 22, 2011

I've been full force on some other projects for sometime now, but I urged to get back to the new engine -- also for business reasons. My intention is to dedicate a bit of care to it every day from now on, but today I worked all the day on it to get back in touch with the new API and the problems that were left open on the ground.

Today I have fixed a couple of nifty details that were left open: the booleanization of items (a = "value"; if a ...), which is now overridable, and safe and consistent cleanup of the execution context in interactive compiler.

Also, I have added grammar for both range declaration ([x:y:z]) and range accessor (x[a:b:c]). I dragged those a bit because they were extremely delicate and complex to integrate in the new array declaration syntax (which actually opens a simple, but powerful sub-parser for improved parsing of functional expressions).

Now I am searching for some ppl at #falcon implementing the implementation of range access in strings and arrays (functions are already in, we just need to copy some glue code from the old engine).

Well, we're back in action.

Wednesday, August 17, 2011

And so, we got try/catch statement working in the new organic virtual machine. Funny enough, it just took 3 days (less, actually) instead of the year it took with the old machine, and I was even able to add a finally keyword that would have been nearly impossible to be added in the old engine, with just a few touches more. Another proof, if it was needed, of the potential of the new engine. Here follows some details about what it took and what this is determining.

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: