March 2017 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] 4389a1: 60427

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 4389a1ae3caf1381f4d33eb97d9849a5a8ead0a0 https://github.com/pharo-project/pharo-core/commit/4389a1ae3caf1381f4d33eb9… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-03-03 (Fri, 03 Mar 2017) Changed paths: M Monticello.package/MCClassDefinition.class/instance/installing/createClass.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/calculateStartIndexWhenShowing_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/initialization/initialize.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/private/resizeAllSubviews.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/private/rowIndexToVerticalScrollBarValue_.st A Reflectivity-Tools-Tests.package/BreakpointTest.class/README.md A Reflectivity-Tools-Tests.package/BreakpointTest.class/definition.st A Reflectivity-Tools-Tests.package/BreakpointTest.class/instance/initialization/setUp.st A Reflectivity-Tools-Tests.package/BreakpointTest.class/instance/initialization/tearDown.st A Reflectivity-Tools-Tests.package/BreakpointTest.class/instance/tests/testRemoveClassWithBreakpoint.st A Reflectivity-Tools-Tests.package/BreakpointTest.class/instance/tests/testRemoveMethodWithBreakpoint.st A Reflectivity-Tools-Tests.package/BreakpointTest.class/instance/utils/newDummyClass.st A Reflectivity-Tools-Tests.package/extension/Breakpoint/class/all.st R Reflectivity-Tools.package/Breakpoint.class/class/class initialization/initialize.st A Reflectivity-Tools.package/Breakpoint.class/class/class initialization/registerInsterestToSystemAnnouncement.st A Reflectivity-Tools.package/Breakpoint.class/class/initialization/initialize.st A Reflectivity-Tools.package/Breakpoint.class/class/removing/removeBreakpointsFromMethod_.st A Reflectivity-Tools.package/Breakpoint.class/class/system announcements/handleClassRemoved_.st A Reflectivity-Tools.package/Breakpoint.class/class/system announcements/handleMethodRemoved_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60426.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60427.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60426.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60427.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60427 18207 Breakpoints still held after a method/class with breakpoints is removed https://pharo.fogbugz.com/f/cases/18207 19669 FastTable jumps to the selected element when its resized https://pharo.fogbugz.com/f/cases/19669 19775 Bootstrapped image does not contain class comment of the Context class https://pharo.fogbugz.com/f/cases/19775 http://files.pharo.org/image/60/60427.zip

March 3, 2017

Re: [Pharo-dev] Growing large images: the case of Moose models

by Eliot Miranda

