- Pharo-dev - lists.pharo.org

Why the Spotter list is truncated?

by Blondeau Vincent

Hi, On a Moose image (should have the problem on a Pharo image too), I wanted to inspect the senders of printOn: (~ 400 results). The end of the list finishes at MBVersionInfo>>printOn:... Where are the others??? : [cid:image001.png@01D1577A.F28341D0] Moreover, on the first page, I have to go in the sender sublist to be able to click on the arrow to have the list... and clicking on #senders does nothing.... [cid:image002.png@01D1577A.F28341D0] Thanks in advance for solving the issues, Cheers Vincent ________________________________ 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.

Jan. 25, 2016

The shortcuts learnability is awesome, thank you!

by Mariano Martinez Peck

This is just to say a big thanks to all those that contributed to the new shortcut learnability. This is awesome. I love it. Bye, -- Mariano http://marianopeck.wordpress.com

Jan. 25, 2016

[pharo-project/pharo-core]

by GitHub

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

Jan. 25, 2016

[pharo-project/pharo-core] 21ac81: 50546

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 21ac81e9a1a6701a687cb20d113a977ea71f5c2c https://github.com/pharo-project/pharo-core/commit/21ac81e9a1a6701a687cb20d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-25 (Mon, 25 Jan 2016) Changed paths: A AST-Tests-Core.package/RBParserTest.class/instance/tests/testBlockNodeIsUsed.st A AST-Tests-Core.package/RBParserTest.class/instance/tests/testBlockReturnNode.st A Morphic-Base.package/FadingMorph.class/README.md A Morphic-Base.package/FadingMorph.class/definition.st A Morphic-Base.package/FadingMorph.class/instance/drawing/areasRemainingToFill_.st A Morphic-Base.package/FadingMorph.class/instance/drawing/fullDrawOn_.st A Morphic-Base.package/FadingMorph.class/instance/events-processing/handleMouseMove_.st A Morphic-Base.package/FadingMorph.class/instance/events-processing/rejectsEvent_.st A Morphic-Base.package/FadingMorph.class/instance/initialization/defaultFadingFactor.st A Morphic-Base.package/FadingMorph.class/instance/initialization/initialize.st A Morphic-Base.package/FadingMorph.class/instance/initialization/initializeAppearance.st A Morphic-Base.package/FadingMorph.class/instance/initialization/initializeLayout.st A Morphic-Base.package/FadingMorph.class/instance/properties-setting/beResetable.st A Morphic-Base.package/FadingMorph.class/instance/properties-setting/beUnResetable.st A Morphic-Base.package/FadingMorph.class/instance/stepping and presenter/resetAlpha.st A Morphic-Base.package/FadingMorph.class/instance/stepping and presenter/step.st A Morphic-Base.package/FadingMorph.class/instance/stepping and presenter/stepTime.st A Morphic-Base.package/FadingMorph.class/instance/stepping and presenter/wantsSteps.st R Morphic-Base.package/MenuItemMorph.class/instance/counting/countingMenu.st R Morphic-Base.package/MenuItemMorph.class/instance/events/insistMenu.st M Morphic-Base.package/MenuItemMorph.class/instance/events/invokeWithEvent_.st A Morphic-Base.package/MenuItemMorph.class/instance/events/showShortcut.st A Morphic-Base.package/ShortcutReminder.class/README.md A Morphic-Base.package/ShortcutReminder.class/class/as yet unclassified/defaultReminder.st A Morphic-Base.package/ShortcutReminder.class/class/as yet unclassified/showShortcut_.st A Morphic-Base.package/ShortcutReminder.class/class/settings/enabled.st A Morphic-Base.package/ShortcutReminder.class/class/settings/enabled_.st A Morphic-Base.package/ShortcutReminder.class/class/settings/settingsOn_.st A Morphic-Base.package/ShortcutReminder.class/definition.st A Morphic-Base.package/ShortcutReminder.class/instance/accessing/backgroundColor.st A Morphic-Base.package/ShortcutReminder.class/instance/accessing/backgroundColor_.st A Morphic-Base.package/ShortcutReminder.class/instance/accessing/limit.st A Morphic-Base.package/ShortcutReminder.class/instance/accessing/limit_.st A Morphic-Base.package/ShortcutReminder.class/instance/accessing/position.st A Morphic-Base.package/ShortcutReminder.class/instance/accessing/position_.st A Morphic-Base.package/ShortcutReminder.class/instance/accessing/textColor.st A Morphic-Base.package/ShortcutReminder.class/instance/accessing/textColor_.st A Morphic-Base.package/ShortcutReminder.class/instance/accessing/textSize.st A Morphic-Base.package/ShortcutReminder.class/instance/accessing/textSize_.st A Morphic-Base.package/ShortcutReminder.class/instance/defaults/defaultBackgroundColor.st A Morphic-Base.package/ShortcutReminder.class/instance/defaults/defaultFontFamiliyName.st A Morphic-Base.package/ShortcutReminder.class/instance/defaults/defaultLimit.st A Morphic-Base.package/ShortcutReminder.class/instance/defaults/defaultTextColor.st A Morphic-Base.package/ShortcutReminder.class/instance/initialization/initialize.st A Morphic-Base.package/ShortcutReminder.class/instance/private - utilities/createKeyTextMorph_.st A Morphic-Base.package/ShortcutReminder.class/instance/private - utilities/createLabelMorph_.st A Morphic-Base.package/ShortcutReminder.class/instance/private - utilities/fixKeyText_.st A Morphic-Base.package/ShortcutReminder.class/instance/private - utilities/fontSized_.st A Morphic-Base.package/ShortcutReminder.class/instance/private/keyTextFont.st A Morphic-Base.package/ShortcutReminder.class/instance/private/labelFont.st A Morphic-Base.package/ShortcutReminder.class/instance/private/large.st A Morphic-Base.package/ShortcutReminder.class/instance/private/medium.st A Morphic-Base.package/ShortcutReminder.class/instance/private/pointSize.st A Morphic-Base.package/ShortcutReminder.class/instance/private/positions.st A Morphic-Base.package/ShortcutReminder.class/instance/private/sizes.st A Morphic-Base.package/ShortcutReminder.class/instance/private/small.st A Morphic-Base.package/ShortcutReminder.class/instance/private/updateCount_.st A Morphic-Base.package/ShortcutReminder.class/instance/queries/wantsToShow_.st A Morphic-Base.package/ShortcutReminder.class/instance/settings/createResetCountButtonMorph.st A Morphic-Base.package/ShortcutReminder.class/instance/settings/customSettingsOn_.st A Morphic-Base.package/ShortcutReminder.class/instance/settings/resetCount.st A Morphic-Base.package/ShortcutReminder.class/instance/shortcut creation/createShortcutMorphFor_.st A Morphic-Base.package/ShortcutReminder.class/instance/shortcut creation/positionShortcut_.st A Morphic-Base.package/ShortcutReminder.class/instance/shortcut creation/remind_.st A Morphic-Base.package/ShortcutReminder.class/instance/shortcut creation/show_.st R Morphic-Base.package/ShortcutReminderMorph.class/README.md R Morphic-Base.package/ShortcutReminderMorph.class/class/counting/countingMenu.st R Morphic-Base.package/ShortcutReminderMorph.class/class/initialize/initialize.st R Morphic-Base.package/ShortcutReminderMorph.class/class/instance creation/with_.st R Morphic-Base.package/ShortcutReminderMorph.class/class/settings/enableShortcutReminder.st R Morphic-Base.package/ShortcutReminderMorph.class/class/settings/enableShortcutReminder_.st R Morphic-Base.package/ShortcutReminderMorph.class/class/settings/settingsOn_.st R Morphic-Base.package/ShortcutReminderMorph.class/class/settings/timesShortcutReminder.st R Morphic-Base.package/ShortcutReminderMorph.class/class/settings/timesShortcutReminder_.st R Morphic-Base.package/ShortcutReminderMorph.class/class/startup list/startUp_.st R Morphic-Base.package/ShortcutReminderMorph.class/definition.st R Morphic-Base.package/ShortcutReminderMorph.class/instance/accessing/alpha.st R Morphic-Base.package/ShortcutReminderMorph.class/instance/accessing/text_.st R Morphic-Base.package/ShortcutReminderMorph.class/instance/counting/countingMenu.st R Morphic-Base.package/ShortcutReminderMorph.class/instance/initialize/initialize.st R Morphic-Base.package/ShortcutReminderMorph.class/instance/stepping/alpha_.st R Morphic-Base.package/ShortcutReminderMorph.class/instance/stepping/resetAlpha.st R Morphic-Base.package/ShortcutReminderMorph.class/instance/stepping/step.st R Morphic-Base.package/ShortcutReminderMorph.class/instance/stepping/stepTime.st R Morphic-Base.package/ShortcutReminderMorph.class/instance/stepping/wantsSteps.st M Morphic-Base.package/ToggleMenuItemShortcutWithSymbol.class/instance/drawing/text.st A OpalCompiler-Core.package/extension/RBBlockNode/instance/hasBlockReturn.st M OpalCompiler-Core.package/extension/RBBlockNode/instance/isClean.st M OpalCompiler-Core.package/extension/RBBlockNode/instance/lastIsReturn.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50545.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50546.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50545.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50546.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st R UIManager.package/UIManager.class/class/utils/createPageTestWorkspace.st Log Message: ----------- 50546 17348 Enhance shortcut learnability https://pharo.fogbugz.com/f/cases/17348 17452 UIManager has a test method ... https://pharo.fogbugz.com/f/cases/17452 17022 Return sequence not always emitted https://pharo.fogbugz.com/f/cases/17022 http://files.pharo.org/image/50/50546.zip

