I think that the definition of progress is wrong since I was not running the JobTest.
But in addition I think that you are right, close the bars looks to me a bad idea. Stef On Nov 3, 2012, at 10:12 PM, Ciprian Teodorov wrote: > Hi Stef, > > I have seen this problem too, and I think that JobTest is guilty for this > behaviour, since its tearDown method removes all bars, even though they are > not his to remove. > Try removing the tearDown... it work in my case > > JobTest>>tearDown > SystemProgressMorph uniqueInstance bars do: [ :e | e close ]. > > I hope that this helps... > > If not I think that there is a problem with the SystemProgressMorph api in a > concurrent context... An arbitrary class should not be able to remove bars > from our nice progress morph... > > Cheers, > Ciprian > > On Sat, Nov 3, 2012 at 9:57 PM, Stéphane Ducasse <[email protected]> > wrote: > Yes apparently the code run by the test uses the progress bar (do display > progress) and at some point put its max to 1 (since there is only one > definition to process) > => boum. > > since in that case we get a zeroDivide. > > Stef > > On Nov 3, 2012, at 9:51 PM, Stéphane Ducasse wrote: > > > I'm wondering if the progress bar code is not bogus and that it is created > > with wrong values. > > > >> Apparently there was failing test which invoked a on:fork:…. > >> > >> This is strange since the processTest were red. > >> Now running them alone brings green tests. > >> > >> <Screen Shot 2012-11-03 at 7.42.47 PM.pdf> > >> Stef > >> On Nov 3, 2012, at 12:53 PM, Stéphane Ducasse wrote: > >> > >>> There is a bug blocking the image. > >>> SubscriptOutOfBounds: 0 > >>> > >>> in the SystemProgressMorph class updateJob: > >>> > >> > > > > > > > > > > -- > Dr. Ciprian TEODOROV > Ingénieur Développement CAO > > tél : 06 08 54 73 48 > mail : [email protected] > www.teodorov.ro
