On 29/04/2016 15:17, Peter Uhnák wrote:


On Fri, Apr 29, 2016 at 3:08 PM, Mariano Martinez Peck <marianopeck@gmail.com> wrote:


On Fri, Apr 29, 2016 at 8:42 AM, Peter Uhnák <i.uhnak@gmail.com> wrote:
I am also interested in this, as I will likely need it next week.

However if I remember correctly Mariano mentioned that you can't have OSProcess and OSSubprocess installed at once, and in Moose OSProcess is already installed; so even if you manage to install it there may be yet another problem waiting.
That's exactly the reason. I just grab a Moose 6 image to reproduce the problem, and indeed it's that. OSProcess comes already in Moose and both cannot easily co-exist. It's not OSProcess fault, but MINE. This is because for OSSubprocess I am re-using the primitives of OSProcess to capture signals (SIGCHLD for example) and signal a semaphore. So... we cannot have 2 semaphores waiting on a signal. 

Once I tried a workaround to "disable" OSProcess signaling, but it was not easy. The easiest path would be to have a condition or group or something in Moose Metacello configuration that would allow either loading OSProcess or OSSubprocess.  Could this be possible?
 

We still have a problem that there are many tools that use OSProcess so one can still break it accidentally by loading a project.

As for the side-by-side existence, would it be technically possible to have a wrapper that would decide whether to give the control to OSProcess or OSSubprocess based on who created the process? That way only the wrapper would be waiting for the signals.

I was thinking of that too.
For example with announcements?

the wrapper alone captures the signal and then announce it.

nicolas

Peter

 

Peter

On Fri, Apr 29, 2016 at 1:12 PM, Anne Etien <anne.etien@univ-lille1.fr> wrote:

(From Olivier Auverlot, that is not yet accepted in the list, (I will transfer to him until he is on the list))


Hi,

I need to use OSSubprocess in a project with Moose 6. I just tried to load it in a new Moose 6 image but that's doesn't work. By the way, OSSubprocess works fine in the latest Pharo 5 image. 

Please find below the lats lines of Pharo error log:

VM: Mac OS - intel - 1092 - CoInterpreter VMMaker.oscog-eem.1726 uuid: 6a968923-b541-4573-bc4f-64fb95e6462d Mar 15 2016
StackToRegisterMappingCogit VMMaker.oscog-eem.1726 uuid: 6a968923-b541-4573-bc4f-64fb95e6462d Mar 15 2016
https://github.com/pharo-project/pharo-vm.git Commit: 2b53ae43e6a030759fbfa6ce8737a7f55ba76dd1 Date: 2016-03-15 19:05:06 +0100 By: Esteban Lorenzano estebanlm@gmail.com Jenkins build #576

Image: Pharo5.0 [Latest update: #50732]

UndefinedObject(Object)>>doesNotUnderstand: #waitTimeoutMSecs:
Receiver: nil
Arguments and temporary variables: 
aMessage: waitTimeoutMSecs: 1000
exception: MessageNotUnderstood: receiver of "waitTimeoutMSecs:" is nil
resumeValue: nil
Receiver's instance variables: 
nil

By the way, OSSubprocess works fine in the latest Pharo 5 image. 

Someone has an idea ?

Olivier

_______________________________________________
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev




--

_______________________________________________
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev




_______________________________________________
Moose-dev mailing list
Moose-dev@list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev


-- 
Nicolas Anquetil
RMod team -- Inria Lille