Skip to main content.

Tuesday, September 19, 2017

With the hurricane incoming, I had to forfait visiting the Ise Jinja. I want to recover part of the visit shrinking the visit to Mitsue Jinja on 20/7.

20/9 09:00 – 13:00 Travel from Shirakawa-go to Ise.
20/9 13:00 – 14:00 Visit Oharai-machi.
20/9 14:00 – 16:30 Visit Ise inner jinja.
20/9 16:30 – 18:00 Arrive at Misugi Onsen.

21/9 08:00 – 08:45 Travel from Misugi to Mitsue.
21/9 08:45 – 10:00 Visit Mitsue Jinja.
21/9 10:00 – 10:30 Travel to Hasedera
21/9 10:30 – 12:30 Visit Hasedera
21/9 12:30 – 13:00 Travel to Oomiwa jinja
21/9 14:00 – 18:00 Visit Oo-miwa Jinja / iwakura jinja / sai jinja (Climb Mount Oomiwa?)
21/9 19:00 – 21:00 Arrive at Asuka.

Monday, September 18, 2017

When you say the calm before the tempest... Typhoon n. 1718 (the 18th of the 2017) is due to pass over Nagoya at around 21:00, yet the day is just cloudy and the wind is still.

The plan is meeting with my friend Kiyoshi in front of my hotel and then visit the Atsuta Jinja, the Nagoya castle and the Tokugawa Art Museum. For the ones not knowing Japanese history: the Tokugawa dynasty was the samurai family achieving the title of Shogun and creating the role of Taikun (a word known as tycoon in English) -- in opposition to the Japanese Emperor until the Meiji restoration in 1868. Or in other words, they were the legitimate rulers of Japan for over 300 years -- and Nagoya is the theater where the most dramatic scenes of their ascension to power take place, hence the museum dedicated to the art pieces they inspired or acquired is located in this city.

Sunday, September 17, 2017

And so, here we are.

As I get down from the flight, I am immediately facing the proverbial Japanese courtesy: at the immigration gate, a couple of gentle airport employee help me completing the filling of the immigration card (where you declare you're a good guy and how long is your visit). Also, the policeman at the immigration gate checks the card and reads the destinations I set as "address". He is a bit confused, (should be just one address, the one of the first hotel you stay in), but he compliments with me for both my Japanese and my list of destinations, and lets me pass in less than one minute.

Friday, September 15, 2017

Air France flight from Heathrow to Paris was late. Probably the news of a bomb in the London subway caused a bit of security hysteria. I had to run to reach my gate, a few minutes after it was "officially" closed, and all this because the french security check in the flight transfer area were changing turn and talking about the grades of their respective kids at school, and the luggage checker that was just entered in the turn at that moment was afraid a Big Ben souvenir I am bringing to my pen pal was, maybe, a perfume bottle holding more than 10cl. liquid.

However, I am in Seoul, and I already breath eastern air.

Here's the entrance of a free show about the Royal Palace in Soul airport.


Very eastern, isn't it :)
And so, after many years during which I had to keep reserved about my doings and my life, I am finally putting my life don the right track. And so, my old blog can come back to life too. And what better occasion to have it record my first vacation in years: three weeks in Japan, two of which visiting the peculiar locations I wrote about in my book Rai'an, and a third in Tokyo, working from Bloomberg Tokyo office.

My program will touch Nagoya, Shirakawa-go (a small village in the mountains which has been declared a world heritage by Unesco), Ise, Misugi-Mitsue in the mie prefecture, Hase-dera, Sakurai, Asuka, Nara, Kyoto, Sumoto in Awaji-shima and Takamatsu in the Shikoku, and I will be finally back in Tokyo.

Thursday, September 25, 2014

Tuesday, September 23, 2014

After 1 year of silence, I am finally able to break it. Although there are still some formal details to be processed, major changes are incoming in my life, so, the reasons that required me to keep silent about my current life and working status are vanishing.

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

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.