- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Troubles with #flushCache and #run:with:in:

by Lukas Renggli

Created http://code.google.com/p/pharo/issues/detail?id=4512. On 10 July 2011 15:17, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > no we care but have no idea/too busy > Can you add a bug entry so that we do not forget it. > Tx > > > On Jul 10, 2011, at 1:30 PM, Lukas Renggli wrote: > >> Ping! >> >> Does nobody care about method coverage? If so, we should remove it >> from the image. >> >> Is it just broken for me? >> >> Lukas >> >> >> On 1 July 2011 09:32, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Hi Eliot, >>> >>> I am using one of the latest VMs from your site (VM.r2434) and I >>> continue to have subtle problems with objects as methods (#flushCache, >>> #run:with:in:). >>> >>> The issue is that the test coverage in Pharo is kind of broken on Cog >>> for a long time already. It reports methods as not covered that are >>> clearly covered, and tests seem to randomly fail. >>> >>> I suspected that there is something wrong with the coverage code >>> itself. So I started to experiment with TestCoverage>>flushCache and >>> noticed that the current implementation >>> >>> Â Â TestCoverage>>flushCache >>> Â Â Â Â self reference methodSymbol flushCache >>> >>> performs not that well: The set of not covered methods is wrong and >>> many tests suddenly fail. If I replace it with >>> >>> Â Â TestCoverage>>flushCache >>> Â Â Â Â self reference actualClass flushCache >>> >>> I actually get accurate coverage information, but there are still a >>> few tests constantly failing. I tried to use all possible combinations >>> of #flushCache (also calling it on the compiled method), but only >>> flushing the cache on the class seems to work properly. So far so >>> good, but I really wonder what the correct way is to flush the cache? >>> :-) >>> >>> For my experiments I was using the package 'AST-Tests-Semantics'. This >>> is a small package with lots of test methods that cover each method >>> but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" >>> problem is that when running these tests in coverage mode, the same 4 >>> tests always fail: >>> >>> Â Â RBSemanticTest>>testBlockScope >>> Â Â RBSemanticTest>>testCascadeReceiver >>> Â Â RBSemanticTest>>testClassVariableBinding >>> Â Â RBSemanticTest>>testGlobalVariableBinding >>> >>> Not sure of how to debug that? Do you have an idea why these otherwise >>> passing tests suddenly fail? If you want to try to reproduce you can >>> use any Pharo image with the tests loaded, or use those that I used: >>> >>> Â Â http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… >>> Â Â http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… >>> >>> Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'. >>> >>> Any help or clarification would be appreciated :-) >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > -- Lukas Renggli www.lukas-renggli.ch

July 10, 2011

Re: [Pharo-project] Troubles with #flushCache and #run:with:in:

by StÃ©phane Ducasse

