Hi all, Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else? Cheers, Max
Max ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit normal that it got removed in P7. But we should check this. I do not have the time today for this. normally ifNotNilDo: should be covered by a migrator automatic rewrite rules (can you check?): Ducasse/Migrator because in such case you load the migrator packages and execute the tests of the OSProcess (if any) then you execute OSProcess and the user of ifNotNilDo: will be automatically rewritten and you are just left to check the senders that are left and commit a new version. If IfNotNilDo: is not covered by a automated migration we should add one. It was deprecated before the automated migrations were introduced. Now about your question: yes a new version of OSProcess should be produced for P7. The best would be to migrate it to github. Let me know if it helps. Stef
On 11 Mar 2019, at 08:00, Max Leske <maxleske@gmail.com> wrote:
Hi all,
Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else?
Cheers, Max
Hi Stef, On 11 Mar 2019, at 8:12, ducasse wrote:
Max
ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit normal that it got removed in P7. But we should check this. I do not have the time today for this.
normally ifNotNilDo: should be covered by a migrator automatic rewrite rules (can you check?): Ducasse/Migrator because in such case you load the migrator packages and execute the tests of the OSProcess (if any) then you execute OSProcess and the user of ifNotNilDo: will be automatically rewritten and you are just left to check the senders that are left and commit a new version.
You have extensions defined for #ifNotNilDo: in your migration definition for 50 to 60.
If IfNotNilDo: is not covered by a automated migration we should add one. It was deprecated before the automated migrations were introduced.
Now about your question: yes a new version of OSProcess should be produced for P7. The best would be to migrate it to github.
I think Dave might disagree ;) If the maintainers are fine with moving to Github then that would be great. I assume that there will be some objections to that (e.g. because of loading in Squeak?) and we (I at least) don't want to maintain a fork / mirror on Github. Pulling from SqueakSource works fine for now. Max
Let me know if it helps.
Stef
On 11 Mar 2019, at 08:00, Max Leske <maxleske@gmail.com> wrote:
Hi all,
Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else?
Cheers, Max
Ok now one of these days we will have to have all the important libraries hosted in the same place. It is not sure that we will maintain MC forever. For example SmalltalkHub should get readonly by the end of the year (for lack of maintenance reason). BTW is OSSubProcess working for you?
Hi Stef,
On 11 Mar 2019, at 8:12, ducasse wrote:
Max
ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit normal that it got removed in P7. But we should check this. I do not have the time today for this.
normally ifNotNilDo: should be covered by a migrator automatic rewrite rules (can you check?): Ducasse/Migrator because in such case you load the migrator packages and execute the tests of the OSProcess (if any) then you execute OSProcess and the user of ifNotNilDo: will be automatically rewritten and you are just left to check the senders that are left and commit a new version.
You have extensions defined for #ifNotNilDo: in your migration definition for 50 to 60.
If IfNotNilDo: is not covered by a automated migration we should add one. It was deprecated before the automated migrations were introduced.
Now about your question: yes a new version of OSProcess should be produced for P7. The best would be to migrate it to github.
I think Dave might disagree ;) If the maintainers are fine with moving to Github then that would be great. I assume that there will be some objections to that (e.g. because of loading in Squeak?) and we (I at least) don't want to maintain a fork / mirror on Github. Pulling from SqueakSource works fine for now.
Max
Let me know if it helps.
Stef
On 11 Mar 2019, at 08:00, Max Leske <maxleske@gmail.com> wrote:
Hi all,
Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else?
Cheers, Max
On 13 Mar 2019, at 11:55, ducasse wrote:
Ok now one of these days we will have to have all the important libraries hosted in the same place. It is not sure that we will maintain MC forever. For example SmalltalkHub should get readonly by the end of the year (for lack of maintenance reason). BTW is OSSubProcess working for you?
So far I've only loaded it. I'll let yo know when I've run some tests.
Hi Stef,
On 11 Mar 2019, at 8:12, ducasse wrote:
Max
ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit normal that it got removed in P7. But we should check this. I do not have the time today for this.
normally ifNotNilDo: should be covered by a migrator automatic rewrite rules (can you check?): Ducasse/Migrator because in such case you load the migrator packages and execute the tests of the OSProcess (if any) then you execute OSProcess and the user of ifNotNilDo: will be automatically rewritten and you are just left to check the senders that are left and commit a new version.
You have extensions defined for #ifNotNilDo: in your migration definition for 50 to 60.
If IfNotNilDo: is not covered by a automated migration we should add one. It was deprecated before the automated migrations were introduced.
Now about your question: yes a new version of OSProcess should be produced for P7. The best would be to migrate it to github.
I think Dave might disagree ;) If the maintainers are fine with moving to Github then that would be great. I assume that there will be some objections to that (e.g. because of loading in Squeak?) and we (I at least) don't want to maintain a fork / mirror on Github. Pulling from SqueakSource works fine for now.
Max
Let me know if it helps.
Stef
On 11 Mar 2019, at 08:00, Max Leske <maxleske@gmail.com> wrote:
Hi all,
Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else?
Cheers, Max
On 13 Mar 2019, at 11:55, ducasse wrote:
Ok now one of these days we will have to have all the important libraries hosted in the same place. It is not sure that we will maintain MC forever. For example SmalltalkHub should get readonly by the end of the year (for lack of maintenance reason). BTW is OSSubProcess working for you?
Yes, it works. There appear to be some methods that need to be updated but general functionality is there. Max
Hi Stef,
On 11 Mar 2019, at 8:12, ducasse wrote:
Max
ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit normal that it got removed in P7. But we should check this. I do not have the time today for this.
normally ifNotNilDo: should be covered by a migrator automatic rewrite rules (can you check?): Ducasse/Migrator because in such case you load the migrator packages and execute the tests of the OSProcess (if any) then you execute OSProcess and the user of ifNotNilDo: will be automatically rewritten and you are just left to check the senders that are left and commit a new version.
You have extensions defined for #ifNotNilDo: in your migration definition for 50 to 60.
If IfNotNilDo: is not covered by a automated migration we should add one. It was deprecated before the automated migrations were introduced.
Now about your question: yes a new version of OSProcess should be produced for P7. The best would be to migrate it to github.
I think Dave might disagree ;) If the maintainers are fine with moving to Github then that would be great. I assume that there will be some objections to that (e.g. because of loading in Squeak?) and we (I at least) don't want to maintain a fork / mirror on Github. Pulling from SqueakSource works fine for now.
Max
Let me know if it helps.
Stef
On 11 Mar 2019, at 08:00, Max Leske <maxleske@gmail.com> wrote:
Hi all,
Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else?
Cheers, Max
On 14 Mar 2019, at 17:33, Max Leske <maxleske@gmail.com> wrote:
On 13 Mar 2019, at 11:55, ducasse wrote:
Ok now one of these days we will have to have all the important libraries hosted in the same place. It is not sure that we will maintain MC forever. For example SmalltalkHub should get readonly by the end of the year (for lack of maintenance reason). BTW is OSSubProcess working for you?
Yes, it works. There appear to be some methods that need to be updated but general functionality is there.
Let us know because Guille did a pass on Marianoâs version and we are ready to improve it.
Max
Hi Stef,
On 11 Mar 2019, at 8:12, ducasse wrote:
Max
ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit normal that it got removed in P7. But we should check this. I do not have the time today for this.
normally ifNotNilDo: should be covered by a migrator automatic rewrite rules (can you check?): Ducasse/Migrator because in such case you load the migrator packages and execute the tests of the OSProcess (if any) then you execute OSProcess and the user of ifNotNilDo: will be automatically rewritten and you are just left to check the senders that are left and commit a new version.
You have extensions defined for #ifNotNilDo: in your migration definition for 50 to 60.
If IfNotNilDo: is not covered by a automated migration we should add one. It was deprecated before the automated migrations were introduced.
Now about your question: yes a new version of OSProcess should be produced for P7. The best would be to migrate it to github.
I think Dave might disagree ;) If the maintainers are fine with moving to Github then that would be great. I assume that there will be some objections to that (e.g. because of loading in Squeak?) and we (I at least) don't want to maintain a fork / mirror on Github. Pulling from SqueakSource works fine for now.
Max
Let me know if it helps.
Stef
On 11 Mar 2019, at 08:00, Max Leske <maxleske@gmail.com> wrote:
Hi all,
Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else?
Cheers, Max
Iâve been using OSProcess on OSX for exercism (development mode) and its been working fine. (Iâve been piping a go executable output to run a generation command)
On 14 Mar 2019, at 16:38, ducasse <stepharo@netcourrier.com> wrote:
On 14 Mar 2019, at 17:33, Max Leske <maxleske@gmail.com> wrote:
On 13 Mar 2019, at 11:55, ducasse wrote:
Ok now one of these days we will have to have all the important libraries hosted in the same place. It is not sure that we will maintain MC forever. For example SmalltalkHub should get readonly by the end of the year (for lack of maintenance reason). BTW is OSSubProcess working for you?
Yes, it works. There appear to be some methods that need to be updated but general functionality is there.
Let us know because Guille did a pass on Marianoâs version and we are ready to improve it.
Max
Hi Stef,
On 11 Mar 2019, at 8:12, ducasse wrote:
Max
ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit normal that it got removed in P7. But we should check this. I do not have the time today for this.
normally ifNotNilDo: should be covered by a migrator automatic rewrite rules (can you check?): Ducasse/Migrator because in such case you load the migrator packages and execute the tests of the OSProcess (if any) then you execute OSProcess and the user of ifNotNilDo: will be automatically rewritten and you are just left to check the senders that are left and commit a new version.
You have extensions defined for #ifNotNilDo: in your migration definition for 50 to 60.
If IfNotNilDo: is not covered by a automated migration we should add one. It was deprecated before the automated migrations were introduced.
Now about your question: yes a new version of OSProcess should be produced for P7. The best would be to migrate it to github.
I think Dave might disagree ;) If the maintainers are fine with moving to Github then that would be great. I assume that there will be some objections to that (e.g. because of loading in Squeak?) and we (I at least) don't want to maintain a fork / mirror on Github. Pulling from SqueakSource works fine for now.
Max
Let me know if it helps.
Stef
On 11 Mar 2019, at 08:00, Max Leske <maxleske@gmail.com> wrote:
Hi all,
Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else?
Cheers, Max
I was talking about OSSubProcess
On 14 Mar 2019, at 18:21, Tim Mackinnon <tim@testit.works> wrote:
Iâve been using OSProcess on OSX for exercism (development mode) and its been working fine. (Iâve been piping a go executable output to run a generation command)
On 14 Mar 2019, at 16:38, ducasse <stepharo@netcourrier.com> wrote:
On 14 Mar 2019, at 17:33, Max Leske <maxleske@gmail.com> wrote:
On 13 Mar 2019, at 11:55, ducasse wrote:
Ok now one of these days we will have to have all the important libraries hosted in the same place. It is not sure that we will maintain MC forever. For example SmalltalkHub should get readonly by the end of the year (for lack of maintenance reason). BTW is OSSubProcess working for you?
Yes, it works. There appear to be some methods that need to be updated but general functionality is there.
Let us know because Guille did a pass on Marianoâs version and we are ready to improve it.
Max
Hi Stef,
On 11 Mar 2019, at 8:12, ducasse wrote:
Max
ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit normal that it got removed in P7. But we should check this. I do not have the time today for this.
normally ifNotNilDo: should be covered by a migrator automatic rewrite rules (can you check?): Ducasse/Migrator because in such case you load the migrator packages and execute the tests of the OSProcess (if any) then you execute OSProcess and the user of ifNotNilDo: will be automatically rewritten and you are just left to check the senders that are left and commit a new version.
You have extensions defined for #ifNotNilDo: in your migration definition for 50 to 60.
If IfNotNilDo: is not covered by a automated migration we should add one. It was deprecated before the automated migrations were introduced.
Now about your question: yes a new version of OSProcess should be produced for P7. The best would be to migrate it to github.
I think Dave might disagree ;) If the maintainers are fine with moving to Github then that would be great. I assume that there will be some objections to that (e.g. because of loading in Squeak?) and we (I at least) don't want to maintain a fork / mirror on Github. Pulling from SqueakSource works fine for now.
Max
Let me know if it helps.
Stef
On 11 Mar 2019, at 08:00, Max Leske <maxleske@gmail.com> wrote:
Hi all,
Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else?
Cheers, Max
On 14 Mar 2019, at 20:00, ducasse wrote:
I was talking about OSSubProcess
Well, I'm not working with that at the moment ;)
On 14 Mar 2019, at 18:21, Tim Mackinnon <tim@testit.works> wrote:
Iâve been using OSProcess on OSX for exercism (development mode) and its been working fine. (Iâve been piping a go executable output to run a generation command)
On 14 Mar 2019, at 16:38, ducasse <stepharo@netcourrier.com> wrote:
On 14 Mar 2019, at 17:33, Max Leske <maxleske@gmail.com> wrote:
On 13 Mar 2019, at 11:55, ducasse wrote:
Ok now one of these days we will have to have all the important libraries hosted in the same place. It is not sure that we will maintain MC forever. For example SmalltalkHub should get readonly by the end of the year (for lack of maintenance reason). BTW is OSSubProcess working for you?
Yes, it works. There appear to be some methods that need to be updated but general functionality is there.
Let us know because Guille did a pass on Marianoâs version and we are ready to improve it.
Max
Hi Stef,
On 11 Mar 2019, at 8:12, ducasse wrote:
Max
ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit normal that it got removed in P7. But we should check this. I do not have the time today for this.
normally ifNotNilDo: should be covered by a migrator automatic rewrite rules (can you check?): Ducasse/Migrator because in such case you load the migrator packages and execute the tests of the OSProcess (if any) then you execute OSProcess and the user of ifNotNilDo: will be automatically rewritten and you are just left to check the senders that are left and commit a new version.
You have extensions defined for #ifNotNilDo: in your migration definition for 50 to 60.
If IfNotNilDo: is not covered by a automated migration we should add one. It was deprecated before the automated migrations were introduced.
Now about your question: yes a new version of OSProcess should be produced for P7. The best would be to migrate it to github.
I think Dave might disagree ;) If the maintainers are fine with moving to Github then that would be great. I assume that there will be some objections to that (e.g. because of loading in Squeak?) and we (I at least) don't want to maintain a fork / mirror on Github. Pulling from SqueakSource works fine for now.
Max
Let me know if it helps.
Stef
On 11 Mar 2019, at 08:00, Max Leske <maxleske@gmail.com> wrote:
Hi all,
Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else?
Cheers, Max
Max Leske wrote
I was talking about OSSubProcess Well, I'm not working with that at the moment ;)
[OT] Just want to bump the problem that OSProcess and OSSubProcess can't currently be used in the same image. This is an important problem because users can't control which library dependencies use. Mariano hinted at a solution. It didn't seem like a ton of work, but it's beyond my understanding. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
Hi sean You see we are terribly busy working on a lot of cleaning in Spec. This is massive and this is super important for our roadmap. Guille and Pablo produce 600 tests. We are fixing duplication with Alain. Our main problem is that - if more people would review PR - send PRs Then we could free some times for other less urgent issues. For example, this is three years that Iâm waiting to remove duplicated code (PluggableTextMorph, PluggableTextInputField, TextEditor,â¦. Now we have to do it and this for many other points. So this is good that you mention it, but this is not because we do not care of Pharo that we will fix it immediately. Stef
On 15 Mar 2019, at 19:42, Sean P. DeNigris <sean@clipperadams.com> wrote:
Max Leske wrote
I was talking about OSSubProcess Well, I'm not working with that at the moment ;)
[OT] Just want to bump the problem that OSProcess and OSSubProcess can't currently be used in the same image. This is an important problem because users can't control which library dependencies use. Mariano hinted at a solution. It didn't seem like a ton of work, but it's beyond my understanding.
----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
ducasse wrote
Our main problem is that - if more people would review PR - send PRs
Thank you for the reminder of that bottleneck. I will try to do that more now that we have moved to GH. The old process seemed too cumbersome to be able to effectively utilize a few free moments here and there, but I suspect that no longer to be the case. ducasse wrote
this is not because we do not care of Pharo that we will fix it immediately.
Yes of course, just want to keep it on the radar (and maybe Mariano will read he he) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
ducasse wrote
Our main problem is that - if more people would review PR - send PRs
Thank you for the reminder of that bottleneck. I will try to do that more now that we have moved to GH. The old process seemed too cumbersome to be able to effectively utilize a few free moments here and there, but I suspect that no longer to be the case.
Thanks yes it works well now.
ducasse wrote
this is not because we do not care of Pharo that we will fix it immediately.
Yes of course, just want to keep it on the radar (and maybe Mariano will read he he)
ducasse wrote
this is not because we do not care of Pharo that we will fix it immediately.
Yes of course, just want to keep it on the radar (and maybe Mariano will read he he)
I always do :) But honestly, I don't have enough time to carry on that myself. As you could see with latest Guillermo pass, I reviewed every PR and tried to give my advice and support as much as possible. Best regards, -- Mariano https://twitter.com/MartinezPeck http://marianopeck.wordpress.com
Hi Mariano, On Sun, Mar 17, 2019 at 08:29:59PM -0300, Mariano Martinez Peck wrote:
ducasse wrote
this is not because we do not care of Pharo that we will fix it immediately.
Yes of course, just want to keep it on the radar (and maybe Mariano will read he he)
I always do :)
Me too :-)
But honestly, I don't have enough time to carry on that myself. As you could see with latest Guillermo pass, I reviewed every PR and tried to give my advice and support as much as possible.
I saw Sean's earlier email (see below) which reminded me of your ideas about having a child process listener that could provide child exit notifications to both OSSubprocess and OSProcess. This seems to me to be the right thing to do, but it would take some work by somebody (not by me, but it could be done). Meanwhile, prompted by Sean's <bump>, I think maybe I see another way that we could handle the problem, at least in the near term. On Fri, Mar 15, 2019 at 01:42:26PM -0500, Sean P. DeNigris wrote:
Max Leske wrote
I was talking about OSSubProcess Well, I'm not working with that at the moment ;)
[OT] Just want to bump the problem that OSProcess and OSSubProcess can't currently be used in the same image. This is an important problem because users can't control which library dependencies use. Mariano hinted at a solution. It didn't seem like a ton of work, but it's beyond my understanding.
I think I see another way that this can be handled for an image that contains both OSSubprocess and OSProcess. I loaded both into a Pharo 7 image, then added this: OSSVMProcess>>update: aParameter "If subscribed to events from the OSProcess child watcher, the changed/update: mechanism will dispatch child exit notification here. To subscribe to notification from OSProcess add the singleton OSSVMProcess as a dependent of the OSProcess accessor singleton. When any child process exits, this method will be called with parameter #childProcessStatus" "OSProcess accessor addDependent: OSSVMProcess vmProcess" (aParameter == #childProcessStatus) ifTrue: [^ self updateActiveChildrenAndNotifyDead]. I stopped the child watcher in OSSVMProcess (by commenting out the last two lines in OSSVMProcess>>initialize just to see if this would work), then added the changed/update: dependency with "OSProcess accessor addDependent: OSSVMProcess vmProcess" After restarting the image, it appears to be working, at least so far has having both OSP and OSSP handle their child process exits properly in the same image. I don't have time to play with this any more right now, but it does look like it might be a workable approach. It should be possible to have the initializer for OSSVMProcess use its normal child exit handler, but hook into the OSP handler instead if that happens to be present in the image. Dave
On Mon, 18 Mar 2019 at 10:20, David T. Lewis <lewis@mail.msen.com> wrote:
Hi Mariano,
On Sun, Mar 17, 2019 at 08:29:59PM -0300, Mariano Martinez Peck wrote:
ducasse wrote
this is not because we do not care of Pharo that we will fix it immediately.
Yes of course, just want to keep it on the radar (and maybe Mariano
will
read he he)
I always do :)
Me too :-)
But honestly, I don't have enough time to carry on that myself. As you could see with latest Guillermo pass, I reviewed every PR and tried to give my advice and support as much as possible.
I saw Sean's earlier email (see below) which reminded me of your ideas about having a child process listener that could provide child exit notifications to both OSSubprocess and OSProcess.
What about this being even more generic, so child native process/threads can be viewed from the Image similar to Process Browser? I'm not entirely sure of the use case, just wild speculation something like that might be useful when Threaded-FFI arrives. cheers -ben
Thanks Dave! Guille was taking care of OSSubprocess recently. I fixed bugs and issues last year. I do not think that mariano is looking at it. Stef
On 18 Mar 2019, at 03:19, David T. Lewis <lewis@mail.msen.com> wrote:
Hi Mariano,
On Sun, Mar 17, 2019 at 08:29:59PM -0300, Mariano Martinez Peck wrote:
ducasse wrote
this is not because we do not care of Pharo that we will fix it immediately.
Yes of course, just want to keep it on the radar (and maybe Mariano will read he he)
I always do :)
Me too :-)
But honestly, I don't have enough time to carry on that myself. As you could see with latest Guillermo pass, I reviewed every PR and tried to give my advice and support as much as possible.
I saw Sean's earlier email (see below) which reminded me of your ideas about having a child process listener that could provide child exit notifications to both OSSubprocess and OSProcess. This seems to me to be the right thing to do, but it would take some work by somebody (not by me, but it could be done).
Meanwhile, prompted by Sean's <bump>, I think maybe I see another way that we could handle the problem, at least in the near term.
On Fri, Mar 15, 2019 at 01:42:26PM -0500, Sean P. DeNigris wrote:
Max Leske wrote
I was talking about OSSubProcess Well, I'm not working with that at the moment ;)
[OT] Just want to bump the problem that OSProcess and OSSubProcess can't currently be used in the same image. This is an important problem because users can't control which library dependencies use. Mariano hinted at a solution. It didn't seem like a ton of work, but it's beyond my understanding.
I think I see another way that this can be handled for an image that contains both OSSubprocess and OSProcess. I loaded both into a Pharo 7 image, then added this:
OSSVMProcess>>update: aParameter "If subscribed to events from the OSProcess child watcher, the changed/update: mechanism will dispatch child exit notification here. To subscribe to notification from OSProcess add the singleton OSSVMProcess as a dependent of the OSProcess accessor singleton. When any child process exits, this method will be called with parameter #childProcessStatus"
"OSProcess accessor addDependent: OSSVMProcess vmProcess"
(aParameter == #childProcessStatus) ifTrue: [^ self updateActiveChildrenAndNotifyDead].
I stopped the child watcher in OSSVMProcess (by commenting out the last two lines in OSSVMProcess>>initialize just to see if this would work), then added the changed/update: dependency with "OSProcess accessor addDependent: OSSVMProcess vmProcess"
After restarting the image, it appears to be working, at least so far has having both OSP and OSSP handle their child process exits properly in the same image.
I don't have time to play with this any more right now, but it does look like it might be a workable approach. It should be possible to have the initializer for OSSVMProcess use its normal child exit handler, but hook into the OSP handler instead if that happens to be present in the image.
Dave
Hi Max, use the following to load OSProcess: Metacello new configuration: 'OSProcess'; repository: 'http://www.squeaksource.com/MetacelloRepository'; load As I said a while ago, the ifNotNilDo: thing was corrected long ago and that configuration updated; the one in the catalog is limited to Pharo 6. Thierry Le lun. 11 mars 2019 à 08:00, Max Leske <maxleske@gmail.com> a écrit :
Hi all,
Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else?
Cheers, Max
On 11 Mar 2019, at 9:38, Thierry Goubier wrote:
Hi Max,
use the following to load OSProcess:
Metacello new configuration: 'OSProcess'; repository: 'http://www.squeaksource.com/MetacelloRepository'; load
As I said a while ago, the ifNotNilDo: thing was corrected long ago and that configuration updated; the one in the catalog is limited to Pharo 6.
Perfect, that worked. Thanks!
Thierry
Le lun. 11 mars 2019 à 08:00, Max Leske <maxleske@gmail.com> a écrit :
Hi all,
Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else?
Cheers, Max
participants (8)
-
Ben Coman -
David T. Lewis -
ducasse -
Mariano Martinez Peck -
Max Leske -
Sean P. DeNigris -
Thierry Goubier -
Tim Mackinnon