- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 5d8e29: 50544

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 5d8e29106a266ef2cff7f53ec5f793e172a82b5d https://github.com/pharo-project/pharo-core/commit/5d8e29106a266ef2cff7f53e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-24 (Sun, 24 Jan 2016) Changed paths: M Kernel.package/ProtocolOrganizer.class/instance/initialization/initialize.st A Kernel.package/ProtocolOrganizer.class/instance/initialization/reset.st M Morphic-Base.package/MenuMorph.class/definition.st M Morphic-Base.package/MenuMorph.class/instance/accessing/items.st M Morphic-Base.package/MenuMorph.class/instance/accessing/lastItem.st M Morphic-Base.package/MenuMorph.class/instance/accessing/menuItems.st M Morphic-Base.package/MenuMorph.class/instance/construction/addMenuItem_.st M Morphic-Base.package/MenuMorph.class/instance/construction/addToggle_target_selector_getStateSelector_enablementSelector_argumentList_.st M Morphic-Base.package/MenuMorph.class/instance/copying/veryDeepInner_.st M Morphic-Base.package/MenuMorph.class/instance/initialization/initialize.st M Morphic-Base.package/MenuMorph.class/instance/menu/addCustomMenuItems_hand_.st M Morphic-Base.package/MenuMorph.class/instance/menu/removeStayUpItems.st R Morphic-Base.package/MenuMorph.class/instance/submorphs-add%2Fremove/addMorphBack_.st M Morphic-Base.package/MenuMorph.class/instance/testing/hasItems.st M Morphic-Base.package/MenuMorph.class/instance/testing/hasSubMenu_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50543.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50544.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50543.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50544.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50544 17423 PopupChoiceDialogWindow keyboard navigation https://pharo.fogbugz.com/f/cases/17423 17435 ClassOrganisation>>#changeFromString: MNU for empty change https://pharo.fogbugz.com/f/cases/17435 http://files.pharo.org/image/50/50544.zip

Jan. 24, 2016

Fix To Include

by Ben Coman

Is something stuck with integration by the CI monkey. I thought this automatically picked and integrated any Fix To Include status slices. But these two cases were marked Fix To include a fews days ago, and have not yet been integrated. Case 17296 --> Fix To Include 2016-01-21 22:29 Case 17435 --> Fix To Include 2016-01-22 16:34 But I see several cases integrated since then didn't pass through Fix To Include, so I'm curious what the process is. Is it still a manual pick of items to integrate? In that case why are the above passed over? There is no indication on the tracker. Case 17429 --> Fix To include 2016-01-22 16:52 --> Integrated 2016-01-22 21:05 Build 50539 Case 17446 --> Fix To Include 2016-01-22 21:40 --> Integrated 2016-01-22 23:40 Build 50540 Case 17404 --> Fix Reviewed By Monkey 2016-01-24 03:42 Case 17443 --> Fix Reviewed By Monkey 2016-01-24 04:57 Case 17457 --> Fix Reviewed By Monkey 2016-01-24 05:03 --> Integrated 2016-01-24 17:55 Build 50541 Case 17450 --> Fix Review Needed 2016-01-24 19:37 --> Integrated 2016-01-24 17:37 Build 50542 Case 17301 --> Fix Reviewed by the Monkey 2016-01-24 20:39 Case 17384 --> Fix To Include 2016-01-24 16:50 --> Integrated 2016-01-24 20:39

Jan. 24, 2016

Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Stephan Eggermont

On 24-01-16 15:34, Vincent BLONDEAU wrote: > Yes, and we have to do several passes to construct the model with references > (so we store a mapping table). > Maybe a collection or two are GCed. Probably a bit more. Before loading, there were 172 instances of SmallDictionary. After loading, 558293, of which 30194 contain something. Stephan

Jan. 24, 2016

Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Sven Van Caekenberghe

