- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] last opened window does not go away

by Marcus Denker

Ups, wrong threadâ¦ > On 16 Nov 2015, at 11:47, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > I can not reproduce it with a recent vmâ¦ > >> On 16 Nov 2015, at 11:44, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Andrei, >> >> you should be able to use whatever the equivalent of the PointerFinder is these days to find out. Once you have your instances from all instances you can find the path from the roots that is keeping them alive via PoinerFinder openOn: anInstance IIRC. >> >> _,,,^..^,,,_ (phone) >> >>> On Nov 16, 2015, at 6:22 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >>> >>> Hi, >>> >>> In the latest Pharo image there is a rogue instance of GLMSystemWindow. >>> If I do in the console the following code I get one instance: >>> >>> /pharo Pharo.image eval "GLMSystemWindow allInstances" >>> an Array(a GLMSystemWindow(58720256)) >>> >>> There are actually two windows, but one is RubFindReplaceDialogWindow and it should have no link with the glamour window. >>> >>> ./pharo Pharo.image eval "SystemWindow allSubInstances" >>> an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a GLMSystemWindow(58720256)) >>> >>> If I create another window that contains a morph that can take the focus then the glamour window disappears and the new window stays: >>> >>> ./pharo Pharo.image eval "(PluggableTextMorph on: ' ' text: nil accept: nil) openInWindow close. Smalltalk garbageCollect. SystemWindow allSubInstances" >>> an OrderedCollection(a SystemWindow(234094592) an EditorFindReplaceDialogWindow(130547712)) >>> >>> Any idea if the find-replace service from rubric/textmorph holds one somehow to the last opened window or if there is another global cache that does it? >>> >>> Cheers, >>> Andrei >> >

Nov. 16, 2015

Re: [Pharo-dev] last opened window does not go away

by Marcus Denker

I can not reproduce it with a recent vmâ¦ > On 16 Nov 2015, at 11:44, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Andrei, > > you should be able to use whatever the equivalent of the PointerFinder is these days to find out. Once you have your instances from all instances you can find the path from the roots that is keeping them alive via PoinerFinder openOn: anInstance IIRC. > > _,,,^..^,,,_ (phone) > >> On Nov 16, 2015, at 6:22 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: >> >> Hi, >> >> In the latest Pharo image there is a rogue instance of GLMSystemWindow. >> If I do in the console the following code I get one instance: >> >> /pharo Pharo.image eval "GLMSystemWindow allInstances" >> an Array(a GLMSystemWindow(58720256)) >> >> There are actually two windows, but one is RubFindReplaceDialogWindow and it should have no link with the glamour window. >> >> ./pharo Pharo.image eval "SystemWindow allSubInstances" >> an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a GLMSystemWindow(58720256)) >> >> If I create another window that contains a morph that can take the focus then the glamour window disappears and the new window stays: >> >> ./pharo Pharo.image eval "(PluggableTextMorph on: ' ' text: nil accept: nil) openInWindow close. Smalltalk garbageCollect. SystemWindow allSubInstances" >> an OrderedCollection(a SystemWindow(234094592) an EditorFindReplaceDialogWindow(130547712)) >> >> Any idea if the find-replace service from rubric/textmorph holds one somehow to the last opened window or if there is another global cache that does it? >> >> Cheers, >> Andrei >

Nov. 16, 2015

Re: [Pharo-dev] last opened window does not go away

by Eliot Miranda

Hi Andrei, you should be able to use whatever the equivalent of the PointerFinder is these days to find out. Once you have your instances from all instances you can find the path from the roots that is keeping them alive via PoinerFinder openOn: anInstance IIRC. _,,,^..^,,,_ (phone) > On Nov 16, 2015, at 6:22 AM, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi, > > In the latest Pharo image there is a rogue instance of GLMSystemWindow. > If I do in the console the following code I get one instance: > > /pharo Pharo.image eval "GLMSystemWindow allInstances" > an Array(a GLMSystemWindow(58720256)) > > There are actually two windows, but one is RubFindReplaceDialogWindow and it should have no link with the glamour window. > > ./pharo Pharo.image eval "SystemWindow allSubInstances" > an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a GLMSystemWindow(58720256)) > > If I create another window that contains a morph that can take the focus then the glamour window disappears and the new window stays: > > ./pharo Pharo.image eval "(PluggableTextMorph on: ' ' text: nil accept: nil) openInWindow close. Smalltalk garbageCollect. SystemWindow allSubInstances" > an OrderedCollection(a SystemWindow(234094592) an EditorFindReplaceDialogWindow(130547712)) > > Any idea if the find-replace service from rubric/textmorph holds one somehow to the last opened window or if there is another global cache that does it? > > Cheers, > Andrei

