[Moose-dev] Fwd: do you have an idea how we could talk from pharo to vw?

From: Kris Gybels <kris-gybels(a)skynet.be> Date: August 5, 2010 6:13:01 PM GMT+02:00 To: Stéphane Ducasse <stephane.ducasse(a)inria.fr> Cc: Andy Kellens <akellens(a)vub.ac.be>be>, Johan Brichau <johan.brichau(a)uclouvain.be> Subject: Re: do you have an idea how we could talk from pharo to vw? A direct answer to your question where the code is: The code of STaPLe is in a SourceForge CVS repository, this page explains how to check out the repository or browse it via a web browser: http://sourceforge.net/scm/?type=cvs&group_id=96556 There are brief NOTES files explaining what additional things you need (SWI-Prolog) and how the code can be built if you would really want to try it out; but be warned, the last time I looked at it was in 2003 ... About the idea: I would suggest you start by using an existing distributed messaging framework to communicate between Pharo and VisualWorks. I don't know about any such frameworks, since I never needed one, but I'd be surprised if one for Smalltalk does not exist. ;) The only advantage I can immediately see to doing something similar to what I did with STaPLe is that you can eliminate the overhead of process switching and socket communication by running the two virtual machines in the same process. The essence of STaPLe is a small piece of C code that staples together the virtual machines of VisualWorks and SWI-Prolog by using their C foreign function interfaces. But except for the fact that they communicate through these foreign function interfaces and not through sockets, STaPLe does much the same thing as you would have to do for distributed messaging: it converts strings and numbers from one virtual machine to the other, makes proxies for objects so that they can be sent a message from the other side and so on. This creates a lot of overhead for each message send. I am not sure whether process switching and socket communication creates enough additional overhead to try to optimize it away. So: Try distributed messaging first. That way you don't need to do anything in C. If you find it is too slow for what you want to do, try to get rid of process switching and socket communication by using the foreign function interface way. If it's still too slow, then err ... I think the only option left is: run all your code in only one Smalltalk virtual machine ;)) Regards, Kris. On 05 Aug 2010, at 11:47, Stéphane Ducasse wrote: