On Sun, Dec 20, 2015 at 5:21 PM, Thierry Goubier <[email protected]> wrote:
> 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? > > Well, just for putting perspective my sponsorship is about 3 full months of work effort. It doesn't mean I won't work beyond that. But to give you an idea. I think we all want minimal images , command line etc. And Pharo has already done a huge effort in that direction. > 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. > No, wait. You are getting down to the details so I want to discuss :) OSProcess does not use popen()/system() but rather fork()+exec(). That means that OSProcess has implementing the very very low building blocks that would allow you do to almost everything. But then it has it's complicated matters. fork() + exec() cannot be implemented via FFI (this was already discussed in another thread). However, there is a lot of other stuff that we believe it could. So... what we wanted to see if it is possible is to have one only (or very few) primitives (like forkAndExec) and all the rest via FFI. And then all the features I listed in the first email of this thread. With that in mind, we believe that: 1) Before starting dealing with forkAndExec, we could try a first prototype using popen(). That would allow us test a 100% FFI based approeach, deal with writing and reading from pipes via stream, face the blocking issue, see a prototype on how to read async from pipes etc etc etc. If we see this works nicely, on a second step we can build another approach that instead of popen() uses forkAndExec primitive. 2) We believe that there is a large number of OSProcess users that use OSProcess only for executing OS commands AND popen() approach would be more than enough (we will do a survey about this). So, a very simply solution via FFI for these users rather than having all OSProcess, Command Shell, the plugins etc, may be worth. What do you think? > 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. > > Indeed, it won't be easy I guess. But sometimes the process you execute may take quite some time and blocking the VM for that period is not a good choice. So... what would you prefer to solve that? Do you prefer image-based pooling as OSProcess does when IOPlugin is not used? > 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. > Interesting! -- Mariano http://marianopeck.wordpress.com