Nov. 16, 2015

Re: [Pharo-dev] Help me to understand where I screwed up QAâ¦

by Eliot Miranda

Hi Yuriy, this looks like an old VM bug. Are you sure you're using the most up-to-date VM? _,,,^..^,,,_ (phone) > On Nov 16, 2015, at 6:02 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > Hi everyone, > > this is a weird issue that wasnât there when I was developing the feature. > > If inspector plugin is enabled in prefs and you inspect a method (e.g. Object>>#asString) you get âMessageNotUnderstood: SmallInteger>>notEmptyâ on â(critics := self critics) notEmptyâ. If you inspect critics temporary itâs a Set, if you restart in debugger and step over it works well, but for some reason initially notEmpty is sent to some int. Any idea what is the issue? > > Cheers, > Uko

Nov. 16, 2015

last opened window does not go away

by Andrei Chis

Hi, In the latest Pharo image there is a rogue instance of GLMSystemWindow. If I do in the console the following code I get one instance: /pharo Pharo.image eval "GLMSystemWindow allInstances" an Array(a GLMSystemWindow(58720256)) There are actually two windows, but one is RubFindReplaceDialogWindow and it should have no link with the glamour window. ./pharo Pharo.image eval "SystemWindow allSubInstances" an OrderedCollection(a RubFindReplaceDialogWindow(534511616) a GLMSystemWindow(58720256)) If I create another window that contains a morph that can take the focus then the glamour window disappears and the new window stays: ./pharo Pharo.image eval "(PluggableTextMorph on: ' ' text: nil accept: nil) openInWindow close. Smalltalk garbageCollect. SystemWindow allSubInstances" an OrderedCollection(a SystemWindow(234094592) an EditorFindReplaceDialogWindow(130547712)) Any idea if the find-replace service from rubric/textmorph holds one somehow to the last opened window or if there is another global cache that does it? Cheers, Andrei

Nov. 16, 2015

Help me to understand where I screwed up QAâ¦

by Yuriy Tymchuk