Jan. 25, 2016

Re: [Pharo-dev] [Pharo-users] [ANN][Invite] Pharo Sprint 29 Jan

by Serge Stinckwich

Dear all, Paris will join the Pharo/Moose Sprint at the end of the week ! If you want to join us, the address is: UMMISCO Campus des Cordeliers 15 rue de l'Ã©cole de mÃ©decine, 75006 Paris. Escalier J, 1st Floor Regards, On Wed, Jan 20, 2016 at 4:37 PM, <marcus.denker(a)inria.fr> wrote: > > We will organize a Pharo sprint / Moose dojo Friday, 11th September, starting at > 10:00am. (Local Time Lille). > > It will be at the Inria Lille, Building B, third floor (RMoD offices) and > at the University of Chile, Santiago de Chile. > > Remotely, you can join us on Slack or the IRC channel #pharo on > irc.freenode.net server. During the sprint, we will try to synchronize > local and remote Pharo sprinters. > > As the building is not open to the public, please contact us before if > you plan to come. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Jan. 25, 2016

Re: [Pharo-dev] Fix To Include

by stepharo

Le 25/1/16 01:35, Ben Coman a Ã©crit : > On Mon, Jan 25, 2016 at 12:07 AM, stepharo <stepharo(a)free.fr> wrote: >> Hi ben >>> Is something stuck with integration by the CI monkey. >> >> Sometimes yes. Sometimes tests randomly failed on windows or something like >> that :) >>> 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. >> No we (either esteban marcus and me look at the code) at least I try to >> browse the code and click on a button. >>> Case 17296 --> Fix To Include 2016-01-21 22:29 >>> Case 17435 --> Fix To Include 2016-01-22 16:34 >> Fix to include are marked when we do not want that the monkey recheck them >> to avoid that they get unttaged for integration. >> >> When I do an integration session like today for example. I tend to go slowly >> and proceed with the domain I can understand. >> So now I will do >> >> Case 17296 > > Thanks, I see its done. > > >>> 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? >> Fix to include is just a marker to avoid endless verification of an issue. >> Now this is not because a fix is reviewed by the monkey that he should be >> automatically integrated. > > That is good to understand, and I agree. After reviewing someone > else's slice, I have been wary of setting it Fix To Include assuming > it *was* automatically integrated. Its good to know there'll be a > final quick review by you guys (if indeed Marcus and Esteban operate > the same way) > > However that if an issue is tagged Fix to Include on build 50538 and > remains in that state through several builds to 50543 without further > verification then this defeats a little bit the usefulness of the CI > verification if some conflicting changes are introduced between 50538 > and 50543. Yes this is why I do not use "fix to include" to tag issues when I'm not integrating them right away. Only for difficult ones I know the monkey gets strange and I integrate fast. > >> In addition we pay attention to some fast paths when people need it. > I understand. Mainly it was that it was opaque why my issue 17296 was > stuck waiting, and I wait a few days before I ask. Yes you should raise the point like that we pay attention and allocate specific resources. > >> Do I answer your questions? >> >> Stef >> >>> 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 Build 50543 > > > > On Mon, Jan 25, 2016 at 1:25 AM, stepharo <stepharo(a)free.fr> wrote: >>>> Fix to include are marked when we do not want that the monkey recheck >>>> them to avoid that they get unttaged for integration. >>> No, for me they are the ones to get integrated next. I always start with >>> them. i never integrate anything that is not âfix to includeâ. >>> >>> I configured my integrator tool to not show my anything else. This way I >>> am sure that I never integrate something wrong by mistake. > So just to pin this down, did Case 17296 actually show up listed in > the Integrator Tool between builds 50538 and 50543, and you've chosen > to skip it due to time constraints? (which is okay.) Or didn't it > show up? - in which case it would be good to understand why. > >> I do not have the same process. > It would be nice for there to be one process ;) > > I like Marcus' workflow. Its good for the project history to see who > pushed an issue to Fix to Include. Doing this immediately before > integration really shouldn't slow you down. The main thing is there > is no visibility on the tracker of who ran the Integration Tool (and > maybe that could be added sometime (low priority) ). > > cheers -ben > >