no we care but have no idea/too busy Can you add a bug entry so that we do not forget it. Tx On Jul 10, 2011, at 1:30 PM, Lukas Renggli wrote: > Ping! > > Does nobody care about method coverage? If so, we should remove it > from the image. > > Is it just broken for me? > > Lukas > > > On 1 July 2011 09:32, Lukas Renggli <renggli(a)gmail.com> wrote: >> Hi Eliot, >> >> I am using one of the latest VMs from your site (VM.r2434) and I >> continue to have subtle problems with objects as methods (#flushCache, >> #run:with:in:). >> >> The issue is that the test coverage in Pharo is kind of broken on Cog >> for a long time already. It reports methods as not covered that are >> clearly covered, and tests seem to randomly fail. >> >> I suspected that there is something wrong with the coverage code >> itself. So I started to experiment with TestCoverage>>flushCache and >> noticed that the current implementation >> >> TestCoverage>>flushCache >> self reference methodSymbol flushCache >> >> performs not that well: The set of not covered methods is wrong and >> many tests suddenly fail. If I replace it with >> >> TestCoverage>>flushCache >> self reference actualClass flushCache >> >> I actually get accurate coverage information, but there are still a >> few tests constantly failing. I tried to use all possible combinations >> of #flushCache (also calling it on the compiled method), but only >> flushing the cache on the class seems to work properly. So far so >> good, but I really wonder what the correct way is to flush the cache? >> :-) >> >> For my experiments I was using the package 'AST-Tests-Semantics'. This >> is a small package with lots of test methods that cover each method >> but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" >> problem is that when running these tests in coverage mode, the same 4 >> tests always fail: >> >> RBSemanticTest>>testBlockScope >> RBSemanticTest>>testCascadeReceiver >> RBSemanticTest>>testClassVariableBinding >> RBSemanticTest>>testGlobalVariableBinding >> >> Not sure of how to debug that? Do you have an idea why these otherwise >> passing tests suddenly fail? If you want to try to reproduce you can >> use any Pharo image with the tests loaded, or use those that I used: >> >> http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… >> http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… >> >> Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'. >> >> Any help or clarification would be appreciated :-) >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >

July 10, 2011

Re: [Pharo-project] loading OSProcess in Pharo1.3

by StÃ©phane Ducasse

strnage I thought the new version of OS Process fixed that. On Jul 10, 2011, at 3:03 PM, Johan Brichau wrote: > Hi guys, > > I'm (finally) trying out the new Pharo1.3 > Yesterday I had a couple of issues with build 13284 but 13285 seems to fix these. > > Great! > > But I'm now trying to load OSProcess in Pharo 1.3 and OSProcess tries to add its image startup script to the list right after ImageSegment's image startup script. > However, it appears that #ImageSegment is no longer in the startup list, which yields an error. > > I don't know if this is expected, so I thought I should email it here. > > For now, I changed OSProcess so that it adds its startup script right after SmalltalkImage instead. > I'm not sure if that is OK though... it's just a quick fix I made right now. I'm not sure what the prerequisites of OSProcess are in that respect. > > Any thoughts? > > Johan

July 10, 2011

[Pharo-project] loading OSProcess in Pharo1.3

by Johan Brichau

Hi guys, I'm (finally) trying out the new Pharo1.3 Yesterday I had a couple of issues with build 13284 but 13285 seems to fix these. Great! But I'm now trying to load OSProcess in Pharo 1.3 and OSProcess tries to add its image startup script to the list right after ImageSegment's image startup script. However, it appears that #ImageSegment is no longer in the startup list, which yields an error. I don't know if this is expected, so I thought I should email it here. For now, I changed OSProcess so that it adds its startup script right after SmalltalkImage instead. I'm not sure if that is OK though... it's just a quick fix I made right now. I'm not sure what the prerequisites of OSProcess are in that respect. Any thoughts? Johan

July 10, 2011

Re: [Pharo-project] Troubles with #flushCache and #run:with:in:

by Lukas Renggli

Ping! Does nobody care about method coverage? If so, we should remove it from the image. Is it just broken for me? Lukas On 1 July 2011 09:32, Lukas Renggli <renggli(a)gmail.com> wrote: > Hi Eliot, > > I am using one of the latest VMs from your site (VM.r2434) and I > continue to have subtle problems with objects as methods (#flushCache, > #run:with:in:). > > The issue is that the test coverage in Pharo is kind of broken on Cog > for a long time already. It reports methods as not covered that are > clearly covered, and tests seem to randomly fail. > > I suspected that there is something wrong with the coverage code > itself. So I started to experiment with TestCoverage>>flushCache and > noticed that the current implementation > > Â Â TestCoverage>>flushCache > Â Â Â Â self reference methodSymbol flushCache > > performs not that well: The set of not covered methods is wrong and > many tests suddenly fail. If I replace it with > > Â Â TestCoverage>>flushCache > Â Â Â Â self reference actualClass flushCache > > I actually get accurate coverage information, but there are still a > few tests constantly failing. I tried to use all possible combinations > of #flushCache (also calling it on the compiled method), but only > flushing the cache on the class seems to work properly. So far so > good, but I really wonder what the correct way is to flush the cache? > :-) > > For my experiments I was using the package 'AST-Tests-Semantics'. This > is a small package with lots of test methods that cover each method > but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real" > problem is that when running these tests in coverage mode, the same 4 > tests always fail: > > Â Â RBSemanticTest>>testBlockScope > Â Â RBSemanticTest>>testCascadeReceiver > Â Â RBSemanticTest>>testClassVariableBinding > Â Â RBSemanticTest>>testGlobalVariableBinding > > Not sure of how to debug that? Do you have an idea why these otherwise > passing tests suddenly fail? If you want to try to reproduce you can > use any Pharo image with the tests loaded, or use those that I used: > > Â Â http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… > Â Â http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifac… > > Open the Test Runner, select 'AST-Tests-Semantics' and 'Run Coverage'. > > Any help or clarification would be appreciated :-) > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

July 10, 2011

[Pharo-project] [update 1.3] #13285

by StÃ©phane Ducasse

13285 ----- ThreadSafeTranscript install

July 9, 2011

Re: [Pharo-project] would be good to have a presence there

by csrabak＠bol.com.br

It looks bizarre that Microsoft is shown as gold sponsor! For an Open World Forum! Em 07/07/2011 13:27, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > escreveu: http://www.openworldforum.org/rfp/code-osdc.html

July 9, 2011

Re: [Pharo-project] Installing Cog - was Pharo 1.2.1 crashing

by Schwab,Wilhelm K

Thanks!! ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Saturday, July 09, 2011 10:43 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Installing Cog - was Pharo 1.2.1 crashing On 9 July 2011 17:17, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Is there anything I should know about using the Stack or Cog vms from Hudson? It looks like the zips contain a vm, some external plugins and drivers. Can they simply be dumped in a directory with the image/changes and launched using a shell script? Yes. It is just an ordinary executable file, you can place it where you see fit. > > Below, are you recommending the Stack vm to remove Cog features that might be causing problems? > Stack VM serves for two purposes: - we should keep maintaining it, since not all OSes and environments allow running jitter and we don't have jitter for everything. - and of course, if you have problems with Cog (like experiencing crashes etc..) Stack VM can serve as a fallback, more safer solution. also it could serve to detect and diagnose problems (if VM misbehaves with JIT, but runs well without it, you know who to blame ;) -- Best regards, Igor Stasenko AKA sig.

July 9, 2011

Re: [Pharo-project] Installing Cog - was Pharo 1.2.1 crashing

by Igor Stasenko

On 9 July 2011 17:17, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Sig, > > Is there anything I should know about using the Stack or Cog vms from Hudson? Â It looks like the zips contain a vm, some external plugins and drivers. Â Can they simply be dumped in a directory with the image/changes and launched using a shell script? Yes. It is just an ordinary executable file, you can place it where you see fit. > > Below, are you recommending the Stack vm to remove Cog features that might be causing problems? > Stack VM serves for two purposes: - we should keep maintaining it, since not all OSes and environments allow running jitter and we don't have jitter for everything. - and of course, if you have problems with Cog (like experiencing crashes etc..) Stack VM can serve as a fallback, more safer solution. also it could serve to detect and diagnose problems (if VM misbehaves with JIT, but runs well without it, you know who to blame ;) -- Best regards, Igor Stasenko AKA sig.

July 9, 2011

[Pharo-project] Installing Cog - was Pharo 1.2.1 crashing

by Schwab,Wilhelm K

Sig, Is there anything I should know about using the Stack or Cog vms from Hudson? It looks like the zips contain a vm, some external plugins and drivers. Can they simply be dumped in a directory with the image/changes and launched using a shell script? Below, are you recommending the Stack vm to remove Cog features that might be causing problems? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Friday, July 08, 2011 7:23 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo 1.2.1 crashing Could you try running your stuff on Stack VM: https://pharo-ic.lille.inria.fr/hudson/view/Cog/job/Stack%20VM%20Unix/lastS… from log i see that it crashing somewhere in your code.. So i don't have any idea what could be wrong there now. On 8 July 2011 12:51, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Hi list, > My Pharo image is crashing every now and then and I can't seem to work out > why, here's my specs: > 'Pharo1.2.1 > Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.75] > unix i686 linux-gnu' > I also attach the console dump. > Could it be a VM bug or something? > Cheers, > -- > Bernat Romagosa. > -- Best regards, Igor Stasenko AKA sig.

July 9, 2011