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