Re: OSProcess for Pharo 7

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

ducasse
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
>



Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

Thierry Goubier
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
>

Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

Max Leske
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
>>

Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

ducasse
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
>>>
>



Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

Max Leske
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
>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

Max Leske
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
>>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

ducasse


> 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
>>>>>
>>>
>



Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

Tim Mackinnon
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
>>>>>>
>>>>
>>
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

ducasse
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
>>>>>>>
>>>>>
>>>
>>
>>
>>
>
>



Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

Tim Mackinnon
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


Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

Max Leske
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
>>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>>
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

ducasse
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
>



Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

Sean P. DeNigris
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
Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

ducasse

> 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)




Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

Mariano Martinez Peck
In reply to this post by Sean P. DeNigris



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, 

--
Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

David T. Lewis
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



Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

Ben Coman


On Mon, 18 Mar 2019 at 10:20, 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.

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
Reply | Threaded
Open this post in threaded view
|

Re: OSProcess for Pharo 7

ducasse
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
>
>
>