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

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

Re: [Pharo-dev] Pharo VM Crash

by Henrik Johansen

> On 16 Nov 2015, at 12:56 , Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 16 Nov 2015, at 08:08, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >> >> >>> On 16 Nov 2015, at 11:49 , Boris Spasojevic <spasojev(a)inf.unibe.ch <mailto:spasojev@inf.unibe.ch>> wrote: >>> >>> Hey all, >>> >>> How and where can I report the pharo VM crashing? if I have a class Tmp and it has a method >>> >>> Tmp>>tmp >>> [ ^ true ] >>> >>> and I try to execute Tmp new tmp. The VM segfaults. >>> -- >>> Cheers, >>> BoriS >>> >>> >> >> That's a compiler (and probably a code) bug. >> It correctly eliminates the unused block, but it *should* emit a return self instruction (as it would for a method with an empty body), but it doesn't, which is why the VM crashes. >> > > Yes, thatâs it. Should not be to hard to fix.. can you add an issue to the issue tracker? > > Marcus Added: 17022. Wrote down some initial thoughts that may be of help. Cheers, Henry

Nov. 16, 2015

Re: [Pharo-dev] Pharo VM Crash

by Marcus Denker

> On 16 Nov 2015, at 09:32, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Mon, Nov 16, 2015 at 8:56 AM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > >> On 16 Nov 2015, at 08:08, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: >> >> >>> On 16 Nov 2015, at 11:49 , Boris Spasojevic <spasojev(a)inf.unibe.ch <mailto:spasojev@inf.unibe.ch>> wrote: >>> >>> Hey all, >>> >>> How and where can I report the pharo VM crashing? if I have a class Tmp and it has a method >>> >>> Tmp>>tmp >>> [ ^ true ] >>> >>> and I try to execute Tmp new tmp. The VM segfaults. >>> -- >>> Cheers, >>> BoriS >>> >>> >> >> That's a compiler (and probably a code) bug. >> It correctly eliminates the unused block, but it *should* emit a return self instruction (as it would for a method with an empty body), but it doesn't, which is why the VM crashes. >> > > Yes, thatâs it. Should not be to hard to fix.. can you add an issue to the issue tracker? > > Hi guys, > > We were having a some crashes the other day with block closures compilation in 4.0. I didn't send a mail to the mailing list because I was not able to find a small reproducible test case. Maybe it is the same case as this one since my final thought was that it was a compiler problem and not VM. > Marcus, do you think a workaround could also be applied to 4.0? If true, I can check if that solves my crashes or otherwise keep trying to see if I find a smaller case. > Yes, this will be back ported. Marcus

Nov. 16, 2015

Re: [Pharo-dev] Deployment process for Pharo :)

by Mariano Martinez Peck

I saw his presentation and I very much liked him showing that. It shows at least the first steps someone could follow in order to provide a "self contained" app that could be download and run with double click in Unix/Windows/Mac. As always, it may not be 100% complete, but really a good step forward that worth sharing with the community. Best, On Mon, Nov 16, 2015 at 9:20 AM, Damien Cassou <damien.cassou(a)inria.fr> wrote: > stepharo <stepharo(a)free.fr> writes: > > > I'm quite sure that you will love what maximilliano is doing :) > > I talked to him so that he can contribute to what I already did for the > Launcher. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." --Winston Churchill > > -- Mariano http://marianopeck.wordpress.com

Nov. 16, 2015

Re: [Pharo-dev] Pharo VM Crash

by Mariano Martinez Peck

On Mon, Nov 16, 2015 at 8:56 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 16 Nov 2015, at 08:08, Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > On 16 Nov 2015, at 11:49 , Boris Spasojevic <spasojev(a)inf.unibe.ch> wrote: > > Hey all, > > How and where can I report the pharo VM crashing? if I have a class Tmp > and it has a method > > Tmp>>tmp > [ ^ true ] > > and I try to execute Tmp new tmp. The VM segfaults. > > -- > Cheers, > BoriS > > > > That's a compiler (and probably a code) bug. > It correctly eliminates the unused block, but it *should* emit a return > self instruction (as it would for a method with an empty body), but it > doesn't, which is why the VM crashes. > > > Yes, thatâs it. Should not be to hard to fix.. can you add an issue to the > issue tracker? > Hi guys, We were having a some crashes the other day with block closures compilation in 4.0. I didn't send a mail to the mailing list because I was not able to find a small reproducible test case. Maybe it is the same case as this one since my final thought was that it was a compiler problem and not VM. Marcus, do you think a workaround could also be applied to 4.0? If true, I can check if that solves my crashes or otherwise keep trying to see if I find a smaller case. Thanks! -- Mariano http://marianopeck.wordpress.com

Nov. 16, 2015

Re: [Pharo-dev] Deployment process for Pharo :)

by Damien Cassou

stepharo <stepharo(a)free.fr> writes: > I'm quite sure that you will love what maximilliano is doing :) I talked to him so that he can contribute to what I already did for the Launcher. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Nov. 16, 2015

Re: [Pharo-dev] Pharo VM Crash

by Marcus Denker

> On 16 Nov 2015, at 08:08, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 16 Nov 2015, at 11:49 , Boris Spasojevic <spasojev(a)inf.unibe.ch <mailto:spasojev@inf.unibe.ch>> wrote: >> >> Hey all, >> >> How and where can I report the pharo VM crashing? if I have a class Tmp and it has a method >> >> Tmp>>tmp >> [ ^ true ] >> >> and I try to execute Tmp new tmp. The VM segfaults. >> -- >> Cheers, >> BoriS >> >> > > That's a compiler (and probably a code) bug. > It correctly eliminates the unused block, but it *should* emit a return self instruction (as it would for a method with an empty body), but it doesn't, which is why the VM crashes. > Yes, thatâs it. Should not be to hard to fix.. can you add an issue to the issue tracker? Marcus

Nov. 16, 2015

Re: [Pharo-dev] [Reflectivity] Method level breakpoints are back

by Marcus Denker

> On 13 Nov 2015, at 09:27, marcus.denker(a)inria.fr wrote: > > Hi, > > > 50 441 now has simple method level breakpoints that are implemented using > Reflectivity MetaLinks. > > Like the old breakpoints on Pharo3 and earlier, there is a menu entry to add > (or remove) a break. The method icon is that of a #halt for now for active breakpoints. I improved the Nautilus integration: the icon is now a button. If clicked, the breakpoint is removed. Marcus

Nov. 16, 2015