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 48mail :�ciprian.teodorov@gmail.com
www.teodorov.ro