Hi Phil, On Fri, Mar 3, 2017 at 5:04 AM, philippe.back(a)highoctane.be < philippe.back(a)gmail.com> wrote: > > > Le 3 mars 2017 13:56, "ClÃ©ment Bera" <bera.clement(a)gmail.com> a Ã©crit : > > > > On Fri, Mar 3, 2017 at 12:12 PM, Cyril Ferlicot D. < > cyril.ferlicot(a)gmail.com> wrote: > >> On 03/03/2017 11:56, ClÃ©ment Bera wrote: >> > Hello everyone, >> > >> > This morning I investigated with Vincent Blondeau a problem reported by >> > the Moose community a while ago: loading Moose model is slower in Spur >> > (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this >> > problem was present for anyone growing images to a significant size. >> > >> > To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb >> > image, growing the image to 450Mb. Loading such a model takes 2 minutes >> > in Spur and 1m30s in pre-Spur VMs. >> > >> > Using the stable Pharo VM, the analysis results were the following: >> > - total time spent to load the Model: 2 minutes >> > - time spent in full GC: 1 minute (4 fullGCs) >> > - time spent in scavenges[1]: 15 seconds >> > On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% >> > in scavenges, 37.5% executing code. >> > >> > We then used the latest VM that features the new compactor (VM from >> > beginning of March 2017 and over). The full GC execution time went down >> > from 1 minute to 2 seconds. >> > >> > In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time >> > spent in scavenges decreased from 15 seconds to 5 seconds. >> > >> > Overall, loading the model is now taking ~50 seconds instead of 2 >> minutes. >> > >> > To increase Eden size, one needs to run a script similar to: >> > >> > | currentEdenSize desiredEdenSize | >> > currentEdenSize := Smalltalk vm parameterAt: 44. >> > desiredEdenSize := currentEdenSize * 4. >> > Smalltalk vm parameterAt: 45 put: desiredEdenSize. >> > >> > _*And then restart the image.*_ >> > >> > I hope this report can be useful for some of you. I will try to make a >> > blog post out of it, detailing other GC settings one can change from the >> > image to improve performance. >> > _* >> > *_ >> > Best, >> > >> > Clement >> > >> > [1] A scavenge is basically the garbage collection of only young objects >> > [2] Eden is basically the space where objects are initially allocated. >> > [3] All numbers in the report are order of magnitudes and not precise >> > numbers >> > >> > >> > >> >> Hi, >> >> This is great! We will probably try it soon on our models. >> >> Guillaume had a question also, what is the counterparty if we let the >> EdenSize at this size when we are not loading/exporting a MSE? >> > > There are 2 main counterparts: > - You waste a bit of memory. If you increase from 4Mb to 12Mb, you waste > 8Mb. > - The user-pauses for scavenges may be more significant. > > There are customers using 64Mb Eden in production. It improves their > performance, they do not care about wasting 60Mb on machine with 16Gb RAM > and their application does heavy computation and does not need to be that > responsive. > > However for UI applications (typically the IDE), the scavenge pauses may > become significant enough to be noticed by the programmer. Maybe not at > 12Mb, but certainly at 64Mb. > > For your case: > - Do you care that your application use some more Mb of RAM ? > - Do you care if your application takes a couple extra ms to answer a > request ? (In any case, the full GC takes much more time and also delays > the answer right now) > If you don't care, you can use larger Eden. In any case, an Eden of 12 or > 16 Mb should be safe. > > There are other settings that can be useful in your case. I will try to > write a post about it. > > >> Because in our case we deploy a server that might need to read some MSE. >> We cannot restart it with our current solution. In that case it would be >> good to have more info to select the best EdenSize for the server. >> >> Thank you! >> > > I have images that do not shrink with the new compactor and as there are > no leaks I am wondering if there is a way for me to diagnose why this > happens. I am routinely loading 100MB XML in the image but these are only > transient. > First of all run the attached shell script on your image and report back what the "freespace" field value us. In the old compactor this would usually be tens to hundreds of kilobytes. With the new compactor this should be zero or perhaps a few hundred bytes (and I suspect the few hundred bytes should only show up in Newspeak images). > Shrinking works with a Pharo6 image but not with a 5.0 based. Strange. > Look at the vm parameters for growth and shrinkage. > Anyone willing to pair over the internet to have a look? > Yes, but sometime next week. > It is annoying because I am providing those images to customers and an > ever growing thing is not really great especially with a non standard tech > I am trying to push forward there. > > Phil > > >> -- >> Cyril Ferlicot >> >> http://www.synectique.eu >> >> 2 rue Jacques PrÃ©vert 01, >> 59650 Villeneuve d'ascq France >> >> > > -- _,,,^..^,,,_ best, Eliot

March 3, 2017

[pharo-project/pharo-core] 8c2236: 60426

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 8c22361d29c1d1209e0c75b01446436f92be20b2 https://github.com/pharo-project/pharo-core/commit/8c22361d29c1d1209e0c75b0… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-03-03 (Fri, 03 Mar 2017) Changed paths: M ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/symbolic versions/stable_.st A ConfigurationOfUnifiedFFI.package/ConfigurationOfUnifiedFFI.class/instance/versions/v0%5F26%5F2_.st M Rubric.package/RubAbstractTextArea.class/instance/geometry/extent_.st M Rubric.package/RubFindReplaceService.class/instance/accessing/convertedFindString.st A Rubric.package/RubParagraphDecorator.class/instance/accessing/withoutDecorator.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60425.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60426.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60425.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60426.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M UnifiedFFI.package/FFIExternalStructure.class/class/instance creation/fromHandle_.st Log Message: ----------- 60426 19788 sometimes external structures does not initialise properly OFFSET fields before use https://pharo.fogbugz.com/f/cases/19788 19221 Rub Find And Replace can not search for "?" https://pharo.fogbugz.com/f/cases/19221 19789 CI tests often fail on Windows https://pharo.fogbugz.com/f/cases/19789 http://files.pharo.org/image/60/60426.zip

March 3, 2017

[pharo-project/pharo-core]

by GitHub

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

March 3, 2017

[pharo-project/pharo-core]

by GitHub

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

March 3, 2017

[pharo-project/pharo-core] 14b920: 60425

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 14b9202374e943ce20b91b84342106338dd9bbbf https://github.com/pharo-project/pharo-core/commit/14b9202374e943ce20b91b84… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-03-03 (Fri, 03 Mar 2017) Changed paths: M FileSystem-Core.package/FileSystem.class/README.md M FileSystem-Core.package/FileSystem.class/definition.st R FileSystem-Core.package/FileSystem.class/instance/accessing/changeDirectory_.st M FileSystem-Core.package/FileSystem.class/instance/accessing/workingDirectoryPath.st R FileSystem-Core.package/FileSystem.class/instance/accessing/workingDirectoryPath_.st M FileSystem-Core.package/FileSystem.class/instance/initialize-release/initializeWithStore_.st M FileSystem-Core.package/FileSystem.class/instance/navigating/resolvePath_.st M FileSystem-Core.package/FileSystem.class/instance/navigating/resolveReference_.st M FileSystem-Core.package/FileSystem.class/instance/navigating/resolveString_.st R FileSystem-Tests-Core.package/FileSystemTest.class/instance/tests/testChangeDirectory.st R FileSystem-Tests-Core.package/FileSystemTest.class/instance/tests/testChangeDirectoryString.st R FileSystem-Tests-Core.package/FileSystemTest.class/instance/tests/testSetRelativeWorkingDirectory.st R FileSystem-Tests-Core.package/FileSystemTest.class/instance/tests/testSetWorkingDirectory.st M Metacello-Core.package/MetacelloValidationIssue.class/README.md M Metacello-Core.package/MetacelloValidationIssue.class/instance/accessing/label.st M Metacello-Core.package/MetacelloValidationIssue.class/instance/printing/printOn_.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60424.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60425.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60424.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60425.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60425 19717 FileSystem workingDirectory wrong after image moved to a new folder https://pharo.fogbugz.com/f/cases/19717 18578 MetacelloValidationError(MetacelloValidationIssue) printOn: rasies Warning #name https://pharo.fogbugz.com/f/cases/18578 http://files.pharo.org/image/60/60425.zip

March 3, 2017

Re: [Pharo-dev] Growing large images: the case of Moose models

by ClÃ©ment Bera

On Fri, Mar 3, 2017 at 2:10 PM, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: > On 03/03/2017 14:06, Guillaume Larcheveque wrote: > > > > For your case: > > - Do you care that your application use some more Mb of RAM ? > > > > No, we don't care about that > > I agree > > > > > - Do you care if your application takes a couple extra ms to answer > > a request ? (In any case, the full GC takes much more time and also > > delays the answer right now) > > > > No, because we are only using seaside and browser to display > > visualisations and UI, so we don't care that it answers with extra ms; > > it will not freeze at all the UI > > > In addition to Guillaume's comment: If it is in ms we do not care but > longer full GC can be problematic some time. Do you have an idea of how > long would be the full GC depending on the Eden size? If it add 500ms it > should not be a problem. If it add 2sec it might be. > I'm sorry I was not clear. The scavenges take up to a couple ms and they are done very frequently. They depend on Eden size because Eden is scavenged. The full GC is done rarely. The full GC does not depend on Eden size but on old space size. With the new compactor, it takes around 500ms for a 500Mb heap. I would assume it takes more time on larger heaps. On 2Gb heaps, I guess it could take 2 seconds. For this problem, we need to implement an incremental GC. An incremental GC splits the full GC task in multiple sub tasks, allowing to have multiple small pauses instead of one big pause. The incremental GC implementation is on the TODO list. Your company is in the Pharo consortium, so if you discuss this problem during one of the consortium member meetings, you may ask to invest consortium money in this direction. > > > > Thank you very much for your experiment ClÃ©ment and Vincent; this point > > is really important for us :-) > > > > -- > > *Guillaume Larcheveque* > > > > > -- > Cyril Ferlicot > > http://www.synectique.eu > > 2 rue Jacques PrÃ©vert 01, > 59650 Villeneuve d'ascq France > >

