- Pharo-dev - lists.pharo.org

Re: [Pharo-project] 20381 running the test does not work ...

by StÃ©phane Ducasse

SystemProgressMorph show: 'Doing...' from: 0 to: 1 during: [ :bar | 1 to: 2 do: [ :x | bar current: x. (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ]. Works while SystemProgressMorph show: 'Doing...' from: 1 to: 1 during: [ :bar | 1 to: 2 do: [ :x | bar current: x. (Delay forMilliseconds: 20) wait "Just to slow it down so we can see what's going on" ] ]. not :) 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 <stephane.ducasse(a)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(a)gmail.com > www.teodorov.ro

Nov. 3, 2012

Re: [Pharo-project] 20381 running the test does not work ...

by StÃ©phane Ducasse

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 <stephane.ducasse(a)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(a)gmail.com > www.teodorov.ro

Nov. 3, 2012

Re: [Pharo-project] 20381 running the test does not work ...

by StÃ©phane Ducasse

Ouch two problems! I'm also wondering why we have SystemProgressItemMorph and ProgressBarMorph in addition to SystemProgressMorph and of course JobProgressMorph and JobProgressBarMorph to me it looks like this is ok to have - one with the forbidden flag = JobProgressMorph - a default one = SystemProgressMorph and the bar = ProgressBarMorph and I saw that the size of the SystemProgressMorph is not passed to the its inner elements leading to this ugly bar getting out of the size of the progress bar. 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 <stephane.ducasse(a)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(a)gmail.com > www.teodorov.ro

Nov. 3, 2012

[Pharo-project] Job ProgressBar logic is bogus

by StÃ©phane Ducasse

Job ProgressBar logic is bogus here we have: progress ^ (currentValue - min) / (max - min) raises ZeroDivide. and progress is invoked by basicProgress: basicProgress: aNormalizedFloat "Set the progress: 0.0 - 1.0 without triggering an update" currentValue := (min + ((max - min) * aNormalizedFloat)) In my case I have currentValue, min and max = 1 does anybody know this code? and how we can fix it. How to reproduce the problem MCStReaderTest debug: #testCommentWithStyle Here we have fileInFrom: aStream | changes | changes := ChangeSet scanFile: aStream from: 0 to: aStream size. aStream close. ('Processing ', self packageName) displayProgressFrom: 1 ^^^^^ which set the min to 1. Setting it to 0 can solve the problem but the progress bar should be more robust to: changes size ^^^^^^^^^^ max to 1 during:[:bar| | chgRec | 1 to: changes size do:[:i| bar current: i. chgRec := changes at: i. self perform: (chgRec type copyWith: $:) asSymbol with: chgRec. ]. ]. Stef

Nov. 3, 2012

Re: [Pharo-project] 20381 running the test does not work ...

by Ciprian Teodorov

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(a)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(a)gmail.com www.teodorov.ro

Nov. 3, 2012

Re: [Pharo-project] 20381 running the test does not work ...

by StÃ©phane Ducasse

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: >>> >> > >

Nov. 3, 2012

Re: [Pharo-project] 20381 running the test does not work ...

by StÃ©phane Ducasse

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: >> >

Nov. 3, 2012

Re: [Pharo-project] 20381 running the test does not work ...

by StÃ©phane Ducasse

Executing this test method leads to an error MCStReaderTest debug: #testCommentWithStyle SmallInteger>>/ Job>>progress JobChange>>progress SystemProgressMorph class>>updateJob: MessageSend>>value: MessageSend>>cull: MessageSend>>cull:cull: AnnouncementSubscription>>deliver: in Block: [action cull: anAnnouncement cull: announcer] BlockClosure>>on:do: BlockClosure>>on:fork: in Block: [Processor terminateActive] testCommentWithStyle "self debug: #testCommentWithStyle" | reader | reader := MCStReader on: self commentWithStyle readStream. reader definitions But the error is raised by the progress bar Job>>progress ^ (currentValue - min) / (max - min) Raises a ZeroDivide Because max and min are equal to 1. What is really strange is that if I try with another test - green it will run perfectly - if I introduce a bug in another green test it will run and lead to the debugger and not the error SmallInteger>>/ Job>>progress JobChange>>progress SystemProgressMorph class>>updateJob: MessageSend>>value: MessageSend>>cull: MessageSend>>cull:cull: AnnouncementSubscription>>deliver: in Block: [action cull: anAnnouncement cull: announcer] BlockClosure>>on:do: BlockClosure>>on:fork: in Block: [Processor terminateActive]

Nov. 3, 2012

Re: [Pharo-project] How to load MetacelloToolbox

by Dale Henrichs

Out of curiosity, what are some of the undeclared references? There shouldn't be any undeclared references, unless you ignored the required packages or ??? offhand I can't imagine what they might be... Dale ----- Original Message ----- | From: "Esteban Lorenzano" <estebanlm(a)gmail.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Friday, November 2, 2012 6:51:42 AM | Subject: Re: [Pharo-project] How to load MetacelloToolbox | | because MetacelloToolbox shouldn't be in 2.0, I told you :) | | On Nov 2, 2012, at 2:48 PM, Camillo Bruni <camillobruni(a)gmail.com> | wrote: | | > we recently pushed MetacelloToolbox into Pharo2.0. | > However we have tons of undeclared references. | > | > Where do I find the complete sources? | > | | |

Nov. 3, 2012

Re: [Pharo-project] 20381 running the test does not work ...

by StÃ©phane Ducasse

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. 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: >

Nov. 3, 2012