29 Apr
2016
29 Apr
'16
3:22 p.m.
2016-04-29 15:17 GMT+02:00 Peter Uhnák <i.uhnak(a)gmail.com>om>:
On Fri, Apr 29, 2016 at 3:08 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
I also believe that, depending on the project, having code that either
targets OSProcess or OSSubprocess could be done; for example it would be
easy to do this on GitFileTree. A bit harder would be to have a
configuration or baseline which only loads say OSSubprocess if OSProcess
isn't already present on the target image (or the reverse).
Thierry
On Fri, Apr 29, 2016 at 8:42 AM, Peter Uhnák <i.uhnak(a)gmail.com> wrote:
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 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?
Peter
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
Peter
On Fri, Apr 29, 2016 at 1:12 PM, Anne Etien <anne.etien(a)univ-lille1.fr>
wrote:
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Moose-dev mailing list
Moose-dev(a)list.inf.unibe.ch
https://www.list.inf.unibe.ch/listinfo/moose-dev
(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 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
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