yeah I completely agree that any improvement is more than welcomed. Thanks I will check out RemoteTask and Seamless :)
On Sun, Dec 20, 2015 at 8:55 PM Mariano Martinez Peck <marianop...@gmail.com> wrote: > 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.al...@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 <le...@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 >