> On 24 Jan 2016, at 16:09, Stephan Eggermont <stephan(a)stack.nl> wrote: > > On 24-01-16 15:34, Vincent BLONDEAU wrote: >> Yes, and we have to do several passes to construct the model with references >> (so we store a mapping table). >> Maybe a collection or two are GCed. > > At least a lot of Announcements and Announcers > > Stephan Of course it is good to optimise code (generating too much garbage is a delayed slowdown), but if GC is slower in Spur then that sounds like a regression that has to be studied. Sven

Jan. 24, 2016

Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Stephan Eggermont

On 24-01-16 15:34, Vincent BLONDEAU wrote: > Yes, and we have to do several passes to construct the model with references > (so we store a mapping table). > Maybe a collection or two are GCed. At least a lot of Announcements and Announcers Stephan

Jan. 24, 2016

2nd Chapter of Updated Pharo by Example ready for review.

by stepharo

2nd Chapter of Updated Pharo by Example ready for review. https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample… Stef

Jan. 24, 2016

Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by Vincent BLONDEAU

Yes, and we have to do several passes to construct the model with references (so we store a mapping table). Maybe a collection or two are GCed. Vincent -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of stepharo Sent: dimanche 24 janvier 2016 13:40 To: Pharo Development List Subject: Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :() Thanks for this analysis. This is really interesting. I wonder what is the type of the garbage collected object. In MSE we have mainly strings. Stef Le 24/1/16 12:43, Vincent BLONDEAU a Ã©crit : > Hi, > > I made the benchmarks with the files you provided. I have more or less > the same magnitude: > Version 504: 0:00:01:09.021 > Version 1175: 0:00:02:37.507 > > However, by launching it in the time profiler (MooseModel new > importFromMSEStream: (StandardFileStream readOnlyFileNamed: > 'd:/ArgoUML-0-34.mse')), it takes > 504: 1 min 55 > 1175: 4 min 25 > Well there is a delta... > > After investigation, the standard process has almost the same duration > (120 secs for prespur and 140 secs for spur). > But, there is a large difference in GC time: > > 504: not spur > **Memory** > old +144,822,000 bytes > young -8,293,660 bytes > used +136,528,340 bytes > free -104,186,788 bytes > > **GCs** > full 1 totalling 965ms (1.0% uptime), avg 965.0ms > incr 3264 totalling 42,279ms (33.0% uptime), avg 13.0ms > tenures 2,497 (avg 1 GCs/tenure) > root table 0 overflows > > 1175: spur > **Memory** > old +0 bytes > young +340,048 bytes > used +340,048 bytes > free -340,048 bytes > **GCs** > full 7 totalling 145,003ms (66.0% uptime), avg > 20715.0ms > incr 3288 totalling 30,912ms (14.0% uptime), avg 9.0ms > tenures 7,146,505 (avg 0 GCs/tenure) > root table 0 overflows > > Total GC time > 504: 43 secs > 1175: 176 secs > > See the performance reports attached. > > I let VM people take care of the issue ;) > > Cheers, > Vincent > > -----Original Message----- > From: moose-dev-bounces(a)list.inf.unibe.ch > [mailto:moose-dev-bounces@list.inf.unibe.ch] On Behalf Of Tudor Girba > Sent: dimanche 24 janvier 2016 09:08 > To: Moose-related development > Subject: [Moose-dev] Re: mse loading looks slower :( > > Hi, > > I am talking about the difference between Moose 6 images: > - October 7: > https://ci.inria.fr/moose/job/moose-6.0/504/artifact/moose-6.0.zip > > - yesterday: > https://ci.inria.fr/moose/job/moose-6.0/1175/artifact/moose-6.0.zip > > Multiple things did change, but not in Moose. In the end, I would like > to understand where the slowness comes. Maybe it comes from Spur > itself, but maybe it comes from somewhere else. > > Cheers, > Doru > > > >> On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> > wrote: >> Doru...just to be sure it is not a Pharo (image change), when you >> said > before and after Spur, do you mean a Pharo 5.0 exactly (just before > Spur) and a Pharo JUST after it? Otherwise, the slowness may come > from the difference between the 2 Pharos you are running. >> Cheers, >> >> On Sat, Jan 23, 2016 at 5:55 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I am doing some performance testing of Moose with the Spur VM on Mac. >> >> I tried to load an MSE file with ArgoUML 0.34 and on my machine it >> loads > twice as slow with Spur than before: >> - PreSpur: 0:00:01:07.272 >> - Spur: 0:00:02:10.508 >> >> Here is the reference file: >> https://dl.dropboxusercontent.com/u/18323746/Tmp/ArgoUML-0-34.mse.zip >> >> And here is the script: >> [ >> MooseModel new >> importFromMSEStream: (StandardFileStream > readOnlyFileNamed: >> (FileSystem workingDirectory / 'src' / > 'ArgoUML-0-34' / 'ArgoUML-0-34.mse') fullName). >> ] timeToRun >> >> Do you get the same? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Problem solving should be focused on describing the problem in a way >> that makes the solution obvious." >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Jan. 24, 2016

Re: [Pharo-dev] Get an image from monkey job

by Yuriy Tymchuk

We can create artifacts from images and store them for 8-24 hours. This would be enough to download the image and evaluate it. Uko > On 23 Jan 2016, at 13:53, Ben Coman <btc(a)openinworld.com> wrote: > > On Sat, Jan 23, 2016 at 7:12 PM, Vincent BLONDEAU > <vincent.blondeau(a)polytech-lille.net> wrote: >> Hi, >> >> With the current configuration, it is not possible: the workspace is deleted >> after the execution (so the image generated too...). >> Maybe it should be nice to delete the workspace only before the job, in this >> way, one can be able to retrieve the generated image and debug it? > > > But if there are several FixReviewNeeded, wouldn't all except the last > get bumped out? Maybe workspaces could be kept for a short time ~ 6 > to 24 hours? I guess it all depends on CI space available. > cheers -ben > >> Can a Pharo CI admin change this configuration? >> >> Cheers, >> Vincent >> >> -----Original Message----- >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> Yuriy Tymchuk >> Sent: samedi 23 janvier 2016 11:52 >> To: Pharo Development List >> Subject: [Pharo-dev] Get an image from monkey job >> >> Hi, >> >> sometimes some strange tests fail while money is checking the >> slice/configuration. And while the failures are not related to the >> contribution sometimes I want to know what happened and maybe fix it. Is it >> possible to get the resulting image to investigate it? >> >> Cheers. >> Uko >> >> >

Jan. 24, 2016

Re: [Pharo-dev] Spur Garbage collection takes 4 times more when loading MSE (WAS: mse loading looks slower :()

by stepharo

Thanks for this analysis. This is really interesting. I wonder what is the type of the garbage collected object. In MSE we have mainly strings. Stef Le 24/1/16 12:43, Vincent BLONDEAU a Ã©crit : > Hi, > > I made the benchmarks with the files you provided. I have more or less the > same magnitude: > Version 504: 0:00:01:09.021 > Version 1175: 0:00:02:37.507 > > However, by launching it in the time profiler (MooseModel new > importFromMSEStream: (StandardFileStream readOnlyFileNamed: > 'd:/ArgoUML-0-34.mse')), it takes > 504: 1 min 55 > 1175: 4 min 25 > Well there is a delta... > > After investigation, the standard process has almost the same duration (120 > secs for prespur and 140 secs for spur). > But, there is a large difference in GC time: > > 504: not spur > **Memory** > old +144,822,000 bytes > young -8,293,660 bytes > used +136,528,340 bytes > free -104,186,788 bytes > > **GCs** > full 1 totalling 965ms (1.0% uptime), avg 965.0ms > incr 3264 totalling 42,279ms (33.0% uptime), avg 13.0ms > tenures 2,497 (avg 1 GCs/tenure) > root table 0 overflows > > 1175: spur > **Memory** > old +0 bytes > young +340,048 bytes > used +340,048 bytes > free -340,048 bytes > **GCs** > full 7 totalling 145,003ms (66.0% uptime), avg > 20715.0ms > incr 3288 totalling 30,912ms (14.0% uptime), avg 9.0ms > tenures 7,146,505 (avg 0 GCs/tenure) > root table 0 overflows > > Total GC time > 504: 43 secs > 1175: 176 secs > > See the performance reports attached. > > I let VM people take care of the issue ;) > > Cheers, > Vincent > > -----Original Message----- > From: moose-dev-bounces(a)list.inf.unibe.ch > [mailto:moose-dev-bounces@list.inf.unibe.ch] On Behalf Of Tudor Girba > Sent: dimanche 24 janvier 2016 09:08 > To: Moose-related development > Subject: [Moose-dev] Re: mse loading looks slower :( > > Hi, > > I am talking about the difference between Moose 6 images: > - October 7: > https://ci.inria.fr/moose/job/moose-6.0/504/artifact/moose-6.0.zip > > - yesterday: > https://ci.inria.fr/moose/job/moose-6.0/1175/artifact/moose-6.0.zip > > Multiple things did change, but not in Moose. In the end, I would like to > understand where the slowness comes. Maybe it comes from Spur itself, but > maybe it comes from somewhere else. > > Cheers, > Doru > > > >> On Jan 24, 2016, at 1:41 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: >> Doru...just to be sure it is not a Pharo (image change), when you said > before and after Spur, do you mean a Pharo 5.0 exactly (just before Spur) > and a Pharo JUST after it? Otherwise, the slowness may come from the > difference between the 2 Pharos you are running. >> Cheers, >> >> On Sat, Jan 23, 2016 at 5:55 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Hi, >> >> I am doing some performance testing of Moose with the Spur VM on Mac. >> >> I tried to load an MSE file with ArgoUML 0.34 and on my machine it loads > twice as slow with Spur than before: >> - PreSpur: 0:00:01:07.272 >> - Spur: 0:00:02:10.508 >> >> Here is the reference file: >> https://dl.dropboxusercontent.com/u/18323746/Tmp/ArgoUML-0-34.mse.zip >> >> And here is the script: >> [ >> MooseModel new >> importFromMSEStream: (StandardFileStream > readOnlyFileNamed: >> (FileSystem workingDirectory / 'src' / > 'ArgoUML-0-34' / 'ArgoUML-0-34.mse') fullName). >> ] timeToRun >> >> Do you get the same? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Problem solving should be focused on describing the problem in a way >> that makes the solution obvious." >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > -- > www.tudorgirba.com > www.feenk.com > > "What is more important: To be happy, or to make happy?" > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Jan. 24, 2016

[pharo-project/pharo-core] 519ddd: 50543

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 519dddf72b0bdb723ff239b5be7485495ea54e81 https://github.com/pharo-project/pharo-core/commit/519dddf72b0bdb723ff239b5… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-24 (Sun, 24 Jan 2016) Changed paths: M AST-Core.package/RBNullFormatter.class/definition.st A AST-Core.package/RBNullFormatter.class/instance/initialization/initialize.st M AST-Core.package/RBNullFormatter.class/instance/public interface/format_.st A AST-Core.package/RBNullFormatter.class/instance/visiting/visitMethodNode_.st A AST-Tests-Core.package/RBNullFormatterTest.class/README.md A AST-Tests-Core.package/RBNullFormatterTest.class/definition.st A AST-Tests-Core.package/RBNullFormatterTest.class/instance/tests/testGivenAMethodNodeWhenSourceAvailableThenSourceReturnedAsResultOfFormatting.st A AST-Tests-Core.package/RBNullFormatterTest.class/instance/tests/testGivenAMethodNodeWhenSourceNotAvailableThenSelectorWithWarningMessageReturnedAsResultOfFormatting.st M Athens-Morphic.package/extension/Morph/instance/drawOnAthensCanvas_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50542.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50543.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50542.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50543.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50543 17301 Morph>>#drawOnAthensCanvas: should only fill innerBounds https://pharo.fogbugz.com/f/cases/17301 17384 RBNulllFormater>>#format: should not return nil https://pharo.fogbugz.com/f/cases/17384 http://files.pharo.org/image/50/50543.zip

Jan. 24, 2016