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

> From: Kris Gybels <[hidden email]>
> Date: August 5, 2010 6:13:01 PM GMT+02:00
> To: Stéphane Ducasse <[hidden email]>
> Cc: Andy Kellens <[hidden email]>, Johan Brichau <[hidden email]>
> 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.
>
>