November 2012 - Pharo-dev - lists.pharo.org

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

by StÃ©phane Ducasse

While riding under the rain I was thinking and I guess that SystemProgressMorph => singleton that accepts several tasks and bars ProgressBarMorph => basic elements Job: progress bar + title + I will probably repackage this together and add comments then I will try to fix the size problem. Stef On Nov 3, 2012, at 10:48 PM, StÃ©phane Ducasse wrote: > 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. 4, 2012

Re: [Pharo-project] Are the any Fuel file analysis tools/techniques?

by Yanni Chiu

[cc: Seaside and Pier mailing lists] Postmortem, no polished code... First tried the "space" analysis tool from the "status" application tool of Seaside. It showed only objects with more than 100 instances, which did not give much useful info. with my data set. I suppose I could have changed the threshold. Second try: since the exported structure is a Pier kernel, I created a subclass of PRVisitor that visited each structure and its children, printing each structure on the Transcript. It did not find any extra objects in the deserialized kernel. Third try: create another PRVisitor that visited the kernel using #instVarAt: and #at: for variable classes. Again, it did not locate the extra objects. Fourth try: somehow inspired to examine #fuelAfterMaterialization. Placed a halt where it was called. Tried to filter the calls to only the objects where my code had specialize #fuelAfterMaterialization. While trying to get this filtering right, I noticed that the materialized object was a WAUserConfiguration instance. Using explore pointers, eventually found WASession instances and whatnot, being de-serialized. Using Smalltalk>>garbageCollect and regenerating a test Pier kernel, eventually led to a single WASession instance to trace. It led to a PRComponent holding its prototypeInstance object, which then held a non-nil PRContext. The solution, add: PRWidget class>>fuelIgnoredInstanceVariableNames ^#(context) The prototypeInstance construct was introduce by Magritte3/Pier3. I didn't have this issue before moving the Pier3. Clearly, I need better test cases. On 03/11/12 5:54 AM, Max Leske wrote: > +1 I'd be very interested in that sort of thing. > > On 02.11.2012, at 19:08, Yanni Chiu > <yanni(a)rogers.com> wrote: > >> This scenario has happened a few times... Stuff is serialized and >> de-serialized (to/from files) without problem. Code changes are >> made. At some later date, I notice that the Fuel file is orders of >> magnitude bigger than it used to be. >> >> I usually manually de-serialize, and navigate the structures until >> I find the cause of the bloating. >> >> Is there some package or code snippets that can quickly summarize >> the object classes and sizes in a serialized file, or from its >> in-memory de-serialized form?

Nov. 4, 2012

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

by Ciprian Teodorov

loool... divisionByZero indeed On Sat, Nov 3, 2012 at 10:52 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > 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 > > > -- 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

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