Hi Mariano,
Le 20/12/2015 19:54, Mariano Martinez Peck a écrit :
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.
Would we have access then to a command-line oriented minimal Pharo image?
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.
My guess is that, at least on Linux/Unix, that FFI will be exactly the
same as the one used/expressed by the OSProcess plugin, that is
popen/system.
Now, given some of the difficulties seen when dealing with external
processes, I'd be wary of the "async" side of things. Random failures
seemingly linked to signal loss are certainly not something I'd like to
debug.
Something interesting and powerful would be pseudo-tty support. It would
allow a Pharo image to maintain an open connection to a shell, for
example, reducing the cost and latency of launching external commands
and maintaining a context.
Regards,
Thierry
