Smalltalk › Pharo › Pharo Smalltalk Developers

osprocess in pharo 2.0

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

13 messages Options

Tudor Girba-2

osprocess in pharo 2.0

Hi,

For some reason I thought that OSProcess was integrated in Pharo 2.0, but it appears that it is not in the image. Did I understand the issue incorrectly, or was the class renamed to something else?

If it is not in the image, was it already ported to SmalltalkHub? (I could not find it)

I am asking because I would like to know if we should continue to load OSProcess explicitly with Moose.

Cheers,
Doru

--
www.tudorgirba.com

"Not knowing how to do something is not an argument for how it cannot be done."

stephane ducasse

Re: osprocess in pharo 2.0

good question.

> For some reason I thought that OSProcess was integrated in Pharo 2.0, but it appears that it is not in the image. Did I understand the issue incorrectly, or was the class renamed to something else?

we did not renamed the class
>
> If it is not in the image, was it already ported to SmalltalkHub? (I could not find it)

No because david did not move it. I could do it but I was waiting for him.
>
> I am asking because I would like to know if we should continue to load OSProcess explicitly with Moose.

EstebanLM

Re: osprocess in pharo 2.0

OSProcess was not ready for 2.0 when we closed the beta, so we did not include it.
Now is working fine but since we are hours from release, is not good to have it there by default now (it will be for 3.0. then)... it would be really cool to have a metacello configuration in MetaRepoForPharo20, though.

Esteban

On Mar 6, 2013, at 6:38 PM, stephane ducasse <[hidden email]> wrote:

> good question.
>
>> For some reason I thought that OSProcess was integrated in Pharo 2.0, but it appears that it is not in the image. Did I understand the issue incorrectly, or was the class renamed to something else?
>
> we did not renamed the class
>>
>> If it is not in the image, was it already ported to SmalltalkHub? (I could not find it)
>
> No because david did not move it. I could do it but I was waiting for him.
>>
>> I am asking because I would like to know if we should continue to load OSProcess explicitly with Moose.
>
>

Tudor Girba-2

Re: osprocess in pharo 2.0

Hi,

Thanks for the answers.

It's no problem that it is not in 2.0. I just wanted to make sure. It's already great that it works with 2.0.

Cheers,
Doru

On Mar 6, 2013, at 7:43 PM, Esteban Lorenzano <[hidden email]> wrote:

> OSProcess was not ready for 2.0 when we closed the beta, so we did not include it.
> Now is working fine but since we are hours from release, is not good to have it there by default now (it will be for 3.0. then)... it would be really cool to have a metacello configuration in MetaRepoForPharo20, though.
>
> Esteban
>
> On Mar 6, 2013, at 6:38 PM, stephane ducasse <[hidden email]> wrote:
>
>> good question.
>>
>>> For some reason I thought that OSProcess was integrated in Pharo 2.0, but it appears that it is not in the image. Did I understand the issue incorrectly, or was the class renamed to something else?
>>
>> we did not renamed the class
>>>
>>> If it is not in the image, was it already ported to SmalltalkHub? (I could not find it)
>>
>> No because david did not move it. I could do it but I was waiting for him.
>>>
>>> I am asking because I would like to know if we should continue to load OSProcess explicitly with Moose.
>>
>>
>
>

--
www.tudorgirba.com

"Every now and then stop and ask yourself if the war you're fighting is the right one."

Sean P. DeNigris

Re: osprocess in pharo 2.0

Administrator

In reply to this post by EstebanLM

EstebanLM wrote

it would be really cool to have a metacello configuration in MetaRepoForPharo20

There is one there :)

Cheers,
Sean

Camillo Bruni-3

Re: osprocess in pharo 2.0

On 2013-03-07, at 22:35, "Sean P. DeNigris" <[hidden email]> wrote:
> EstebanLM wrote
>> it would be really cool to have a metacello configuration in
>> MetaRepoForPharo20
>
> There is one there :)

I wonder why it fails on the build-server?

https://ci.inria.fr/pharo-contribution/job/OSProcess/

Sean P. DeNigris

Re: osprocess in pharo 2.0

Administrator

On Mar 8, 2013, at 3:49 AM, Camillo Bruni-3 [via Smalltalk] <[hidden email]> wrote:
> I wonder why it fails on the build-server?
It fails because ThisOSProcess class>>shutDown: includes "OSProcess accessor breakDependents", but OSProcess accessor returns nil because none of the platform packages are loaded by the 'Tests' group of ConfigurationOfOSProcess.

You can load 'Tests' and 'All OS' via "--groups='All OS',Tests" with the slice for "Issue 7662: [ENH]: ConfigurationCommandLineHandler: Accept multiple group names"

Going forward, I'm not sure whether Tests should depend on the OS packages. You may want to load just the current OS, for example. I think probably a good error message and maybe a retry to find a suitable OS class if the accessor is nil...

cc: David Lewis

Cheers,
Sean

Camillo Bruni-3

