Thanks Christophe! This thread opens a lot of interesting questions, and as most of them are all subjective and I will only add my opinion that is so wrong (or right) as all the other opinions. First, I consider that having options to do the same tasks with different considerations is good for the community, as it enlarges the options when using Pharo professionally. I always consider that a good engineer takes all the options and decide the best one depending on the existent requirement and restrictions. Sometimes we require to have tools that only fit for a single scenario and others that are general but mostly fit for all scenarios. I also consider good that Christophe, that fixes something for the Pharo Launcher (but it could have been any other project) and releases to the community so anyone else can fix the same problem. I ask everybody else before taking opinions to read the motivations behind the library / framework / couple of classes of Christophe. He required to have something that was working with correctly with UTF8 paths and it is polymorphic with OSSubprocess (as it is used in the other 2 platforms). I don't see any other solution that fulfills these requirements, so he has done an ad-hoc solution. Thankfully he has released it and now whoever cames later can have another option to use or even to copy and spawn a completely new solution. Finally, I share the good point of Torsten that we require to have a better way of publishing all the tools / libraries / pieces of code that we share, so the newcomers can find them easily. But even with the perfect documenting-sharing tool, it will be nice to have different solutions with different constraints and different improvements. Also, it will be nice to have more communication and focussing on pushing to the same targets. But how we can do that without cutting down the innovation, the reception of new ideas and the enjoy of implementing new things. One interesting case we have to accept as an open community is the reimplementation of something because is funny. I know this is not the case with Christophe, because I have seen him. This is also important and should not be cut down. It is not good to reinvent the wheel every time, but if we don't do it when it is required we will not have anything. I will really like to see more contributions of any kind, I invite to reimplement any of the things I did / do with new approaches and vision so everyone can grow. And one that will be really nice to have is a replacement for the catalog, so we can compare all the solutions that we have for a single problem!!! Thanks for reading me!! On Mon, Jul 8, 2019 at 12:13 PM Christophe Demarey <christophe.demarey@inria.fr> wrote:
Hi,
Pharo Launcher had stability problems to spawn new processes (launch Pharo images) on Windows as well as limitations (paths could only contain ASCII characters). To solve this problem, we developed a new library: OSWinSubprocess (https://github.com/pharo-contributions/OSWinSubprocess) and decided to make it a standalone library so that people can use it if they need to. We tried to use the same API as OSSubprocess when possible. This library uses the Windows API to create process from both 32-bit and 64-bit Pharo images. It also supports Unicode characters.
Here are some examples on how to use it:
process := OSWSWinProcess new command: 'C:\Windows\notepad.exe'; run. ... process terminate.
OSWSWinProcess new command: 'C:\Windows\notepad.exe'; arguments: #('notepad.exe' 'C:\foo.txt'); runAndWait.
Important note: As of now, this library does not yet support standard streams (stdin, stdout and stderr). It could be done by setting the appropriate information in the STARTUPINFO structutre.
You can check the README for more information.
Regards, Christophe.
-- Pablo Tesone. tesonep@gmail.com