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

10 Aug 2010

This can be interested to other Smalltalkers :)

Begin forwarded message:

...
  From: Kris Gybels &lt;kris-gybels(a)skynet.be&gt;
 Date: August 5, 2010 6:13:01 PM GMT+02:00
 To: Stéphane Ducasse &lt;stephane.ducasse(a)inria.fr&gt;
 Cc: Andy Kellens &lt;akellens(a)vub.ac.be&gt;be>, Johan Brichau
&lt;johan.brichau(a)uclouvain.be&gt;
 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:

  thanks!

 Stef

 On Aug 5, 2010, at 11:46 AM, Andy Kellens wrote:

> Stef,
> 
> I added Kris's new email address to this conversation.
> 
> On 05 Aug 2010, at 11:45, Stéphane Ducasse wrote:
> 
>> Hi kris
>> 
>> how can I access the code of staple?
>> 
>> Stef
>> On Aug 5, 2010, at 10:48 AM, Andy Kellens wrote:
>> 
>>> Hello,
>>> 
>>> The trick with using VW as a DLL indeed seems a good idea.
>>> While I also don't have a clue how this actually works, I believe Kris
used it when he implemented StaPLe (a bridge between SWI-Prolog and VW).
>>> You can probably find some example code on that project's website:
http://staple.sourceforge.net/
>>> 
>>> Andy
>>> 
>>> On 05 Aug 2010, at 10:42, Johan Brichau wrote:
>>> 
>>>> Hm.... except the traditional unwanted xml-rpc communication, I would
investigate the possibility to use Alien/FFI and talk to Visualworks as a dll.
>>>> I seem to remember that Visualworks can be used like that, but I'm
not sure.
>>>> 
>>>> If that works, you can create a high-level communication layer that would
make communication seamless.  