According to this��

http://stackoverflow.com/questions/9903670/measure-local-sockets-speed

The speed for a modern computer should be around 200 mbs/sec , you can easily choke Pharo with this amount of data.I seriously doubt that Pharo can process 200mbs in 1 second. So it looks like you will worry about Pharo a lot sooner than you will worry about Ephestos.

Also Ephestos because it allows you to execute any kind of python code, you have the option to let the data sit inside blender and fetch it whenever you want them or just the precise data that interests you. Afterall Blender is much faster than Pharo with dealing with 3d data ��and Pharo has light years of distance to cover before it competes in that area. ��

By the way MORSE looks like it uses sockets already from what I read in the documentation section for communicating with matlab and other applications.��

I read also in the second link you sent��

"The last line configure the robot���s components on socket, for more information about services and datastreams, go to��Middleware configuration"

so if is fast enough for Blender I don't see why it won't be fast enough for Ephestos. Ephestos afterall is Blender and is Python.��

Its great that binding for Pharo already exist , I am sure you can find a way to make everything work together , including Ephestos. Afterall the biggest problem always is knowledge , " how I do this" , technology already provides huge amount of solution but you have to know how to use the tools. Ephestos wont teach you pharo, it wont teach you python and certainly wont teach you blender.

My thinking about sockets is that they present two big advantages over wrapping code and FFIs

a) Much easier to use. See how simple Ephestos is .
b) No maintenance needed at all. The library changes ? no problemo, unlike a wrapper or a FFI no API needs to be defined at Pharo side, that ensures that the latest of the library ported is supported with no extra work.
c) The socket bridge may have no scope, it could run as Ephestos does any kind of code and any kind of library out of the box.

You sacrifice some performance but that a small price to pay over the advantages. ��


On Mon, Jul 21, 2014 at 11:02 AM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Mon, Jul 21, 2014 at 9:48 AM, kilon alios <kilon.alios@gmail.com> wrote:
> Well in theory it should work.
>
> I am saying "in theory" because I have not tried MORSE.
>
> What is Ephestos ? ��Basically its a python application that creates a
> streamsocket server that listens byte data, then it takes the byte messages
> it converts them to strings and it executes them using exec() built-in
> python function. The end. See what I did here , I did not mention Blender at
> all. Actually Ephestos is implemented as Blender addon. So it gives you both
> access to Bpy and python libraries. A Blender addon is basically a python
> application + access to BPY + extra stuff to make it easy to select and
> enable in the Blender GUI.
>
> Now from what I see at first glance MORSE uses BPY and BGE. BGE , the
> blender game engine is a separate app essentially with its own API. So I
> need to wrap Ephestos for BGE but it will still be the same thing with added
> more code to be called by BGE. It should be fairly easy to do and I will do
> it.
>
> I don't know if there are other implementation details ��about MORSE but I
> don't think there will be a problem to make it work with Ephestos.
>
> Of course Ephestos has still got some big limitations a) does not receive
> data from Blender b) does not support of multiline python code. I don't know
> about b) it may work already if you add newlines in your python strings and
> whitespaces but I will have to test this and of course improve it to make it
> easier to use. Both of these features will be added since they are high
> priority goals.

Thank you for your explanations Kilon. I understand better how it works now.
Yes receiving data like perception data from robots is quite important
for MORSE.
One problem I envision, is that the data could be huge and some
performance issues could appear I guess
if you have to translate data structures from Python to Pharo.

BTW, Noury and Luc developed a ROS binding for Pharo.
ROS is a robotic middleware that could be used to do communication with MORSE.

Regards,
--
Serge Stinckwich
UCBN & UMI UMMISCO 209 (IRD/UPMC)
Every DSL ends up being Smalltalk
http://www.doesnotunderstand.org/