I've been so busy that I didn't even had the time to put down this notes recently.
Long story short:
Parallel programming is writing programs where one or more parts are designed to potentially or actually run at the same time on different computational nodes (processors, computers, co-processors).
Multithreading programming (or simply threading) consists in using a set of tools to control physical computational parallel resources, together with their physical synchronization and sharing devices. Some multithreading structures abstract the final physical layer, but MT never gives completely off the ability to control the minute instruction flow on every processor you have at your disposal. Mutexes and MT-wise semaphores (i.e. MS-Windows events or POSIX condition variables) may be implemented differently on different processor architectures, but their point is granting that the underlying processors and/or the operating system tightly bound to it will do a set of operation granting some specific behavior of the hardware.
So, is MT parallel programming? -- No, but you can DO parallel programming with MT tools/programs/libraries. When using MT, either you want to control the underlying hardware parallel abilities for other reasons (and you don't want to mess with the raw ASM needed to do that), or you're writing your own parallel programming environment, for how simple it is, to make your program to do tasks in parallel.
After some years in the field and in the field of programming languages, I finally came to the conclusion that high level languages, and especially scripting languages, doesn't need MT. Worse, exposing MT-level operations and concepts to high level scripts (threads, mutexes, and so on) can harm more than help.
What you want when using a low level language is to be low level as low as you can, but not lower. In C and C++, you want threads, CPU affinity masks, mutexes, condition variables. What you want when you use an high level language is to be high level as much as you can, but not more. Like, doing all the messy stuff of a whole C program in a couple of well-designed instructions or commands. You want to tell the system the LOGIC of your THOUGHTS, and then you want the system to do the stuff for you.
In short, the next Falcon version will have threads and parallel structures removed, and will embed threading in the language itself, not differently from Erlang or Ocalm. Coroutining may be reviewed as well, and be considered a special case of threading. The idea is to be able to define parallel code, and find the compiler (for what can be told at compile time) and the VM (for the runtime conditions) to run it "as parallel as possible". A VM may be assigned the limit of 0 thread, thus making all the parallel code to run as coroutines.
More on the upcoming idea in the next post.
Monday, June 28, 2010
Tuesday, June 15, 2010
Black is white, up is down and short is long!. I'd vote for Al Yankovic to be dubbed mankind heritage. Or nobel price. Or something.
I would, but I am wrong, so I won't.
I would, but I am wrong, so I won't.
Monday, May 24, 2010
Yes, Twitter can be good. At times, is just useful to share small thoughts.
So I added a tweet panel right on the sidebar of this blog, to see if I can make some good use of it. I thought it may be interesting to keep fast notes about Falcon development and other everyday issues there.
However, it can't hurt, can it?
So I added a tweet panel right on the sidebar of this blog, to see if I can make some good use of it. I thought it may be interesting to keep fast notes about Falcon development and other everyday issues there.
However, it can't hurt, can it?
Tuesday, May 11, 2010
Last night we (Maik, Paul, Luca and me) had an interesting talk on "variable classes". Many scripting languages allow to change the structure of a class, and doing so, changing the runtime structure of the instances they have generated. Although this is generally regarded as "horror" in terms of object oriented programming, and relying on this is considered a bad practice, Maik and Paul (exp. Paul) convinced me that the thing has "a meaning" when profiling the an application at design/setup time.
Also, if specifically constrained and shaped down with the help of well-defined language extensions, as the type contracts we're designing, altering a class may not be as bad as it sounds.
Also, if specifically constrained and shaped down with the help of well-defined language extensions, as the type contracts we're designing, altering a class may not be as bad as it sounds.
[ Read More... ]
Wednesday, April 14, 2010
When the believer asks: "Hey, you're skeptic, but why should I trust YOUR point?"
The true skeptic answers: "You shouldn't. That's the point."
The true skeptic answers: "You shouldn't. That's the point."
Thursday, April 08, 2010
Ok, the problem with the "opaque object* and class handler" model I just posted about is inheritance. But it's a problem even now, as pure CoreObject derived entities cannot be inherited at all, while more complex FalconObject based entities can inherit only from ONE non-pure falcon base class.
This should fix the problem and allow interface-based classing to work.
The system is based on 3 classes: the dear old CoreClass implementing pure language-level classes, a base abstract class for manipulation of foreign data (UserClass) and a class glueing the two, called HyperClass. A new CoreClass can be derived from any count of base CoreClass parents; it knows that its opaque "object" is actually an array of items parallel to its property table (and there's a good news about property tables too). The CoreClass is meant to be final (or nearly so).
UserClass doesn't provide any default way to access its properties and makes no assumption on the nature of the opaque data used as object to be manipulated.
The HyperClass is created when linking a CoreClass with a UserClass-derived entity. As the new model doesn't require anymore a VM to be there to link a final class, nor the class structure declaration to be unmodifiable, the CoreClass itself can perform its own link (up to the constructor call). If all its parents are CoreClasses, it will return itself modified so that it has the union of properties provided by the parents (using the current logic). If one or more parents are not CoreClasses (if they are user or hyper classes), it creates an HyperClass that will take its place.
The Hyperclass knows its opaque structure to be an HyperObject, that is, an array of opaque pointers where the element 0 MAY be occupied by an item array storing data coming from the CoreClasses, while the others are the opaque pointers known and manipulated by each non-CoreClass parent.
The HyperClass handles its properties differently from CoreClasses: it holds a list of HyperProperties each indicating the owning class (after link resolution), the position of the owning class in the HyperObject array (0 if the parent is a CoreClass) and, in case the property is coming from the CoreClass hierarcy, the position to access the property.
In this way, if willing to access a property provided by a UserClass (of which Falcon knows nothing about the internal object manipulation logic), it will just hand down to the right class the request to get that property on an opaque data of the type that the UserClass is expecting to manipulate.
In case of explicit subclass access (i.e. HyperClass.BaseClass.prop), the process is even simpler. If the BaseClass is a CoreClass, we simply ask for the default value of that property (as defined by our standard); if it's a UserClass, we simply hand down the request for that property to the UserClass, feeding it with its own data (Note to me: a flag should indicate if we're taking the default property via the baseclass access).
The HyperClass fits also the interface object picture.
Interfaces are inherited exactly like objects. When forming an HyperClass, if a subclass provides an interface object (i.e. the sequence interface for hooking into for/in, or the array subscript interface), the winning interface gets wrapped into a HyperInterface for the same task, which records that interface and the position in the HyperObject that must be passed to that interface if invoked.
This makes possible to turn all the basic structures into UserClasses, with the ability to be even derived. The special callback hooks used for operator overload can force language-based CoreClasses to push in the hierarcy a standard InterfaceObject, whose action is that of calling the required callback. This allows, for example to override the language-defined action for an Array (declared as a UserClass) providing a __getIndex callback on a language level Array subclass (implemented as a CoreClass at module level, and becoming a HyperClass during the link step).
... cool, huh?
This should fix the problem and allow interface-based classing to work.
The system is based on 3 classes: the dear old CoreClass implementing pure language-level classes, a base abstract class for manipulation of foreign data (UserClass) and a class glueing the two, called HyperClass. A new CoreClass can be derived from any count of base CoreClass parents; it knows that its opaque "object" is actually an array of items parallel to its property table (and there's a good news about property tables too). The CoreClass is meant to be final (or nearly so).
UserClass doesn't provide any default way to access its properties and makes no assumption on the nature of the opaque data used as object to be manipulated.
The HyperClass is created when linking a CoreClass with a UserClass-derived entity. As the new model doesn't require anymore a VM to be there to link a final class, nor the class structure declaration to be unmodifiable, the CoreClass itself can perform its own link (up to the constructor call). If all its parents are CoreClasses, it will return itself modified so that it has the union of properties provided by the parents (using the current logic). If one or more parents are not CoreClasses (if they are user or hyper classes), it creates an HyperClass that will take its place.
The Hyperclass knows its opaque structure to be an HyperObject, that is, an array of opaque pointers where the element 0 MAY be occupied by an item array storing data coming from the CoreClasses, while the others are the opaque pointers known and manipulated by each non-CoreClass parent.
The HyperClass handles its properties differently from CoreClasses: it holds a list of HyperProperties each indicating the owning class (after link resolution), the position of the owning class in the HyperObject array (0 if the parent is a CoreClass) and, in case the property is coming from the CoreClass hierarcy, the position to access the property.
In this way, if willing to access a property provided by a UserClass (of which Falcon knows nothing about the internal object manipulation logic), it will just hand down to the right class the request to get that property on an opaque data of the type that the UserClass is expecting to manipulate.
In case of explicit subclass access (i.e. HyperClass.BaseClass.prop), the process is even simpler. If the BaseClass is a CoreClass, we simply ask for the default value of that property (as defined by our standard); if it's a UserClass, we simply hand down the request for that property to the UserClass, feeding it with its own data (Note to me: a flag should indicate if we're taking the default property via the baseclass access).
The HyperClass fits also the interface object picture.
Interfaces are inherited exactly like objects. When forming an HyperClass, if a subclass provides an interface object (i.e. the sequence interface for hooking into for/in, or the array subscript interface), the winning interface gets wrapped into a HyperInterface for the same task, which records that interface and the position in the HyperObject that must be passed to that interface if invoked.
This makes possible to turn all the basic structures into UserClasses, with the ability to be even derived. The special callback hooks used for operator overload can force language-based CoreClasses to push in the hierarcy a standard InterfaceObject, whose action is that of calling the required callback. This allows, for example to override the language-defined action for an Array (declared as a UserClass) providing a __getIndex callback on a language level Array subclass (implemented as a CoreClass at module level, and becoming a HyperClass during the link step).
... cool, huh?
Talking with the people in #falcon IRC channel (at irc.freenode.org), we worked out the concept a bit, and we found out that the best place where to store the interface objects is the Falcon "CoreClass" instance.
The CoreClass has the meaning to describe what Falcon can do with the data you pass. Rather than storing the knowledge of how to handle the object in the CoreObject hierarcy, we can think of the object as a totally opaque entity, and store all the knowledge about it in the CoreClass.
This allows embedders and modules to provide totally opaque data (their data) and separate it from the code that Falcon should use to handle it.
The way to associate CoreClasses with the opaque data they should handle is still under investigation. One option is that of just storing the class and its opaque data in the item, but then we must make sure that a method creation (obj.mth) has a way to refer the class. Shouldn't be too hard in the new model we're developing, as the methods may now have a back-reference to the classes from which they come from.
Another option may that of having a pool of pre-allocated small buffers where the opaque-data / handler-class pair can be stored, and then store that pointer in the items. This has the advantage that we're sure that the opaque data can never be disconnected from the class, but it requires extra allocation, memory management and dereferences.
The current coupling of methods and objects on which they operate solves a problem similar to this, and has been proven one of our most solid assets since first alpha release; so, keeping the pair class/opaque-object or method(class)/opaque-object directly in the item structure seems a very smooth and viable solution.
The CoreClass has the meaning to describe what Falcon can do with the data you pass. Rather than storing the knowledge of how to handle the object in the CoreObject hierarcy, we can think of the object as a totally opaque entity, and store all the knowledge about it in the CoreClass.
This allows embedders and modules to provide totally opaque data (their data) and separate it from the code that Falcon should use to handle it.
The way to associate CoreClasses with the opaque data they should handle is still under investigation. One option is that of just storing the class and its opaque data in the item, but then we must make sure that a method creation (obj.mth) has a way to refer the class. Shouldn't be too hard in the new model we're developing, as the methods may now have a back-reference to the classes from which they come from.
Another option may that of having a pool of pre-allocated small buffers where the opaque-data / handler-class pair can be stored, and then store that pointer in the items. This has the advantage that we're sure that the opaque data can never be disconnected from the class, but it requires extra allocation, memory management and dereferences.
The current coupling of methods and objects on which they operate solves a problem similar to this, and has been proven one of our most solid assets since first alpha release; so, keeping the pair class/opaque-object or method(class)/opaque-object directly in the item structure seems a very smooth and viable solution.
Thursday, March 25, 2010
One element of the new object model in the next falcon must surely be the "interface object".
Interface objects are pure abstract class which the final object can expose to Falcon engine. For example, implementing the "dictionary" interface means to expose a Dictionary* object (which is actualy a virtual table pointer) that must be returned implementing something like getDictionary() class. For example:
And of course, the default for get*Interface() function would be that of returning 0, to let the users know that the required interface is not available.
Problems of this model are mainly two. First, adding an interface type requires to break binary compatibility and also a full recompilation of all the modules. Second, but that's a minor issue, the interface require initialization with "this" during constructor, and that raises a warning on many compilers; also, it suggests storing the "this" pointer in the base class, which makes the Interface base class not fully abstract.
Finally, it would be highly desirable to provide the ability to "expose an interface" even to user-provided classes (i.e. its own application classes) without the need to build a wrapper coreobject.
I am figuring out how to solve this problems.
Interface objects are pure abstract class which the final object can expose to Falcon engine. For example, implementing the "dictionary" interface means to expose a Dictionary* object (which is actualy a virtual table pointer) that must be returned implementing something like getDictionary() class. For example:
class MyDict: public CoreObject
{
MyDict():
m_idict( this )
{}
...
virtual DictionaryInterface* getDictionaryInterface() { return &m_idict; }
...
private:
class DictForMyDict: public DictionaryInterface
{
... reimplement the abstract methods from DictionaryInterface
}
m_idict;
};
And of course, the default for get*Interface() function would be that of returning 0, to let the users know that the required interface is not available.
Problems of this model are mainly two. First, adding an interface type requires to break binary compatibility and also a full recompilation of all the modules. Second, but that's a minor issue, the interface require initialization with "this" during constructor, and that raises a warning on many compilers; also, it suggests storing the "this" pointer in the base class, which makes the Interface base class not fully abstract.
Finally, it would be highly desirable to provide the ability to "expose an interface" even to user-provided classes (i.e. its own application classes) without the need to build a wrapper coreobject.
I am figuring out how to solve this problems.
Thursday, March 11, 2010
I have finally been able to release a quite stable bugfix of Falcon version 0.9.6.4. So I took a breath and had a look around and from high above, so that I can plan a good roadmap for the next version.
Also, I notice that my blog is pretty sparse on Falcon. Despite it absorbing a vast part of my everyday life, I rearely write about it in the blog; I prefer to "do" rather than to "argue". Yet, today a couple of questions about some arguments in the Newsgroup have fired the considerations I usually keep for myself, or for the few people on our chat channel.
I immediately thougth that writing some ideas, doubt, solutions down here is much better than keeping them for myself, so I'll be using my blog to keep track of what is going around my mind about Falcon much more regularly from now on.
The achievements I want to obtain in the next version are the final stabilization of the Embedding/module writing API, together with the new Item model and the new compiler/moduler/linker triplet. If it seems ambitious, it must be considered that those elements are tightly interrelated, and cannot exist without each other. So the fix order must be:
Deep item/garbage model -> Item framework -> Syntactic tree -> Module/VM/Runtime -> Compiler
Also, some iterative process will be required. A redesign of the inheritance resolution pattern will require to do a first VM/Link passage, and then continue again into the Deep/item garbage model.
More tomorrow.
Also, I notice that my blog is pretty sparse on Falcon. Despite it absorbing a vast part of my everyday life, I rearely write about it in the blog; I prefer to "do" rather than to "argue". Yet, today a couple of questions about some arguments in the Newsgroup have fired the considerations I usually keep for myself, or for the few people on our chat channel.
I immediately thougth that writing some ideas, doubt, solutions down here is much better than keeping them for myself, so I'll be using my blog to keep track of what is going around my mind about Falcon much more regularly from now on.
The achievements I want to obtain in the next version are the final stabilization of the Embedding/module writing API, together with the new Item model and the new compiler/moduler/linker triplet. If it seems ambitious, it must be considered that those elements are tightly interrelated, and cannot exist without each other. So the fix order must be:
Deep item/garbage model -> Item framework -> Syntactic tree -> Module/VM/Runtime -> Compiler
Also, some iterative process will be required. A redesign of the inheritance resolution pattern will require to do a first VM/Link passage, and then continue again into the Deep/item garbage model.
More tomorrow.
Wednesday, February 24, 2010
Today, in Italy, in the country where the prime minister left arm and founder of its Party is under trial for participation in Mafia organizations, and where the Prime Minister is under trial for judge corruption, for the FIRST TIME IN THE WORLD, network service providers have been condemned to jail because of a video leaked on the network they are in charge of administrate by a user.
Original article (in Italian).
Not the user that leaked the video. Which would be terrible enough. But the providers. In this case, Google itself.
Not even the Iranian government, not even the Myanmar government arrived to this point. They prosecuted the publishing of the ideas, but not the media through which those ideas was published.
An immediate, formal and firm protest of the world internet community is absolutely in order, to avoid that this happens also in your country.
The fact that this happened in Italy, a country where free speech is formally granted by our Constitution and ensured by a rich body of ordinary laws, is a warn and admonishment for all the "free" and "democratic" countries in the world. This can happen even in your country, and even if your country consider itself a Home for free speech.
Fight back now, or it will be too late.
Please, send a mail to the President of the Italian Republic, which has the power to lessen the effectiveness of this sentence in our legal system:
Republic President's webmail.
If other governments think they can do that because Italy did that, it will be a dark day for us all. Stop this from happening.
Original article (in Italian).
Not the user that leaked the video. Which would be terrible enough. But the providers. In this case, Google itself.
Not even the Iranian government, not even the Myanmar government arrived to this point. They prosecuted the publishing of the ideas, but not the media through which those ideas was published.
An immediate, formal and firm protest of the world internet community is absolutely in order, to avoid that this happens also in your country.
The fact that this happened in Italy, a country where free speech is formally granted by our Constitution and ensured by a rich body of ordinary laws, is a warn and admonishment for all the "free" and "democratic" countries in the world. This can happen even in your country, and even if your country consider itself a Home for free speech.
Fight back now, or it will be too late.
Please, send a mail to the President of the Italian Republic, which has the power to lessen the effectiveness of this sentence in our legal system:
Republic President's webmail.
If other governments think they can do that because Italy did that, it will be a dark day for us all. Stop this from happening.
Friday, February 19, 2010
Unexpected events can even be pleasant.
Yesterday, I've been asked to bring myself to the local station of the Finance Guard, for a one-time control applied randomly on new firms started last year.
Even if it's just a formal control on new-born firms, to prevent empty cover-up names to be legally provided to criminals, one may think it's quite a nuisance to loose a workday and bring your invoices into a police station for a check. And usually it is.
But contrarily to my expectations, I found the people at the office so empathic and warm that I had one of my most pleasurable morning since long. I met up with a officer being both skilled and loving I.T., so we entered immediately in a sympathetic mode.
As I was leaving the station, we took some time to talk about various arguments. As we talked, I wondered about the nice time we had, and realized that even if I had been forced to stop my restless work for half a day, that had been good indeed.
We run, run, rush to do things and never stop looking around, we're so dug into our daily troubles that we rarely see what's around, or in front of us. I felt so refreshed by the meeting that I had a feeling like taking a deep breath after a long run. And I felt like having found a new friend too.
Shuffling cards, meeting new people, going in new places, can really be good.
Yesterday, I've been asked to bring myself to the local station of the Finance Guard, for a one-time control applied randomly on new firms started last year.
Even if it's just a formal control on new-born firms, to prevent empty cover-up names to be legally provided to criminals, one may think it's quite a nuisance to loose a workday and bring your invoices into a police station for a check. And usually it is.
But contrarily to my expectations, I found the people at the office so empathic and warm that I had one of my most pleasurable morning since long. I met up with a officer being both skilled and loving I.T., so we entered immediately in a sympathetic mode.
As I was leaving the station, we took some time to talk about various arguments. As we talked, I wondered about the nice time we had, and realized that even if I had been forced to stop my restless work for half a day, that had been good indeed.
We run, run, rush to do things and never stop looking around, we're so dug into our daily troubles that we rarely see what's around, or in front of us. I felt so refreshed by the meeting that I had a feeling like taking a deep breath after a long run. And I felt like having found a new friend too.
Shuffling cards, meeting new people, going in new places, can really be good.
Sunday, February 07, 2010
... that makes me proud of being part of the mankind, it is this man.
Tiziano Terzani, he's not a master, as he says, he's not a Guru. He's just a man who lived, and who understood. Very probably, in another place, in another time, they would have called him a Buddah, an Enlightened.
He wrote books, as he was a journalist. In this interview, he was dying of a cancer, and he says he's happy of his life, and of the incredible opportunity he had been given; last but not least, the opportunity to die serenely, now that he is 66. Was he ill at a younger age, say at 30, he would have not be so happy to die, he says, but now, now that it has fulfilled his life, now that he has an equilibrium, now that he's in peace with himself... he says he and his "hosts", his cancer, will live and die together.
His last sentence in this video, one of his advices (not teaching, he never wanted to teach), is: if you find a fork in the road, where one road goes down, and the other goes up, get the one that goes up. You'll always find yourself in a better place.
And he was from Tuscany. As he's a man of the world, maybe I shouldn't say that, but hearing his adventures, his knowing, his wisdom in my own tongue, with that irony and views and happiness and life-force that are so much imbued in my homeland and so well know across the world, gives me a special kind of feeling.
Friday, February 05, 2010
Cheers for Falcon!
We have just committed version 1500:
Well, not a great news, but it was cool to cheer at it. With my fav beer :-).
We have just committed version 1500:
gian@hplin:~/Progetti/falcon/core$ svn commit -m "Removed unneeded troublesome dependency"
Trasmetto manpages/CMakeLists.txt
Trasmissione dati .
Commit della Revisione 1500 eseguito.
Well, not a great news, but it was cool to cheer at it. With my fav beer :-).
Thursday, January 28, 2010
Italy is slowly but steadily falling towards a new form of Fascism. As Primo Levi said, in the 60's, "it's today's Fascism, that is just missing the power to enforce itself to return being what it was, that is, the consecration of privilege and inequality".
To prevent this from happen again, there is just one way. Remember what happened, what caused fascism to raise and what it leaded to. And the horror it caused.
A person I know asked me, "why are we still re-vising what happened more than 60 years ago; why should be pity for a so distant fact, and for people of other races".
Because, I replied, there is one race I know: human. The people who suffered in the laghers, the people who was jailed and killed by Fascism and its descendant Nazism, wasn't of "a race", they wasn't a "kind". They was me. They all was me.
And I don't want this sort of things to happen to me, never again.
To prevent this from happen again, there is just one way. Remember what happened, what caused fascism to raise and what it leaded to. And the horror it caused.
A person I know asked me, "why are we still re-vising what happened more than 60 years ago; why should be pity for a so distant fact, and for people of other races".
Because, I replied, there is one race I know: human. The people who suffered in the laghers, the people who was jailed and killed by Fascism and its descendant Nazism, wasn't of "a race", they wasn't a "kind". They was me. They all was me.
And I don't want this sort of things to happen to me, never again.
Thursday, January 21, 2010
I proposed myself for a voluntary cooperation with CICAP, the "the Italian Committee for the Investigation of Claims on the Paranormal". They were searching for translators willing to lend a hand in translating material from "less common languages", like French, German and the like. So I wondered if they would have been interested in translations from Japanese.
The talk went on a bit, and a general interest on the relationships between Japan and paranormal things emerged. So, I started a bit of an investigation on the field.
It is well known that Japanese people have a traditional attraction towards supernatural and paranormal talks. While the first "gothic literature" in Europe is generally placed at the beginning of the '800, and individuated in works as "The Castle of Otranto" and "Wuthering Heights", Japanese literature is two-way bound with supernatural themes since the first records, and theatre pieces like "Yotsuya Ghost Story" produced in the early '800s was counting on an already solid tradition.
This may depend on the shamanic roots of the early Japanese culture, which changed into a more organized cult during the passage out of the pre-historic period into the early Japan as a central state emerged around 600 AD, but whose founding principles was never totally forgotten.
In the beginning, the search for people and associations seriously approaching paranormal phenomenon and claims of supernatural activities had been harder than I thought. I will digress on this aspect as my research progress.
However, I've been able to get in touch with an amazing set of fellow researchers, forming the ASIOS. The relatively young association (born in 2007) had already performed a quantity of investigations, promoted a series of books on scientific investigation (and dismantling) of "paranormal facts" and published a collective book called "The solving of mysteries". The president of the association, Mr. Honjou Tatsuya, replied to my first contact letter with an unexpectedly warm welcome.
I am so starting my journey in to the Japanese mysteries and the Japanese way to solve them. Isn't this exciting? :-)
If you have any news about weird things, mysteries, supernatural phenomenon and the like, and researchers on this field in Japan, I'd love you to send me comments on this article or mail me via my contact form.
Thanks!
The talk went on a bit, and a general interest on the relationships between Japan and paranormal things emerged. So, I started a bit of an investigation on the field.
It is well known that Japanese people have a traditional attraction towards supernatural and paranormal talks. While the first "gothic literature" in Europe is generally placed at the beginning of the '800, and individuated in works as "The Castle of Otranto" and "Wuthering Heights", Japanese literature is two-way bound with supernatural themes since the first records, and theatre pieces like "Yotsuya Ghost Story" produced in the early '800s was counting on an already solid tradition.
This may depend on the shamanic roots of the early Japanese culture, which changed into a more organized cult during the passage out of the pre-historic period into the early Japan as a central state emerged around 600 AD, but whose founding principles was never totally forgotten.
In the beginning, the search for people and associations seriously approaching paranormal phenomenon and claims of supernatural activities had been harder than I thought. I will digress on this aspect as my research progress.
However, I've been able to get in touch with an amazing set of fellow researchers, forming the ASIOS. The relatively young association (born in 2007) had already performed a quantity of investigations, promoted a series of books on scientific investigation (and dismantling) of "paranormal facts" and published a collective book called "The solving of mysteries". The president of the association, Mr. Honjou Tatsuya, replied to my first contact letter with an unexpectedly warm welcome.
I am so starting my journey in to the Japanese mysteries and the Japanese way to solve them. Isn't this exciting? :-)
If you have any news about weird things, mysteries, supernatural phenomenon and the like, and researchers on this field in Japan, I'd love you to send me comments on this article or mail me via my contact form.
Thanks!
Posted by Giancarlo at 04:03 AM. Filed under: Culture & science
