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

Re: [Pharo-dev] Using a newer vm with PharoLauncher, platform differences

by Stephan Eggermont

On 12/11/15 23:46, Dimitris Chloupis wrote: > I could be wrong but since pharolauncher on macos is a mac app then you > will need to change the vm inside the pharo.app folder, in > pharo.app/Contents/MacOS PharoLauncher has a setting to use a different vm to start its images than the one it uses itself. I can get that to work on Ubuntu, but not on mac. Changeing the vm in pharo.app in Applications and leaving the vm path empty woudl be a workaround. Stephan

Nov. 13, 2015

Re: [Pharo-dev] Using a newer vm with PharoLauncher, platform differences

by Dimitris Chloupis

I could be wrong but since pharolauncher on macos is a mac app then you will need to change the vm inside the pharo.app folder, in pharo.app/Contents/MacOS On Thu, Nov 12, 2015 at 5:13 PM Stephan Eggermont <stephan(a)stack.nl> wrote: > I wanted to use a newer vm with PharoLauncher, > so I added a vms directory in > /Users/stephan/Library/Application Support/Pharo/ > and used > curl get.pharo.org/vmLatest50 | bash > to install it there. > In PharoLauncher I then set the vm full path to either > /Users/stephan/Library/Application > Support/Pharo/vms/pharo-vm/Pharo.app/Contents/MacOS/pharo > or > /Users/stephan/Library/Application Support/Pharo/vms/pharo-vm/Pharo.app > > Neither works to launch an image (Mac 10.10.5). > The similar procedure on Ubuntu 15.04 works (though the apt dependencies > of SDL2/Cairo/Freetype:i386 are somewhat broken). > > What is the vm path supposed to be? > > Stephan > > >

Nov. 12, 2015

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

by Tudor Girba

+1 Doru > On Nov 12, 2015, at 10:21 PM, stepharo <stepharo(a)free.fr> wrote: > > thanks max this is great to have your support. > > Le 12/11/15 21:21, Max Leske a Ã©crit : >> 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 >>> > >>> >>> >>> >> > -- www.tudorgirba.com "To utilize feedback, you first have to acquire it."

Nov. 12, 2015

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

by stepharo

thanks max this is great to have your support. Le 12/11/15 21:21, Max Leske a Ã©crit : > 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. 12, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50440 Home: https://github.com/pharo-project/pharo-core

Nov. 12, 2015

[pharo-project/pharo-core] 26e6b3: 50440

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 26e6b3ab5ea102c92db043ea8a4f10b6557c30bd https://github.com/pharo-project/pharo-core/commit/26e6b3ab5ea102c92db043ea… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-12 (Thu, 12 Nov 2015) Changed paths: A Kernel.package/Object.class/instance/binding/hasBindingOf_.st M Monticello.package/MCMczReader.class/instance/parsing/contentsForMember_.st R ProfStef-Core.package/LessonView.class/instance/hack/hasBindingOf_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50439.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50440.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50439.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50440.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50440 16960 fix DNU hasBindingOf: https://pharo.fogbugz.com/f/cases/16960 16998 Loading old monticello files throws UTF8InvalidText https://pharo.fogbugz.com/f/cases/16998 http://files.pharo.org/image/50/50440.zip

Nov. 12, 2015

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

by Max Leske

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 <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. 12, 2015

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

by Martin Dias

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. 12, 2015

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

by Sven Van Caekenberghe

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. 12, 2015

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

by Marcus Denker

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 <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. 12, 2015