Thursday, September 25, 2014
Amazon Kindle: http://www.amazon.it/gp/product/B00NWHJFOK?*Version*=1&*entries*=0
And finally Google Play: https://play.google.com/store/books/details/Rai_an?id=GyubBAAAQBAJ
Tuesday, September 23, 2014
I took the occasion in a gap between my professional occupations to finish my long novel: Rai'an (future peace).
Click here for being linked there.
The novel is in Italian, so, if you don't understand this language (I might be biased, but is common saying that it's one of the most beautiful languages in the world), it will be useless to you, I am afraid.
It's about a time travel back to Japan of the Hei'an period, around the year 1000. However, the time travel is just an excuse to be able to place a modern scientist in an ancient environment.
Although there is adventure, romance action, there's much space also for a historic reconstruction of the everyday living and generic cultural environment of the pre-medieval Japan. This period is one of the most mysterious in the history of Japan, as not much documentation has come to us, except for the very probably much embellished stories that the Imperial Court wrote about itself. In fact, modern researches are revealing many aspects of the culture, everyday living and religion of the place and time that was nearly unsuspected just 10-20 years ago. In this novel, I am trying to explore the ancient Japan as it's being revealed by the most advanced researches in the field.
So, if you can read Italian, and are into time travel and/or ancient Japan stuff, jump in and have a look at my Lulu showcase.
Update: E-book now added. Here you can read an extended preview, before buying from the above link.
Friday, April 19, 2013
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
This is a first Hangout we had last night (this time, in English).
Friday, April 05, 2013
I did a preliminary test, and I liked it. Here's our first try (sorry, in Italian):
Wednesday, April 03, 2013
【IT英語】ravioli code : [名] ラビオリコード / 俗語ですが、過度に構造化されたコードを意味します。関数分割しまくって、２～３行の関数が大量にあるような状態とかですね。ちなみにラビオリとは、イタリア風ぎょうざのことです。— codic / ネーミング辞書 (@codic_project) 03 aprile 2013
Too precious not to incorporate it...
Monday, January 21, 2013
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.
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
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:
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
I have reshaped the draft a bit, and added relevant parts
for what concerns:
- The management of group runnable context limits
- The message queue structure
- 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
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
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
When it will be complete, I'll move it to the Falcon documentation site.
Comments are welcome.
Friday, July 13, 2012
"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
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
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.