Jan. 25, 2016

Re: [Pharo-dev] Fix To Include

by Ben Coman

On Mon, Jan 25, 2016 at 12:07 AM, stepharo <stepharo(a)free.fr> wrote: > Hi ben >> >> Is something stuck with integration by the CI monkey. > > > Sometimes yes. Sometimes tests randomly failed on windows or something like > that :) >> >> 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. > > No we (either esteban marcus and me look at the code) at least I try to > browse the code and click on a button. >> >> Case 17296 --> Fix To Include 2016-01-21 22:29 >> Case 17435 --> Fix To Include 2016-01-22 16:34 > > Fix to include are marked when we do not want that the monkey recheck them > to avoid that they get unttaged for integration. > > When I do an integration session like today for example. I tend to go slowly > and proceed with the domain I can understand. > So now I will do > > Case 17296 Thanks, I see its done. >> >> 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? > > Fix to include is just a marker to avoid endless verification of an issue. > Now this is not because a fix is reviewed by the monkey that he should be > automatically integrated. That is good to understand, and I agree. After reviewing someone else's slice, I have been wary of setting it Fix To Include assuming it *was* automatically integrated. Its good to know there'll be a final quick review by you guys (if indeed Marcus and Esteban operate the same way) However that if an issue is tagged Fix to Include on build 50538 and remains in that state through several builds to 50543 without further verification then this defeats a little bit the usefulness of the CI verification if some conflicting changes are introduced between 50538 and 50543. > In addition we pay attention to some fast paths when people need it. I understand. Mainly it was that it was opaque why my issue 17296 was stuck waiting, and I wait a few days before I ask. > > Do I answer your questions? > > Stef > >> 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 Build 50543 On Mon, Jan 25, 2016 at 1:25 AM, stepharo <stepharo(a)free.fr> wrote: > >>> Fix to include are marked when we do not want that the monkey recheck >>> them to avoid that they get unttaged for integration. >> >> No, for me they are the ones to get integrated next. I always start with >> them. i never integrate anything that is not âfix to includeâ. >> >> I configured my integrator tool to not show my anything else. This way I >> am sure that I never integrate something wrong by mistake. So just to pin this down, did Case 17296 actually show up listed in the Integrator Tool between builds 50538 and 50543, and you've chosen to skip it due to time constraints? (which is okay.) Or didn't it show up? - in which case it would be good to understand why. > > I do not have the same process. It would be nice for there to be one process ;) I like Marcus' workflow. Its good for the project history to see who pushed an issue to Fix to Include. Doing this immediately before integration really shouldn't slow you down. The main thing is there is no visibility on the tracker of who ran the Integration Tool (and maybe that could be added sometime (low priority) ). cheers -ben

