[Pharo-project] 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."
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.
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 <stephane.ducasse@free.fr> 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.
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 <estebanlm@gmail.com> 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 <stephane.ducasse@free.fr> 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."
EstebanLM wrote
it would be really cool to have a metacello configuration in MetaRepoForPharo20
There is one there :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/osprocess-in-pharo-2-0-tp4674453p4675619.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 2013-03-07, at 22:35, "Sean P. DeNigris" <sean@clipperadams.com> 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/
On Mar 8, 2013, at 3:49 AM, Camillo Bruni-3 [via Smalltalk] <ml-node+s1294792n4675680h68@n4.nabble.com> 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.
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" <sean@clipperadams.com> wrote:
On Mar 8, 2013, at 3:49 AM, Camillo Bruni-3 [via Smalltalk] <ml-node+s1294792n4675680h68@n4.nabble.com> 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.
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
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] <ml-node+s1294792n4675680h68@n4.nabble.com> 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
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] <ml-node+s1294792n4675680h68@n4.nabble.com> 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
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 -- View this message in context: http://forum.world.st/osprocess-in-pharo-2-0-tp4674453p4675867.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
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
participants (6)
-
Camillo Bruni -
David T. Lewis -
Esteban Lorenzano -
Sean P. DeNigris -
stephane ducasse -
Tudor Girba