Re: OSProcess for Pharo 7
Locked
 
|
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 <[hidden email]> 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 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 <[hidden email]> 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 > |
|
|
In reply to this post by ducasse
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 >>>> >> |
|
|
In reply to this post by ducasse
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: > > > >> On 14 Mar 2019, at 17:33, Max Leske <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >> >> >> >>> On 14 Mar 2019, at 17:33, Max Leske <[hidden email]> 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 <[hidden email]> 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 >>>>>>> >>>>> >>> >> >> >> > > |
|
|
Ohh - yeah, I can’t use that as it doesn’t support windows right? (It’s all a bit confusing)
Tim Sent from my iPhone Sent from my iPhone > On 14 Mar 2019, at 19:00, ducasse <[hidden email]> wrote: > > I was talking about OSSubProcess |
|
|
In reply to this post by ducasse
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 <[hidden email]> 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 <[hidden email]> wrote: >>> >>> >>> >>>> On 14 Mar 2019, at 17:33, Max Leske <[hidden email]> 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 <[hidden email]> 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 >>>>>>>> >>>>>> >>>> >>> >>> >>> >> >> |
|
Administrator
|
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
Cheers,
Sean |
|
|
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 <[hidden email]> 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 > |
|
Administrator
|
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
Cheers,
Sean |
|
|
> 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) |
Re: OSProcess for Pharo 7
|
|
In reply to this post by Sean P. DeNigris
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, |
|
|
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 <[hidden email]> wrote: Hi Mariano, 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 |
|
|
In reply to this post by David T. Lewis
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 <[hidden email]> 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 > > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |