(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 https://github.com/pharo-project/pharo-vm.git Commit: 2b53ae43e6a030759fbfa6ce8737a7f55ba76dd1 Date: 2016-03-15 19:05:06 +0100 By: Esteban Lorenzano estebanlm@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
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.
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 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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
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?
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 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@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
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.
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 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@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
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
2016-04-29 15:17 GMT+02:00 Peter Uhnák i.uhnak@gmail.com:
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 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
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 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@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
-- Mariano http://marianopeck.wordpress.com
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
On Fri, Apr 29, 2016 at 10:22 AM, Thierry Goubier <thierry.goubier@gmail.com
wrote:
2016-04-29 15:17 GMT+02:00 Peter Uhnák i.uhnak@gmail.com:
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 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).
Well... I think there could be an easy way, but that may involve either hacks/overrides or code change in OSProcess. OSProcess tries to re-register it's child process in a couple of places. So... trying to stop doing that will be more complicated. I think the easiest path is to:
1) Let OSProcess to be the one that defines the semaphore and waits for signals 2) Allow OSSubprocess to be tell to stop it's own child watcher (a method to be called explicitly by a user when OSProcess is in the image) 3) Modify OSProcess #grimReaperProcess to throw a notification / announcement when the semaphore is signaled (just before the "self changed: #childProcessStatus"). 4) Define an announcement / notification handler for OSSubprocess that when such a notification is receives, it sends the #updateActiveChildrenAndNotifyDead.
What do you think?
Thierry
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 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@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
-- Mariano http://marianopeck.wordpress.com
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
Welp apparenty GitFileTree has already switched to OSSubprocess… which means that since I use Moose I can no longer commit my code… which is fun. -_- There is a method to try to disable OSProcess… which does work in fresh Moose image, just not mine apparently…
As for the points, it seems strange to me that a user would have to take explicit action to decide just because the underlying mechanism is poor. As an end-user, even though a developer, this is not a good solution. How do other systems do this? In python I can use X different commands and libraries… os, subprocess, popen2… and I don't need to care about some super-low-level semaphores between several libraries.
If we want to deprecate OSProcess I really don't see why it should be the primary subsystem…
Well... I think there could be an easy way, but that may involve either
hacks/overrides or code change in OSProcess.
What's wrong with making code changes to OSProcess?
Peter
On Fri, Apr 29, 2016 at 3:37 PM, Mariano Martinez Peck < marianopeck@gmail.com> wrote:
On Fri, Apr 29, 2016 at 10:22 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2016-04-29 15:17 GMT+02:00 Peter Uhnák i.uhnak@gmail.com:
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 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).
Well... I think there could be an easy way, but that may involve either hacks/overrides or code change in OSProcess. OSProcess tries to re-register it's child process in a couple of places. So... trying to stop doing that will be more complicated. I think the easiest path is to:
- Let OSProcess to be the one that defines the semaphore and waits for
signals 2) Allow OSSubprocess to be tell to stop it's own child watcher (a method to be called explicitly by a user when OSProcess is in the image) 3) Modify OSProcess #grimReaperProcess to throw a notification / announcement when the semaphore is signaled (just before the "self changed: #childProcessStatus"). 4) Define an announcement / notification handler for OSSubprocess that when such a notification is receives, it sends the #updateActiveChildrenAndNotifyDead.
What do you think?
Thierry
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 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@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
-- Mariano http://marianopeck.wordpress.com
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
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Le 29/04/2016 18:22, Peter Uhnák a écrit :
Welp apparenty GitFileTree has already switched to OSSubprocess… which means that since I use Moose I can no longer commit my code… which is fun. -_-
I suspected this was the problem.
I can setup GitFileTree so that it may either use OSProcess / OSSubprocess depending on what is already installed. Would that solve your problem?
Thierry
There is a method to try to disable OSProcess… which does work in fresh Moose image, just not mine apparently…
As for the points, it seems strange to me that a user would have to take explicit action to decide just because the underlying mechanism is poor. As an end-user, even though a developer, this is not a good solution. How do other systems do this? In python I can use X different commands and libraries… os, subprocess, popen2… and I don't need to care about some super-low-level semaphores between several libraries.
If we want to deprecate OSProcess I really don't see why it should be the primary subsystem…
Well... I think there could be an easy way, but that may involve either hacks/overrides or code change in OSProcess.What's wrong with making code changes to OSProcess?
Peter
Hi,
OSProcess is used for providing a quick way to link to VerveineJ in MooseImportFromVerveineJWizard. If we port this code to OSSubprocess, we can adopt it. Any takers?
In any case, modifying OSProcess to allow for OSSubprocess to coexist would be great.
Cheers, Doru
On Apr 29, 2016, at 6:22 PM, Peter Uhnák i.uhnak@gmail.com wrote:
Welp apparenty GitFileTree has already switched to OSSubprocess… which means that since I use Moose I can no longer commit my code… which is fun. -_- There is a method to try to disable OSProcess… which does work in fresh Moose image, just not mine apparently…
As for the points, it seems strange to me that a user would have to take explicit action to decide just because the underlying mechanism is poor. As an end-user, even though a developer, this is not a good solution. How do other systems do this? In python I can use X different commands and libraries… os, subprocess, popen2… and I don't need to care about some super-low-level semaphores between several libraries.
If we want to deprecate OSProcess I really don't see why it should be the primary subsystem…
Well... I think there could be an easy way, but that may involve either hacks/overrides or code change in OSProcess.
What's wrong with making code changes to OSProcess?
Peter
On Fri, Apr 29, 2016 at 3:37 PM, Mariano Martinez Peck marianopeck@gmail.com wrote:
On Fri, Apr 29, 2016 at 10:22 AM, Thierry Goubier thierry.goubier@gmail.com wrote:
2016-04-29 15:17 GMT+02:00 Peter Uhnák i.uhnak@gmail.com:
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 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).
Well... I think there could be an easy way, but that may involve either hacks/overrides or code change in OSProcess. OSProcess tries to re-register it's child process in a couple of places. So... trying to stop doing that will be more complicated. I think the easiest path is to:
- Let OSProcess to be the one that defines the semaphore and waits for signals
- Allow OSSubprocess to be tell to stop it's own child watcher (a method to be called explicitly by a user when OSProcess is in the image)
- Modify OSProcess #grimReaperProcess to throw a notification / announcement when the semaphore is signaled (just before the "self changed: #childProcessStatus").
- Define an announcement / notification handler for OSSubprocess that when such a notification is receives, it sends the #updateActiveChildrenAndNotifyDead.
What do you think?
Thierry
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
-- Mariano http://marianopeck.wordpress.com
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
-- Mariano http://marianopeck.wordpress.com
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
-- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
Hi Peter,
Le 29/04/2016 18:22, Peter Uhnák a écrit :
Welp apparenty GitFileTree has already switched to OSSubprocess… which means that since I use Moose I can no longer commit my code… which is fun. -_-
For Pharo 5.0, I've pushed both #dev and #stable versions of GitFileTree which will reuse either OSProcess or OSSubprocess if it is already loaded and will avoid reloading OSSubprocess over OSProcess.
Could you try with Moose to see if it solves the problem you have? Just tell how it goes.
Thierry
On Sat, Apr 30, 2016 at 5:14 PM, Thierry Goubier thierry.goubier@gmail.com wrote:
Hi Peter,
Le 29/04/2016 18:22, Peter Uhnák a écrit :
Welp apparenty GitFileTree has already switched to OSSubprocess… which means that since I use Moose I can no longer commit my code… which is fun. -_-
For Pharo 5.0, I've pushed both #dev and #stable versions of GitFileTree which will reuse either OSProcess or OSSubprocess if it is already loaded and will avoid reloading OSSubprocess over OSProcess.
Could you try with Moose to see if it solves the problem you have? Just tell how it goes.
This indeed solves the Moose + Git problem, thanks!
Although the underlying problem still remains… which I don't understand, so I guess I will have to take a look to learn a bit. Because imagine a year from now someone else comes along with a new library, or OS(Sub)Process goes through a backwards-incompatible rewrite into OS(Sub)Process2 and suddenly we are where we started...
Peter
Thierry
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Le 30/04/2016 17:53, Peter Uhnák a écrit :
On Sat, Apr 30, 2016 at 5:14 PM, Thierry Goubier <thierry.goubier@gmail.com mailto:thierry.goubier@gmail.com> wrote:
Hi Peter, Le 29/04/2016 18:22, Peter Uhnák a écrit : Welp apparenty GitFileTree has already switched to OSSubprocess… which means that since I use Moose I can no longer commit my code… which is fun. -_- For Pharo 5.0, I've pushed both #dev and #stable versions of GitFileTree which will reuse either OSProcess or OSSubprocess if it is already loaded and will avoid reloading OSSubprocess over OSProcess. Could you try with Moose to see if it solves the problem you have? Just tell how it goes.This indeed solves the Moose + Git problem, thanks!
It took me a lot longer to get all the Baselines/Configurations aligned properly (as well as testing and tuning the SmalltalkCI configuration) than writing/recovering the code.
Git makes child play of recovering a years' old version of a method :)
Although the underlying problem still remains… which I don't understand, so I guess I will have to take a look to learn a bit. Because imagine a year from now someone else comes along with a new library, or OS(Sub)Process goes through a backwards-incompatible rewrite into OS(Sub)Process2 and suddenly we are where we started...
Well, there isn't much we can do about that.
Pharo and some of the underlying components change over time, and stuff needs to be maintained/adjusted to make the transition. Making APIs perfectly stable contradict the ability of Pharo to evolve.
Thierry
Peter
Thierry _______________________________________________ Moose-dev mailing list Moose-dev@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
OSProcess is used for providing a quick way to link to VerveineJ in MooseImportFromVerveineJWizard. If we port this code to OSSubprocess, we can adopt it. Any takers?
Moose also depends on ZeroConf, which uses OSProcess through CommandShell. Although this is quite confusing… ZeroConf depends on CommandShell but it loads just the ConfigurationOfCommandShell, not the package; instead it uses OSProcess directly (with specifying dependency on OSProcess).
If we can't have coexistence then we are introducing fragility into the system. As a user loading a package X you have no way of knowing if it will break unless you investigate the whole dependency tree.
So maybe both OSProcess and OSSubprocess should at the very least #preLoadDoIt: check whether the other is in the system and refuse to install, or ask the user for confirmation?
On Sat, Apr 30, 2016 at 6:33 PM, Thierry Goubier thierry.goubier@gmail.com wrote:
Le 30/04/2016 17:53, Peter Uhnák a écrit :
On Sat, Apr 30, 2016 at 5:14 PM, Thierry Goubier <thierry.goubier@gmail.com mailto:thierry.goubier@gmail.com> wrote:
Hi Peter, Le 29/04/2016 18:22, Peter Uhnák a écrit : Welp apparenty GitFileTree has already switched to OSSubprocess… which means that since I use Moose I can no longer commit my code… which is fun. -_- For Pharo 5.0, I've pushed both #dev and #stable versions of GitFileTree which will reuse either OSProcess or OSSubprocess if it is already loaded and will avoid reloading OSSubprocess overOSProcess.
Could you try with Moose to see if it solves the problem you have? Just tell how it goes.This indeed solves the Moose + Git problem, thanks!
It took me a lot longer to get all the Baselines/Configurations aligned properly (as well as testing and tuning the SmalltalkCI configuration) than writing/recovering the code.
Git makes child play of recovering a years' old version of a method :)
Although the underlying problem still remains… which I don't understand,
so I guess I will have to take a look to learn a bit. Because imagine a year from now someone else comes along with a new library, or OS(Sub)Process goes through a backwards-incompatible rewrite into OS(Sub)Process2 and suddenly we are where we started...
Well, there isn't much we can do about that.
Pharo and some of the underlying components change over time, and stuff needs to be maintained/adjusted to make the transition. Making APIs perfectly stable contradict the ability of Pharo to evolve.
Thierry
Peter
Thierry _______________________________________________ Moose-dev mailing list Moose-dev@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@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
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 mailto:marianopeck@gmail.com> wrote:
On Fri, Apr 29, 2016 at 8:42 AM, Peter Uhnák <i.uhnak@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@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@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@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@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@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@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Since we are discussing about OSSubprocess. How can I use it? For example, how can I execute: ls /tmp > foo.txt
Alexandre
Sorry, I did not see:
https://github.com/marianopeck/OSSubprocess
Having some examples in the image would help :-)
Cheers, Alexandre
-
Alexandre Bergel -
Anne Etien -
Mariano Martinez Peck -
Nicolas Anquetil -
Peter Uhnák -
Thierry Goubier -
Tudor Girba