March 3, 2017

Re: [Pharo-dev] [Moose-dev] Re: Growing large images: the case of Moose models

by Tudor Girba

Amazing work and great news! Thanks a lot. Doru -- www.tudorgirba.com "Every thing has its own flow" > On 3 Mar 2017, at 13:31, Blondeau Vincent <vincent.blondeau(a)worldline.com> wrote: > > Thanks Eliot for the implementation of the new compactor! > > Just to add a piece of information: the mse imported have a size of 40Mb. > > Cheers, > Vincent > > > De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de ClÃ©ment Bera > EnvoyÃ© : vendredi 3 mars 2017 11:56 > Ã : Discusses Development of Pharo > Objet : [Pharo-dev] Growing large images: the case of Moose models > > Hello everyone, > > This morning I investigated with Vincent Blondeau a problem reported by the Moose community a while ago: loading Moose model is slower in Spur (Pharo 5+) than in pre-Spur (Pharo 4 and older). In general, this problem was present for anyone growing images to a significant size. > > To investigate the problem, we loaded a 200Mb[3] Moose model on a 250Mb image, growing the image to 450Mb. Loading such a model takes 2 minutes in Spur and 1m30s in pre-Spur VMs. > > Using the stable Pharo VM, the analysis results were the following: > - total time spent to load the Model: 2 minutes > - time spent in full GC: 1 minute (4 fullGCs) > - time spent in scavenges[1]: 15 seconds > On the 2 minutes spent, we have 50% of the time spent in full GCs, 12.5% in scavenges, 37.5% executing code. > > We then used the latest VM that features the new compactor (VM from beginning of March 2017 and over). The full GC execution time went down from 1 minute to 2 seconds. > > In addition, we increased the size of Eden[2] from 4Mb to 12Mb. Time spent in scavenges decreased from 15 seconds to 5 seconds. > > Overall, loading the model is now taking ~50 seconds instead of 2 minutes. > > To increase Eden size, one needs to run a script similar to: > > | currentEdenSize desiredEdenSize | > currentEdenSize := Smalltalk vm parameterAt: 44. > desiredEdenSize := currentEdenSize * 4. > Smalltalk vm parameterAt: 45 put: desiredEdenSize. > > And then restart the image. > > I hope this report can be useful for some of you. I will try to make a blog post out of it, detailing other GC settings one can change from the image to improve performance. > > Best, > > Clement > > [1] A scavenge is basically the garbage collection of only young objects > [2] Eden is basically the space where objects are initially allocated. > [3] All numbers in the report are order of magnitudes and not precise numbers > > > > > !!!************************************************************************************* > "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!" > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

