Hi guys,

First, I would like to say that David was always very helpful, positive and we have discussed and worked together a lot for this.��

When I was sponsored to build OSSubprocess I already got the "we would like this have this", so maybe some additional opinion from the ESUG board may help clarify. From what I understand/remember/believe, the main reasons for building OSSubprocess were:

1) FFI-based tool. Low the barrier of having to modify the VM to make a fix. Despite all our efforts, we still have way more people able to deal with��FFI than with the VM. Even more if the VM is now shared under a common project, in which is not always easy to plug Pharo-specific stuff.��

��

2) Cleaner/nicer API. You may or may not agree with this and that's perfect (we all have different opinions). When I was using OSProcess I always thought the API was not as I would like to, so my goal was to provide a API closer to my wishes. Again, not necessary better.��

3) Smaller functionality��than OSProcess: OSProcess is huge...it allows you to fork squeak images, fork()��+ exec*()�� whatever you want, runs on Windows, etc. We wanted something smaller...just enough to be able to fork processes. That is... to capture the most common/easy process forking.. But if you really need something very advance, you may still go to bare metals and use OSProcess approach (fork��+ exec).��

4) Added infrastructure. We wanted the project to be on Git, with a very detailed documentation, very high test coverage, and CI integration.��

-----

So...that is about the reasons... as to why it breaks when OSProcess is loaded to, it's because for OSSubprocess I took the wonderful idea from OSProcess of the child reaper. This is a process that runs on the Smalltalk side and handles exception (via semaphore) when the child has died.�� This is (currently) only possible thanks to OSProcess primitive. That means OSSubprocess still needs (one or very little) OSProcess primitives down in the VM. When you load either of the projects, they launch the child reaper process, register the semaphore etc etc. So the problem is when you loaded one and you then try to load the second one, the initialization of the second one you plug its own semaphore etc etc and so the previous gets broken as it doesn't have a working child reaper process.��

If someone has a better idea on how to solve this, then please speak up.��

Cheers,

On Wed, May 23, 2018 at 11:12 AM Sean P. DeNigris <sean@clipperadams.com> wrote:

Guillermo Polito wrote
> I try not to depend on projects using OSProcess in that case.

That is not exactly a robust solution! What is the only project providing
the functionality you need depends on OSP?!

Guillermo Polito wrote
> I understand that the incompatibilities bother, but putting all the fault
> in OSSubprocess and not in OSProcess seems not fair :)

Ha ha, well OSProcess was born in 2005, and then OSSP appeared reusing some
of its functionality just recently, so I'd say it's fair indeed!

Guillermo Polito wrote
> Maybe both should be modified to be compatible?

Maybe. I don't really understand the source of the incompatibility well
enough.

Guillermo Polito wrote
> I found OSProcess API particularly bad. It's never clear to me whether to
> use OSProcess, PipeableSomething or CommandWhatever (I don't even remember
> the names of the things that **do work** and I have to look them every
> time).

The things you're describing are not accidental complexity, but the fact
that OSP (and its companion CommandShell) actually have a far wider feature
set than just simple commands. CommandShell makes many shell-like things
possible in-image, but one doesn't have to use or even know anything about
all that to do simple things. That said, every time I did into CS and see
all the things that are possible I am amazed.

Guillermo Polito wrote
> Most people only want to do
> output := OSProcess executeCommand: 'ls'.
> Blocking. Recovering stdout. And that's all.

(PipeableOSProcess command: 'ls') output

That doesn't seem horribly complex to do in OSP ;)

Guillermo Polito wrote
> Well from a technical point of view, if you want to choose from one or
> another today I'd say��

Ah, interesting and informative. Thank you.

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html