Hi everyone, this is a weird issue that wasnât there when I was developing the feature. If inspector plugin is enabled in prefs and you inspect a method (e.g. Object>>#asString) you get âMessageNotUnderstood: SmallInteger>>notEmptyâ on â(critics := self critics) notEmptyâ. If you inspect critics temporary itâs a Set, if you restart in debugger and step over it works well, but for some reason initially notEmpty is sent to some int. Any idea what is the issue? Cheers, Uko

Nov. 16, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Andrei Chis

Also you do not have to run it from the command line to reproduce the error. You can just execute in a playground: CommandLineTestRunner runClasses: {GLMPagerMorphTest . GLMTreeMorphicTest. GLMWatcherMorphicTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests'). But if you run the same tests using a script then there is no block: suite := TestSuite named: 'x'. classes := {GLMPagerMorphTest . GLMTreeMorphicTest. GLMWatcherMorphicTest} asSortedCollection: [ :a :b | a name <= b name ]. classes do: [ :each | each addToSuiteFromSelectors: suite ]. runner := TestRunner new . Author uniqueInstance ifUnknownAuthorUse: 'hudson' during: [ runner runSuite: suite ]. On Mon, Nov 16, 2015 at 2:25 PM, Max Leske <maxleske(a)gmail.com> wrote: > Interestingly, if I change the delay in that method from 400 to 0 I get > the same effect (namely, it doesnât hang). So maybe itâs a problem with > delay scheduling from low priority processes? > > > On 16 Nov 2015, at 14:12, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi, > > Any news on this? > > Might be totally unrelated but I went back and searched for the the first > version where [1] blocks. > In my case the first version where it blocks is Pharo-40520. > In Pharo-40519 it works ok. > 40520 integrated https://pharo.fogbugz.com/f/cases/14993 which does a lot > of changes, but one changed that this issue did is introduced an async > tasks for updating the scrolling in inspector. > > Next if in the latest version I change in > GLMScrollPaneBandBrick>>onChildrenLayouted the priority of asyncTask from > 'Processor lowestPriority' to 'Processor userBackgroundPriority + 1' > then #testBenchFor does not block. If I change the priority to the initial > one it blocks again. At least on my machine this is consistent. > > Not sure if this fixes the bug on the CI but I updated issue 16957 > <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> to > include this change. > Can you try to integrate the issue and see if it still blocks. > > Cheers, > Andrei > > > > [1] ./pharo Pharo.image eval "CommandLineTestRunner runClasses: > {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. > CommandLineTestRunner runPackages: #('Kernel-Tests')" > > > > On Thu, Nov 12, 2015 at 9:21 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> I found a single test method I could use to narrow down the problem (be >> aware that this might not work for you. I have other (fresh) images where >> the issue never occurs). The method I used >> is EpRedoAndUndoVisitorTest>>testClassModification. >> >> I was able to mitigate the hang by making a small modification to the >> method EpUndoVisitor>>visitClassModification: Simply add >> >> 2 seconds asDelay wait. Smalltalk garbageCollect. >> >> or >> >> Smalltalk garbageCollect. 2 seconds asDelay wait. >> >> after the compilation phase. My guess is, that announcements build up (a >> simple printout showed 1 announcement instance before and 74 instances >> after the #evaluate:) and do stuff in the system that influence the process >> scheduling. For instance, a lot of those announcements will probably be >> weak and need to be finalized at some point. >> >> I donât have enough experience with the ClassBuilder to go on hunting but >> this should hopefully give you a good head start. >> > > >> >> >> For testing I used the following command line: >> >> ./pharo found_case.image eval "CommandLineTestRunner runPackages: >> #('Epicea' 'Kernel-Testsâ)" >> >> Install Epicea with >> >> ./pharo Pharo.image get Epicea 6.5 >> >> >> To isolate the test case I simply moved test classes from Epicea to a >> differently named package and once I had found the class I started >> excluding methods (e.g. with âself fail.â at the beginning). >> >> >> HTH, >> Max >> >> >> >> >> On 12 Nov 2015, at 18:57, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> Yes! with Max Leske we have been isolating the problem and we realized >> that a fresh image was enough: >> >> 1) >> curl get.pharo.org/50+vm | bash >> >> 2) >> ./pharo Pharo.image eval "CommandLineTestRunner runClasses: >> {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. >> CommandLineTestRunner runPackages: #('Kernel-Tests')" >> >> Martin >> >> On Thu, Nov 12, 2015 at 6:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >>> Then it must be that waiting on the delay never ends, which is probably >>> a problem all by itself. >>> >>> > On 12 Nov 2015, at 18:39, Marcus Denker <marcus.denker(a)inria.fr> >>> wrote: >>> > >>> > The fun thing is that I now get the same problem when integrating the >>> GT Tools update. >>> > >>> > After doing the update for issue 16957, the test run hangs with >>> > >>> > starting testcase: BlockClosureTest>>testBenchFor ... >>> > >>> > >>> >> On 11 Nov 2015, at 22:42, Martin Dias <tinchodias(a)gmail.com> wrote: >>> >> >>> >> Hello, >>> >> >>> >> I'm trying to understand why this method hangs in certain >>> conditions*. What happens is that the #whileTrue: in the following method >>> is never cut. >>> >> >>> >> benchFor: duration >>> >> "Run me for duration and return a BenchmarkResult" >>> >> >>> >> "[ 100 factorial ] benchFor: 2 seconds" >>> >> >>> >> | count run started | >>> >> count := 0. >>> >> run := true. >>> >> [ duration wait. run := false ] forkAt: Processor timingPriority >>> - 1. >>> >> started := Time millisecondClockValue. >>> >> [ run ] whileTrue: [ self value. count := count + 1 ]. >>> >> ^ BenchmarkResult new >>> >> iterations: count; >>> >> elapsedTime: (Time millisecondsSince: started) >>> milliSeconds; >>> >> yourself >>> >> >>> >> Strangely, I verified with several #logCr that the forked block >>> starts, but the #wait never ends. >>> >> ---> Maybe you see something I don't in the code. Any clue? >>> >> >>> >> I will continue trying to isolate the problem, but maybe you have >>> some idea. >>> >> >>> >> * the conditions to reproduce are: >>> >> 1) curl get.pharo.org/50+vm | bash >>> >> 2) ./pharo Pharo.image get Epicea 6.5 >>> >> 3) ./pharo Pharo.image test '^(?!Metacello)[A-L].*' >>> >> >>> >> Notes: >>> >> - It doesn't hang when running from UI >>> >> - it doesn't hang when running less tests, like: >>> >> pharo Pharo.image test '^(?!Metacello)[E-L].*' >>> >> - it *does* hang even when removing all Epicea tests >>> >> - Epicea doesn't extend or override "kernel" behavior... >>> >> >>> >> Regards, >>> >> Martin >>> > >>> >>> >>> >> >> > >

Nov. 16, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Max Leske

Interestingly, if I change the delay in that method from 400 to 0 I get the same effect (namely, it doesnât hang). So maybe itâs a problem with delay scheduling from low priority processes? > On 16 Nov 2015, at 14:12, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi, > > Any news on this? > > Might be totally unrelated but I went back and searched for the the first version where [1] blocks. > In my case the first version where it blocks is Pharo-40520. In Pharo-40519 it works ok. > 40520 integrated https://pharo.fogbugz.com/f/cases/14993 <https://pharo.fogbugz.com/f/cases/14993> which does a lot of changes, but one changed that this issue did is introduced an async tasks for updating the scrolling in inspector. > > Next if in the latest version I change in GLMScrollPaneBandBrick>>onChildrenLayouted the priority of asyncTask from 'Processor lowestPriority' to 'Processor userBackgroundPriority + 1' > then #testBenchFor does not block. If I change the priority to the initial one it blocks again. At least on my machine this is consistent. > > Not sure if this fixes the bug on the CI but I updated issue 16957 <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> to include this change. > Can you try to integrate the issue and see if it still blocks. > > Cheers, > Andrei > > > > [1] ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests')" > > > > On Thu, Nov 12, 2015 at 9:21 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > I found a single test method I could use to narrow down the problem (be aware that this might not work for you. I have other (fresh) images where the issue never occurs). The method I used is EpRedoAndUndoVisitorTest>>testClassModification. > > I was able to mitigate the hang by making a small modification to the method EpUndoVisitor>>visitClassModification: Simply add > > 2 seconds asDelay wait. Smalltalk garbageCollect. > > or > > Smalltalk garbageCollect. 2 seconds asDelay wait. > > after the compilation phase. My guess is, that announcements build up (a simple printout showed 1 announcement instance before and 74 instances after the #evaluate:) and do stuff in the system that influence the process scheduling. For instance, a lot of those announcements will probably be weak and need to be finalized at some point. > > I donât have enough experience with the ClassBuilder to go on hunting but this should hopefully give you a good head start. > > > > For testing I used the following command line: > > ./pharo found_case.image eval "CommandLineTestRunner runPackages: #('Epicea' 'Kernel-Testsâ)" > > Install Epicea with > > ./pharo Pharo.image get Epicea 6.5 > > > To isolate the test case I simply moved test classes from Epicea to a differently named package and once I had found the class I started excluding methods (e.g. with âself fail.â at the beginning). > > > HTH, > Max > > > > >> On 12 Nov 2015, at 18:57, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >> >> Yes! with Max Leske we have been isolating the problem and we realized that a fresh image was enough: >> >> 1) >> curl get.pharo.org/50+vm <http://get.pharo.org/50+vm> | bash >> >> 2) >> ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests')" >> >> Martin >> >> On Thu, Nov 12, 2015 at 6:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> Then it must be that waiting on the delay never ends, which is probably a problem all by itself. >> >> > On 12 Nov 2015, at 18:39, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> > >> > The fun thing is that I now get the same problem when integrating the GT Tools update. >> > >> > After doing the update for issue 16957, the test run hangs with >> > >> > starting testcase: BlockClosureTest>>testBenchFor ... >> > >> > >> >> On 11 Nov 2015, at 22:42, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >> >> >> >> Hello, >> >> >> >> I'm trying to understand why this method hangs in certain conditions*. What happens is that the #whileTrue: in the following method is never cut. >> >> >> >> benchFor: duration >> >> "Run me for duration and return a BenchmarkResult" >> >> >> >> "[ 100 factorial ] benchFor: 2 seconds" >> >> >> >> | count run started | >> >> count := 0. >> >> run := true. >> >> [ duration wait. run := false ] forkAt: Processor timingPriority - 1. >> >> started := Time millisecondClockValue. >> >> [ run ] whileTrue: [ self value. count := count + 1 ]. >> >> ^ BenchmarkResult new >> >> iterations: count; >> >> elapsedTime: (Time millisecondsSince: started) milliSeconds; >> >> yourself >> >> >> >> Strangely, I verified with several #logCr that the forked block starts, but the #wait never ends. >> >> ---> Maybe you see something I don't in the code. Any clue? >> >> >> >> I will continue trying to isolate the problem, but maybe you have some idea. >> >> >> >> * the conditions to reproduce are: >> >> 1) curl get.pharo.org/50+vm <http://get.pharo.org/50+vm> | bash >> >> 2) ./pharo Pharo.image get Epicea 6.5 >> >> 3) ./pharo Pharo.image test '^(?!Metacello)[A-L].*' >> >> >> >> Notes: >> >> - It doesn't hang when running from UI >> >> - it doesn't hang when running less tests, like: >> >> pharo Pharo.image test '^(?!Metacello)[E-L].*' >> >> - it *does* hang even when removing all Epicea tests >> >> - Epicea doesn't extend or override "kernel" behavior... >> >> >> >> Regards, >> >> Martin >> > >> >> >> > >

Nov. 16, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Max Leske

Very nice! I can confirm that this change does indeed help. Now the question becomes: why? > On 16 Nov 2015, at 14:12, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Hi, > > Any news on this? > > Might be totally unrelated but I went back and searched for the the first version where [1] blocks. > In my case the first version where it blocks is Pharo-40520. In Pharo-40519 it works ok. > 40520 integrated https://pharo.fogbugz.com/f/cases/14993 <https://pharo.fogbugz.com/f/cases/14993> which does a lot of changes, but one changed that this issue did is introduced an async tasks for updating the scrolling in inspector. > > Next if in the latest version I change in GLMScrollPaneBandBrick>>onChildrenLayouted the priority of asyncTask from 'Processor lowestPriority' to 'Processor userBackgroundPriority + 1' > then #testBenchFor does not block. If I change the priority to the initial one it blocks again. At least on my machine this is consistent. > > Not sure if this fixes the bug on the CI but I updated issue 16957 <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> to include this change. > Can you try to integrate the issue and see if it still blocks. > > Cheers, > Andrei > > > > [1] ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests')" > > > > On Thu, Nov 12, 2015 at 9:21 PM, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: > I found a single test method I could use to narrow down the problem (be aware that this might not work for you. I have other (fresh) images where the issue never occurs). The method I used is EpRedoAndUndoVisitorTest>>testClassModification. > > I was able to mitigate the hang by making a small modification to the method EpUndoVisitor>>visitClassModification: Simply add > > 2 seconds asDelay wait. Smalltalk garbageCollect. > > or > > Smalltalk garbageCollect. 2 seconds asDelay wait. > > after the compilation phase. My guess is, that announcements build up (a simple printout showed 1 announcement instance before and 74 instances after the #evaluate:) and do stuff in the system that influence the process scheduling. For instance, a lot of those announcements will probably be weak and need to be finalized at some point. > > I donât have enough experience with the ClassBuilder to go on hunting but this should hopefully give you a good head start. > > > > For testing I used the following command line: > > ./pharo found_case.image eval "CommandLineTestRunner runPackages: #('Epicea' 'Kernel-Testsâ)" > > Install Epicea with > > ./pharo Pharo.image get Epicea 6.5 > > > To isolate the test case I simply moved test classes from Epicea to a differently named package and once I had found the class I started excluding methods (e.g. with âself fail.â at the beginning). > > > HTH, > Max > > > > >> On 12 Nov 2015, at 18:57, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >> >> Yes! with Max Leske we have been isolating the problem and we realized that a fresh image was enough: >> >> 1) >> curl get.pharo.org/50+vm <http://get.pharo.org/50+vm> | bash >> >> 2) >> ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests')" >> >> Martin >> >> On Thu, Nov 12, 2015 at 6:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> Then it must be that waiting on the delay never ends, which is probably a problem all by itself. >> >> > On 12 Nov 2015, at 18:39, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: >> > >> > The fun thing is that I now get the same problem when integrating the GT Tools update. >> > >> > After doing the update for issue 16957, the test run hangs with >> > >> > starting testcase: BlockClosureTest>>testBenchFor ... >> > >> > >> >> On 11 Nov 2015, at 22:42, Martin Dias <tinchodias(a)gmail.com <mailto:tinchodias@gmail.com>> wrote: >> >> >> >> Hello, >> >> >> >> I'm trying to understand why this method hangs in certain conditions*. What happens is that the #whileTrue: in the following method is never cut. >> >> >> >> benchFor: duration >> >> "Run me for duration and return a BenchmarkResult" >> >> >> >> "[ 100 factorial ] benchFor: 2 seconds" >> >> >> >> | count run started | >> >> count := 0. >> >> run := true. >> >> [ duration wait. run := false ] forkAt: Processor timingPriority - 1. >> >> started := Time millisecondClockValue. >> >> [ run ] whileTrue: [ self value. count := count + 1 ]. >> >> ^ BenchmarkResult new >> >> iterations: count; >> >> elapsedTime: (Time millisecondsSince: started) milliSeconds; >> >> yourself >> >> >> >> Strangely, I verified with several #logCr that the forked block starts, but the #wait never ends. >> >> ---> Maybe you see something I don't in the code. Any clue? >> >> >> >> I will continue trying to isolate the problem, but maybe you have some idea. >> >> >> >> * the conditions to reproduce are: >> >> 1) curl get.pharo.org/50+vm <http://get.pharo.org/50+vm> | bash >> >> 2) ./pharo Pharo.image get Epicea 6.5 >> >> 3) ./pharo Pharo.image test '^(?!Metacello)[A-L].*' >> >> >> >> Notes: >> >> - It doesn't hang when running from UI >> >> - it doesn't hang when running less tests, like: >> >> pharo Pharo.image test '^(?!Metacello)[E-L].*' >> >> - it *does* hang even when removing all Epicea tests >> >> - Epicea doesn't extend or override "kernel" behavior... >> >> >> >> Regards, >> >> Martin >> > >> >> >> > >

Nov. 16, 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

by Andrei Chis

Hi, Any news on this? Might be totally unrelated but I went back and searched for the the first version where [1] blocks. In my case the first version where it blocks is Pharo-40520. In Pharo-40519 it works ok. 40520 integrated https://pharo.fogbugz.com/f/cases/14993 which does a lot of changes, but one changed that this issue did is introduced an async tasks for updating the scrolling in inspector. Next if in the latest version I change in GLMScrollPaneBandBrick>>onChildrenLayouted the priority of asyncTask from 'Processor lowestPriority' to 'Processor userBackgroundPriority + 1' then #testBenchFor does not block. If I change the priority to the initial one it blocks again. At least on my machine this is consistent. Not sure if this fixes the bug on the CI but I updated issue 16957 <https://pharo.fogbugz.com/f/cases/16957/Update-GTools-version-3-1> to include this change. Can you try to integrate the issue and see if it still blocks. Cheers, Andrei [1] ./pharo Pharo.image eval "CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPackages: #('Kernel-Tests')" On Thu, Nov 12, 2015 at 9:21 PM, Max Leske <maxleske(a)gmail.com> wrote: > I found a single test method I could use to narrow down the problem (be > aware that this might not work for you. I have other (fresh) images where > the issue never occurs). The method I used > is EpRedoAndUndoVisitorTest>>testClassModification. > > I was able to mitigate the hang by making a small modification to the > method EpUndoVisitor>>visitClassModification: Simply add > > 2 seconds asDelay wait. Smalltalk garbageCollect. > > or > > Smalltalk garbageCollect. 2 seconds asDelay wait. > > after the compilation phase. My guess is, that announcements build up (a > simple printout showed 1 announcement instance before and 74 instances > after the #evaluate:) and do stuff in the system that influence the process > scheduling. For instance, a lot of those announcements will probably be > weak and need to be finalized at some point. > > I donât have enough experience with the ClassBuilder to go on hunting but > this should hopefully give you a good head start. > > > > For testing I used the following command line: > > ./pharo found_case.image eval "CommandLineTestRunner runPackages: > #('Epicea' 'Kernel-Testsâ)" > > Install Epicea with > > ./pharo Pharo.image get Epicea 6.5 > > > To isolate the test case I simply moved test classes from Epicea to a > differently named package and once I had found the class I started > excluding methods (e.g. with âself fail.â at the beginning). > > > HTH, > Max > > > > > On 12 Nov 2015, at 18:57, Martin Dias <tinchodias(a)gmail.com> wrote: > > Yes! with Max Leske we have been isolating the problem and we realized > that a fresh image was enough: > > 1) > curl get.pharo.org/50+vm | bash > > 2) > ./pharo Pharo.image eval "CommandLineTestRunner runClasses: > {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. > CommandLineTestRunner runPackages: #('Kernel-Tests')" > > Martin > > On Thu, Nov 12, 2015 at 6:42 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> Then it must be that waiting on the delay never ends, which is probably a >> problem all by itself. >> >> > On 12 Nov 2015, at 18:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> > >> > The fun thing is that I now get the same problem when integrating the >> GT Tools update. >> > >> > After doing the update for issue 16957, the test run hangs with >> > >> > starting testcase: BlockClosureTest>>testBenchFor ... >> > >> > >> >> On 11 Nov 2015, at 22:42, Martin Dias <tinchodias(a)gmail.com> wrote: >> >> >> >> Hello, >> >> >> >> I'm trying to understand why this method hangs in certain conditions*. >> What happens is that the #whileTrue: in the following method is never cut. >> >> >> >> benchFor: duration >> >> "Run me for duration and return a BenchmarkResult" >> >> >> >> "[ 100 factorial ] benchFor: 2 seconds" >> >> >> >> | count run started | >> >> count := 0. >> >> run := true. >> >> [ duration wait. run := false ] forkAt: Processor timingPriority >> - 1. >> >> started := Time millisecondClockValue. >> >> [ run ] whileTrue: [ self value. count := count + 1 ]. >> >> ^ BenchmarkResult new >> >> iterations: count; >> >> elapsedTime: (Time millisecondsSince: started) >> milliSeconds; >> >> yourself >> >> >> >> Strangely, I verified with several #logCr that the forked block >> starts, but the #wait never ends. >> >> ---> Maybe you see something I don't in the code. Any clue? >> >> >> >> I will continue trying to isolate the problem, but maybe you have some >> idea. >> >> >> >> * the conditions to reproduce are: >> >> 1) curl get.pharo.org/50+vm | bash >> >> 2) ./pharo Pharo.image get Epicea 6.5 >> >> 3) ./pharo Pharo.image test '^(?!Metacello)[A-L].*' >> >> >> >> Notes: >> >> - It doesn't hang when running from UI >> >> - it doesn't hang when running less tests, like: >> >> pharo Pharo.image test '^(?!Metacello)[E-L].*' >> >> - it *does* hang even when removing all Epicea tests >> >> - Epicea doesn't extend or override "kernel" behavior... >> >> >> >> Regards, >> >> Martin >> > >> >> >> > >

Nov. 16, 2015