Re: osprocess in pharo 2.0

thanks, I changed it and it sort of works: https://ci.inria.fr/pharo-contribution/job/OSProcess/
though an impressive number of 81 tests fail, that is almost 50% of all the tests.
Is that normal?

On 2013-03-08, at 17:13, "Sean P. DeNigris" <[hidden email]> wrote:

> On Mar 8, 2013, at 3:49 AM, Camillo Bruni-3 [via Smalltalk] <[hidden email]> wrote:
>> I wonder why it fails on the build-server?
> It fails because ThisOSProcess class>>shutDown: includes "OSProcess accessor breakDependents", but OSProcess accessor returns nil because none of the platform packages are loaded by the 'Tests' group of ConfigurationOfOSProcess.
>
> You can load 'Tests' and 'All OS' via "--groups='All OS',Tests" with the slice for "Issue 7662: [ENH]: ConfigurationCommandLineHandler: Accept multiple group names"
>
> Going forward, I'm not sure whether Tests should depend on the OS packages. You may want to load just the current OS, for example. I think probably a good error message and maybe a retry to find a suitable OS class if the accessor is nil...
>
> cc: David Lewis
>
>
>
>
>
> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/osprocess-in-pharo-2-0-tp4674453p4675783.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

David T. Lewis

Re: osprocess in pharo 2.0

In reply to this post by Sean P. DeNigris

On Fri, Mar 08, 2013 at 08:13:19AM -0800, Sean P. DeNigris wrote:
> On Mar 8, 2013, at 3:49 AM, Camillo Bruni-3 [via Smalltalk] <[hidden email]> wrote:
> > I wonder why it fails on the build-server?
> It fails because ThisOSProcess class>>shutDown: includes "OSProcess accessor breakDependents", but OSProcess accessor returns nil because none of the platform packages are loaded by the 'Tests' group of ConfigurationOfOSProcess.
>

Thanks Sean,

So I should add a nil check in the shutDown: method, right? I'll do it later tonight when I get home.

Dave

David T. Lewis

Re: osprocess in pharo 2.0

In reply to this post by Camillo Bruni-3

On Fri, Mar 08, 2013 at 05:27:04PM +0100, Camillo Bruni wrote:
> thanks, I changed it and it sort of works: https://ci.inria.fr/pharo-contribution/job/OSProcess/
> though an impressive number of 81 tests fail, that is almost 50% of all the tests.
> Is that normal?
>

I wouldn't call in "normal", but the full test suite requires an interpreter
VM on Unix.

To check for failures associated with the image, as opposed to VM features,
I need to run the tests on an interpreter VM. Unfortunately I cannot open
a Pharo image on an interpreter VM any more, possibly due to something failing
in the startUp sequence. If anyone can explain what has changed I'd appreciate
the help, because I have not been able to figure it out.

Dave

David T. Lewis

Re: osprocess in pharo 2.0

In reply to this post by David T. Lewis

On Fri, Mar 08, 2013 at 11:58:38AM -0500, David T. Lewis wrote:
> On Fri, Mar 08, 2013 at 08:13:19AM -0800, Sean P. DeNigris wrote:
> > On Mar 8, 2013, at 3:49 AM, Camillo Bruni-3 [via Smalltalk] <[hidden email]> wrote:
> > > I wonder why it fails on the build-server?
> > It fails because ThisOSProcess class>>shutDown: includes "OSProcess accessor breakDependents", but OSProcess accessor returns nil because none of the platform packages are loaded by the 'Tests' group of ConfigurationOfOSProcess.
> >
>
> Thanks Sean,
>
> So I should add a nil check in the shutDown: method, right? I'll do it later tonight when I get home.

Fixed in OSProcess-Base-dtl.31

Dave

Sean P. DeNigris

Re: osprocess in pharo 2.0

Administrator

In reply to this post by David T. Lewis

David T. Lewis wrote

So I should add a nil check in the shutDown: method, right?

Would it be a good idea to do a lazy initialization in #accessor? For example, if I load Base, and then I separately add the OS packages, I think I would have to manually reinitialize OSP before they will be picked up...

Cheers,
Sean

David T. Lewis

Re: osprocess in pharo 2.0

On Fri, Mar 08, 2013 at 05:25:55PM -0800, Sean P. DeNigris wrote:
> David T. Lewis wrote
> > So I should add a nil check in the shutDown: method, right?
>
> Would it be a good idea to do a lazy initialization in #accessor? For
> example, if I load Base, and then I separately add the OS packages, I think
> I would have to manually reinitialize OSP before they will be picked up...
>

ThisOSProcess>>processAccessor already is lazy initialized. I think that
this particular issue was probably caused by doing a shutDown: with no
processor accessor, which I think might happen if the image was running
on e.g. RISC OS. So I fixed the shutDown: so it will not fail in a case
like that.

If someone was running the unit tests for OSProcess and did not have
the platform package(s) loaded, then the tests will fail. That is a
test configuration issue.

Dave