March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] customizing the CommandLineHandler to run Moose tests

by stephane ducasse

this is cool :) > Hi, > > Now that the continuous integration build is using the cool ZeroConf infrastructure, we needed a clean way to run all tests from Moose based on the information gathered from the ConfigurationOfMoose. More precisely we want to run all the tests from all packages that are in the 'Tests' group from all configurations referred from ConfigurationOfMoose (including itself) :). > > It's sounds more complicated than it actually is: > packages > | packages | > packages := Set new. > (self mooseDevelopmentVersion packagesForSpecNamed: 'Tests') do: [ :spec | packages add: spec name ]. > self mooseDevelopmentVersion projects do: [ :each | > (each version packagesForSpecNamed: 'Tests') do: [ :spec | packages add: spec name ] ]. > ^ packages > > We used to have this logic in an .st file that was ran through the builder from Lukas. > > But, now, I simply created the MooseTestRunnerCommandLineHandler as a subclass of TestRunnerCommandLineHandler, and provided the new packages. I gave it the commandName of 'moosetest' and now I can simply call from the command line: > > Pharo ./Moose-latest-dev-4.8.image moosetest > > In Moose, we have a little package named: Moose-Development-Tools that is loaded by the configuration. I added the new class to it, and I can easily integrate the whole test running in the ci job after loading the configuration. > > I'd say it's pretty neat. > > Cheers, > Doru > > p.s. The VM still crashes when running the tests though (at least on Mac) > > -- > www.tudorgirba.com > > "Beauty is where we see it." > > > >

March 9, 2013

Re: [Pharo-project] customizing the CommandLineHandler to run Moose tests

by stephane ducasse

Hi doru can you report precisely because now we cannot take any action? Stef > > p.s. The VM still crashes when running the tests though (at least on Mac)

March 9, 2013

[Pharo-project] GSoC13: Google Summer of Code started, your ideas please!

by Janko MivÅ¡ek

Dear Smalltalkers, Time for your cool project ideas on this year Smalltalk GSoC! For now just express any idea you have here on the mailing list. Later we will together develop it to be in complete format together with two mentors needed. Deadline is end of Mart, so we have three weeks of time. To see how fully developed ideas look like please look at 2012 ones at: http://gsoc2012.esug.org/ideas. Note also that students yourselves can propose a GSoC project. So if you like to be a student on this year GSoC and have a nice idea, don't be shy and propose it here! The community will listen you and guide to the really nicely proposed project. Last year 6 student proposed projects were accepted and finished successfully! For the community, start looking around for students. Think about how to approach the universities near by you, do you know who to contact there, etc. We are namely preparing an application to this year Smalltalk Google Summer of Code under ESUG umbrella, as last year. If accepted, Google will pay few stipendiums to students on our Smalltalk projects. More on our special Smalltalk GSoC 2013 website: http://gsoc2013.esug.org I'm specially inviting mentors of all past GSoCs to rejoin the mentors mailing list, where we discuss all details about this year GSoC: http://groups.google.com/group/smalltalk-gsoc-mentors While students interested on GSoC please join a special Smalltalk GSoC mailing list for you: http://groups.google.com/group/smalltalk-gsoc-students Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

March 9, 2013

Re: [Pharo-project] access to pharoextras repository

by stephane ducasse

It would be good to have a discussion because all the packages I did do not follow this. what is the point to have a Tests group if the core and default already load them? > Hi, > > Could anyone provide me with access to the PharoExtras team on STHub? > > I would need to modify a bit the ConfigurationOfXMLParser to load both Core and Tests by default. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "If you can't say why something is relevant, > it probably isn't." > >

March 9, 2013

Re: [Pharo-project] access to pharoextras repository

by Camillo Bruni

aaan, you're a member On 2013-03-09, at 03:28, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Could anyone provide me with access to the PharoExtras team on STHub? > > I would need to modify a bit the ConfigurationOfXMLParser to load both Core and Tests by default. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "If you can't say why something is relevant, > it probably isn't." > >

March 9, 2013

[Pharo-project] customizing the CommandLineHandler to run Moose tests

by Tudor Girba

Hi, Now that the continuous integration build is using the cool ZeroConf infrastructure, we needed a clean way to run all tests from Moose based on the information gathered from the ConfigurationOfMoose. More precisely we want to run all the tests from all packages that are in the 'Tests' group from all configurations referred from ConfigurationOfMoose (including itself) :). It's sounds more complicated than it actually is: packages | packages | packages := Set new. (self mooseDevelopmentVersion packagesForSpecNamed: 'Tests') do: [ :spec | packages add: spec name ]. self mooseDevelopmentVersion projects do: [ :each | (each version packagesForSpecNamed: 'Tests') do: [ :spec | packages add: spec name ] ]. ^ packages We used to have this logic in an .st file that was ran through the builder from Lukas. But, now, I simply created the MooseTestRunnerCommandLineHandler as a subclass of TestRunnerCommandLineHandler, and provided the new packages. I gave it the commandName of 'moosetest' and now I can simply call from the command line: Pharo ./Moose-latest-dev-4.8.image moosetest In Moose, we have a little package named: Moose-Development-Tools that is loaded by the configuration. I added the new class to it, and I can easily integrate the whole test running in the ci job after loading the configuration. I'd say it's pretty neat. Cheers, Doru p.s. The VM still crashes when running the tests though (at least on Mac) -- www.tudorgirba.com "Beauty is where we see it."

March 9, 2013

Re: [Pharo-project] osprocess in pharo 2.0

by David T. Lewis

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

March 9, 2013

[Pharo-project] access to pharoextras repository

by Tudor Girba

Hi, Could anyone provide me with access to the PharoExtras team on STHub? I would need to modify a bit the ConfigurationOfXMLParser to load both Core and Tests by default. Cheers, Doru -- www.tudorgirba.com "If you can't say why something is relevant, it probably isn't."

March 9, 2013

Re: [Pharo-project] osprocess in pharo 2.0

by Sean P. DeNigris

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.

March 9, 2013

Re: [Pharo-project] osprocess in pharo 2.0

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] <ml-node+s1294792n4675680h68(a)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

March 8, 2013