> 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 <
stephane.ducasse@inria.fr> 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 :
ciprian.teodorov@gmail.com
>
www.teodorov.ro