March 3, 2017

Re: [Pharo-dev] [squeak-dev] Re: [vwnc] Does anyone have a "new" string literal?

by Ben Coman

On Fri, Mar 3, 2017 at 2:17 AM, DavidLeibs <david.leibs(a)gmail.com> wrote: > > > Were I to do anything in Smalltalk and the Compiler and Parser frameworks > still supported the #compilerClass and #parserClass invocations at the > right > place I know what I need to do to give myself a huge leg up in > expressibility and performance. > > hi David, Section 5 might be of interest... https://hal.inria.fr/hal-01353884/file/Salg16a-IWST16-Lowcode.pdf It mentions #compilerClass. I don't know about #parserClass. Lowcode is here... http://smalltalkhub.com/#!/~ronsaldo/Lowcode cheers -ben

March 3, 2017

Re: [Pharo-dev] Importing icons

by Andrei Chis

Hi, On Fri, Mar 3, 2017 at 2:17 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > During the sprint, we wanted to fix issue https://pharo.fogbugz.com/f/ > cases/19668/importIcons-fromFolder-inClass-category- > sends-unimplemented-methods > > The issues is that some implementors of the method: > importIcons: icons fromFolder: aString inClass: aClass category: aCategory > > uses some methods that are not defined: Behavior>>methodStart: and > Behavior>>methodEnd > > Are the methods #importIcons:fromFolder:inClass:category: really used? > Is there a different standard way to import icons in Pharo? (I know the > one of Peter, but is this meant to replace those importIcons methods?) > I remember we were using that long time ago to import icons for glamour. But we did not do it in a while, so I'm not sure if now there is a better way to do it. Cheers, Andrei > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

March 3, 2017