Jan. 25, 2016

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

by Eliot Miranda

Hi Doru, On Sun, Jan 24, 2016 at 12:42 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Eliot, > > I created a package to easily reproduce the problem: > https://dl.dropboxusercontent.com/u/18323746/Tmp/moose-6-for-GC-bug.zip > > In there you will get: > - an image, > - the MSE file to be loaded, and > - a Playground script that loads that file. > I take it that this is a Spur image. t would be great to have both a Spur and a V3 mage to compare, as similar as is easily achievable. But as long as there's both a V3 and a Spur image... > > On my Mac, this takes some 3 minutes, while before it took about 1 minute. > > Let me know if you need anything else. > > Cheers, > Doru > > > > > On Jan 24, 2016, at 9:33 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > Hi Doru, > > > > On Sun, Jan 24, 2016 at 12:26 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > Hi Eliot, > > > > Thanks for looking at this. > > > > Please let us know what support you need, or what kind of experiments we > can do on our side. > > > > What I want most of all is a test case that I can run on Mac. I'm > assuming that I can just copy the job that Vincent mentioned in his email > and use that as a test case. Do you see any issues with that? If so, how > do I get a really bug MOOSE test case to run on Mac? > > > > > > Cheers, > > Doru > > > > > > > On Jan 24, 2016, at 9:20 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > > > Hi Vincent, > > > > > > I'll take a look early this week. There's clearly a bug; the Spur > > > GC is /not/ collecting those dictionaries :-( (thanks Stephan!). > > > Assuming the bug is fixed times should come down (see below). It may > > > be that the bug in Slang that I introduced in December has broken > > > things because I don't see these symptoms in my daily work (but I use > > > the most up-to-date VM version possible ;-) ). But I'm not in denial > > > and look forward to using MOOSE as a good stress case. > > > > > > I do want to say that the GC is not complete. Right now we have a > > > scavenger that works well, and a global GC that has a slow compaction > > > algorithm, and hence there are significant pauses. For example here's > > > what I see as typical in using SPur for VMMaker work: > > > > > > memory 160,432,128 bytes > > > old 153,658,624 bytes (95.8%) > > > young 4,838,224 bytes (3%) > > > used 127,009,928 bytes (79.2%) > > > free 28,126,456 bytes (17.5%) > > > GCs 7,265 (?? ms between GCs) > > > full 36 totalling 13,229 ms (0% uptime), avg 367.5 ms > > > incr 7,229 totalling 6,546 ms (0% uptime), avg 0.9 ms > > > tenures 3,589,063 (avg 0 GCs/tenure) > > > > > > (There's no uptime in the above stats because we're still > > > transitioning Squeak to the 64-bit clock and there are consequently > > > bugs in computing uptime). > > > > > > The plan is to add an incremental global GC so this work is broken up > > > into much smaller pieces. I don't want to see 700ms pauses in global > > > GC; one can't do game animation with that. So an incremental > > > mark-sweep is needed. There are two nice papers we're considering, > > > one from Lua and one for a truly concurrent collector. But time is > > > pressing, so if anyone out there knows GC and is interested in helping > > > this is a nicely self-contained project for which we'd love to have > > > volunteers. > > > > > > _,,,^..^,,,_ (phone) > > > > > >> On Jan 24, 2016, at 3:43 AM, Vincent BLONDEAU < > vincent.blondeau(a)polytech-lille.net> wrote: > > >> > > >> 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 > > >> <report504.txt> > > >> <report1175.txt> > > > > > > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > -- _,,,^..^,,,_ best, Eliot

Jan. 24, 2016

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

by Eliot Miranda

Hi Stephan, On Sun, Jan 24, 2016 at 1:04 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 24-01-16 21:20, Eliot Miranda wrote: > >> Hi Vincent, >> >> I'll take a look early this week. There's clearly a bug; the Spur >> GC is /not/ collecting those dictionaries :-( (thanks Stephan!). >> > > I'm afraid the dictionaries are part of the model and should not be > garbage collected. They do make things slow though, so we need a better > model. Garbage collection cycle takes a few seconds now on my 4 GHz 4790K > 32GB. So Vincent's awful sats are no longer showing up? He reported a 140 second GC pause. What are you seeing? (.i.e. can you post the full stats?) If this has disappeared then I suspect my Slang bug, which I fixed yesterday. But I will investigate. > Stephan > _,,,^..^,,,_ best, Eliot

Jan. 24, 2016

4th Chapter of Updated Pharo by Example ready for review.

by stepharo

4th Chapter of Updated Pharo by Example ready for review. https://ci.inria.fr/pharo-contribution/view/Books/job/UpdatedPharoByExample… This one was way simpler than the PharoTour and FirstAplication, so I imagine that the review will be easier too. Stef Not thinking too much, just doing.

Jan. 24, 2016