Hi Dimitri, Dave et all.

First let me do a little disclaimer.��Regarding the developments itself of this sponsorship, we discussed about the topics I said in the first email. However, those are not written in stone and that's why I also asked for feedback. As you know, Pharo has relatively little resources so those should be well spent. If we decide to take a spin into a project X, it doesn't mean other projects are not worth. It simply means that we think X will be the most useful for the time being.��

One of the final goals of the discusses topics, is to improve a bit the infrastructure for using Pharo as scripting (imagine Coral). For such a thing, we believe that improving FileSystem and OSProcess-like is a good first step to improve the underlying infrastructure.��

That being said, I of course like the idea of distributing processing across multiple images. No wonder, my PhD tool (Marea) and related sub-projects (Fuel, Ghost proxies, etc) have something to do with the mentioned topic. Dave already mentioned about RemoteTask, which was something I was about to mention. There is also Seamless project (now used by Remote Debugger stuff) and quite other tools. Finally, I think this project may have a big percentage that could be considered as "research". So having a PhD / master student working on this would also be nice. In fact, maybe��Denis Kudriashov��might work on that topic??? (he is now in RMOD team).

Also, not that forking the image is not my main short-term goal. As said, I will experiment first with a simple tool to execute OS commands that would be FFI based, trying to make async operations, and that would help in most cases. Maybe for those that are not supported, then fallback in OSProcess. Note that Dave (OSProcess author) is very helpful with me and we are discussing together about this.��

Torsten, thanks about OS. I will check out that project. I started with OSProcess and Limbo. So it's good to have another to check.��

I will try to make the survey starting next week.��

On Sun, Dec 20, 2015 at 2:17 PM, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

how the communication is happening via Fuel , does it save to a fuel file or it does it through memory some way ?

On Sun, Dec 20, 2015 at 6:04 PM David T. Lewis <lewis@mail.msen.com> wrote:

On Sun, Dec 20, 2015 at 05:07:47PM +0800, Pierce Ng wrote:
> On Sun, Dec 20, 2015 at 08:56:43AM +0000, Dimitris Chloupis wrote:
> > Fuel I assume enters here the equation as a data exchange format , the
> > problem I have with fuel is that its not backward compatible which for me
>

Fuel works well in this case. Version compatibility is not an issue, because
when you fork an image/VM the two cooperating images are essentially identical.

> Once you have a set of OS processes running Pharo how they talk to each other
> is up to you no? E.g. the Pharo instances could use ZeroMQ, XML-RPC, JSONRPC,
> msgpack, coordinate via Redis/SQLite/PostgreSQL, etc.

Any of those would work, but Fuel is a good way to enable all kinds of
objects to be copied from one image to another through a stream. In the
case of RemoteTask, all of the results of a remote computation can be put
into a single result object (an array or a dictionary or whatever), and
that result can be passed back to the parent image by reading the single
object. So - fork a copy of the image, have it do some work, and read the
result object from a stream. You know you are done when you have read
exactly one object.

Dave

--

Mariano
http://marianopeck.wordpress.com