29 Apr
2016
29 Apr
'16
3:34 p.m.
On 29/04/2016 15:17, Peter Uhnák wrote:
On Fri, Apr 29, 2016 at 3:08 PM, Mariano Martinez Peck
<marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote:
On Fri, Apr 29, 2016 at 8:42 AM, Peter Uhnák <i.uhnak(a)gmail.com
<mailto: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(a)univ-lille1.fr <mailto: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(a)gmail.com
<mailto:estebanlm@gmail.com> Jenkins build #576
<https://github.com/moosetechnology/Moose/issues/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(a)list.inf.unibe.ch
<mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch>
https://www.list.inf.unibe.ch/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
--
Nicolas Anquetil
RMod team -- Inria Lille