April 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

April 14, 2016

[pharo-project/pharo-core] 0881e8: 50684

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 0881e8b8454b3fe11299b43f9b570f0f5b2007d0 https://github.com/pharo-project/pharo-core/commit/0881e8b8454b3fe11299b43f… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-04-14 (Thu, 14 Apr 2016) Changed paths: M ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/symbolic versions/stable_.st A ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/versions/v2%5F6%5F3_.st M QualityAssistant.package/QANautilusPlugin.class/instance/registration/registerTo_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50683.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50684.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50683.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50684.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50684 17989 QualityAssistant v2.6.3 (memory leak fix) https://pharo.fogbugz.com/f/cases/17989 http://files.pharo.org/image/50/50684.zip

April 14, 2016

[pharo-project/pharo-core]

by GitHub

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

April 14, 2016

[pharo-project/pharo-core] ea58ed: 50683

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: ea58ed3a4f0e88de5aac899248cde2f3f8348158 https://github.com/pharo-project/pharo-core/commit/ea58ed3a4f0e88de5aac8992… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-04-14 (Thu, 14 Apr 2016) Changed paths: A Morphic-Core.package/HandMorph.class/class/cleanup/cleanUp.st R Morphic-Core.package/HandMorph.class/class/events-processing/cleanUp.st R Morphic-Widgets-Basic.package/ButtonClicked.class/README.md R Morphic-Widgets-Basic.package/ButtonClicked.class/definition.st M Morphic-Widgets-Basic.package/MultistateButtonMorph.class/definition.st M Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/adding/addUpAction_.st M Morphic-Widgets-Basic.package/MultistateButtonMorph.class/instance/event handling/mouseUp_.st A Nautilus.package/AbstractNautilusUI.class/class/icons behavior/arrowDown_.st A Nautilus.package/AbstractNautilusUI.class/class/icons behavior/arrowUp_.st A Nautilus.package/AbstractNautilusUI.class/class/icons behavior/runClassInitializeMethod_.st A Nautilus.package/AbstractNautilusUI.class/class/icons behavior/runExampleMethod_.st A Nautilus.package/AbstractNautilusUI.class/class/icons behavior/saveDirtyPackages_.st M Nautilus.package/AbstractNautilusUI.class/instance/accessing/model_.st M Nautilus.package/AbstractNautilusUI.class/instance/icon/packageIconFor_.st R Nautilus.package/AbstractNautilusUI.class/instance/icons behavior/arrowDown_.st R Nautilus.package/AbstractNautilusUI.class/instance/icons behavior/arrowUp_.st R Nautilus.package/AbstractNautilusUI.class/instance/icons behavior/runClassInitializeMethod_.st R Nautilus.package/AbstractNautilusUI.class/instance/icons behavior/runExampleMethod_.st R Nautilus.package/AbstractNautilusUI.class/instance/icons behavior/saveDirtyPackages_.st A Nautilus.package/MethodWidget.class/class/protocol/removeAllFromMethodsIconsCache_.st R Nautilus.package/MethodWidget.class/instance/icon/buildUpAndDownArrowIcon_.st M Nautilus.package/MethodWidget.class/instance/icon/methodIconFor_.st M Nautilus.package/MethodWidget.class/instance/protocol/methodsIconsCache.st M Nautilus.package/MethodWidget.class/instance/protocol/removeAllFromMethodsIconsCache_.st A Nautilus.package/Nautilus.class/instance/history/historyChanged.st M Nautilus.package/Nautilus.class/instance/history/next.st M Nautilus.package/Nautilus.class/instance/history/previous.st M Nautilus.package/Nautilus.class/instance/history/registerHistoryNewEntry.st M Nautilus.package/Nautilus.class/instance/history/removeFromHistory_.st A Nautilus.package/NautilusUI.class/class/menus behavior/runTestForAMethod_notifying_.st A Nautilus.package/NautilusUI.class/class/menus behavior/runTestForAMethod_notifying_priority_.st A Nautilus.package/NautilusUI.class/class/widget method/notifyTitle_contents_color_.st M Nautilus.package/NautilusUI.class/instance/menus behavior/runTestForAMethod_notifying_.st R Nautilus.package/NautilusUI.class/instance/menus behavior/runTestForAMethod_notifying_priority_.st M Nautilus.package/NautilusUI.class/instance/menus behavior/toggleBreakpoint.st M Nautilus.package/NautilusUI.class/instance/widget method/notifyTitle_contents_color_.st A Polymorph-Widgets.package/UITheme.class/class/cleanup/cleanUp.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50682.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50683.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50682.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50683.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50683 17985 Package and methods icon cache are references nautilus instance which shows them first time https://pharo.fogbugz.com/f/cases/17985 17964 Remove usage of Announcer in MultistateButtonMorph for the action to be done when clicked https://pharo.fogbugz.com/f/cases/17964 17986 Nautilus uses old EventManager to subscribe on historyChanged which never garbage collected https://pharo.fogbugz.com/f/cases/17986 17966 garbage subinstance of SystemWindow at image startup https://pharo.fogbugz.com/f/cases/17966 17987 RubFindReplaceService produce leak subscriptions https://pharo.fogbugz.com/f/cases/17987 http://files.pharo.org/image/50/50683.zip

April 14, 2016

[pharo-project/pharo-core]

by GitHub

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

April 14, 2016

[pharo-project/pharo-core] dc0efa: 50682

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: dc0efa27fb4cdedbab1f58570164d815932cec74 https://github.com/pharo-project/pharo-core/commit/dc0efa27fb4cdedbab1f5857… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-04-14 (Thu, 14 Apr 2016) Changed paths: A Collections-Tests.package/SetTest.class/instance/test - integrity/testHealthyWorks.st A Collections-Tests.package/SetTest.class/instance/test - integrity/testSetWithNilItemsIsHealthy.st M Collections-Unordered.package/Set.class/instance/testing/isHealthy.st A Polymorph-Widgets.package/MessageDialogWindow.class/instance/initialization/defaultTextFont.st A Polymorph-Widgets.package/MessageDialogWindow.class/instance/initialization/initialize.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50681.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50682.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50681.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50682.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Traits.package/TApplyingOnClassSide.class/instance/initialize-release/uses_slots_.st Log Message: ----------- 50682 17015 Failing test: SetTest>>#testAllSetsAreHealthy https://pharo.fogbugz.com/f/cases/17015 17979 (MessageDialogWindow new text: Hello) open should work https://pharo.fogbugz.com/f/cases/17979 17897 Slot method used by Nautilus but not implemented https://pharo.fogbugz.com/f/cases/17897 http://files.pharo.org/image/50/50682.zip

April 14, 2016

Reminder: CFP - IWST 2016 - International Workshop on Smalltalk Technologies

by jannik laval

[Please accept our apologies if you receive multiple copies of this call] [Please send to interested colleagues / mailing-lists] ************************************************************************************************************ CALL FOR PAPERS IWST16 â International Workshop on Smalltalk Technologies Prague, Czech Republic; August 23th, 2016 http://www.esug.org/wiki/pier/Conferences/2016/International-Workshop-IWST_… ************************************************************************************************************ ------------------- Goals and scopes ------------------- The goals of the workshop is to create a forum around advances or experience in Smalltalk and to trigger discussions and exchanges of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Participants are invited to submit research articles or industrial papers. This year we want to open two different tracks: one research track and one industrial track with less scientific constraints. We expect papers of three kinds: - Short position papers describing emerging ideas - Long research papers with deeper description of experiments and of research results. - Industrial papers with presentation of real and innovative Smalltalk applications; this kind of paper should enlighten why Smalltalk is really appropriate for your application. *We will not enforce any length restriction.* -------------------- Important Dates -------------------- Submission deadline: *May 15th, 2016* Notification deadline: June 20th, 2016 Camera-ready : July 13th, 2016 Workshop : August 23th, 2016 *All accepted papers will be published in ACM DL (To be confirmed)* *Best papers would be extended in an International Journal* ------------------- Topics ------------------- We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: -Aspect-oriented programming, -Design patterns, -Experience reports, -Frameworks, -Implementation, new dialects or languages implemented in Smalltalk, -Interaction with other languages, -Meta-programming and Meta-modeling, -Tools ------------------- Best Paper Award ------------------- To encourage the submission of high-quality papers, the IWST organizing committee is very proud to announce a Best Paper Award for this edition of IWST. We thank the Lam Research Corporation for its financial contribution which makes it possible for prizes for the three best papers: 1000 USD for first place, 600 USD for second place and 400 USD for third place. The ranking will be decided by the program committee during the review process. The awards will be given during the ESUG conference social event. The Best Paper Award will take place only with a minimum of six submissions. Notice also that to be illegible, a paper must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. ------------------- Publication ------------------- Both submissions and final papers must be prepared using the ACM SIGPLAN 10 point format. Templates for Word and LaTeX are available at http://www.acm.org/sigs/sigplan/authorInformation.htm. This site also contains links to useful informations on how to write effective submissions. ------------------- Submission ------------------- All submissions must be sent via easychair: https://easychair.org/conferences/?conf=iwst20160 ------------------- Program chairs ------------------- Anne Etien (UniversitÃ© de Lille 1, France) Jannik Laval (UniversitÃ© Lyon 2 LumiÃ¨re, France) -- ~~Jannik Laval~~ Enseignant-chercheur Responsable PÃ©dagogique Licence Coordonnateur de Projet en SystÃ¨me d'Information IUT LumiÃ¨re, UniversitÃ© Lyon LumiÃ¨re laboratoire DISP http://www.jannik-laval.eu http://www.phratch.com http://www.approchealpes.info

April 14, 2016

Re: [Pharo-dev] Missing #removeDuplicates

by stepharo

thanks nicolai. Do you think the old removeAll would be good to add to the collection. Le 11/4/16 09:06, Nicolai Hess a Ã©crit : > > > 2016-04-10 8:55 GMT+02:00 Volkert <volkert(a)komponentenwerkstatt.de > <mailto:volkert@komponentenwerkstatt.de>>: > > Sorry. i meant AthensSkatch ;-) It is a nice demo about using athens. > > http://smalltalkhub.com/#!/~NicolaiHess/AthensSketch > <http://smalltalkhub.com/#%21/%7ENicolaiHess/AthensSketch> > > > > Hi Volkert, > I just replaced > #removeDuplicates with > #asSet > (this should work now). > > (and replaced some deprecated on:send:to: calls (for Announcements) with > when:send:to: > > in the latest version. > > > Nicolai > > > > > On 10.04.2016 07:42, stepharo wrote: > > > > Le 9/4/16 22:36, Volkert a Ã©crit : > > What happens to OrderedCollection>>removeDuplicates in > Pharo 5.0? In Pharo 4.0 it was part of a Package > "GroupManager"? > > > It was probably badly implemented or only used in group > manager (whose code was terrible) and we cleaned it. > Now we could reintroduce it but in the right place and with tests. > > It breaks the nice Package "AthensScratch" in Pharo 5.0 > > > what is athenscracth? > > > BW. > Volkert > > > > > > >

April 14, 2016

Re: [Pharo-dev] A weak/leak story

by Tudor Girba

Hi, Great work. Thank you very much for this summary. Cheers, Doru > On Apr 12, 2016, at 2:41 AM, Guille Polito <guillermopolito(a)gmail.com> wrote: > > Hi list, > > With Pavel and Christophe we spend some time digging these last weaks chasing the memory leaks we were seeing lately. It is a long story to tell, so this mail is divided in three: > > 1) A brief intro to weak structures and finalization in Pharo, for those that do not know, > 2) A bit of history to explain what happened in pre-spur and post-spur, > 3) The actual cause of the memory leak today, > 4) How to avoid them in your application, and what are we going to do to prevent this in the future. > > For those that need/want/prefer just the practical explanation, you can jump over 2) and just read 1) and 3). > > ======================================================================== > 1. A weak explanation > ======================================================================== > > To cleanup objects upon garbage collection, Pharo and Squeak use a finalization mechanism based on a Weak Registry. That is, if you want to execute some cleanup (like closing a file) when an object is about to be collected, you have to put your object inside the weak registry with the corresponding executor/finalizer object. The object you want to 'track' is hold weakly by this weak registry i.e., if the only reference to the object is from the weak registry, it will be chosen for garbage collection. When this object is collected, a special process in the Pharo image will send #finalize to your executor object where you implement your cleanup. > > To interact with the weak registry, there are two main subscription messages: > > - #add:executor: > > Will add an object to the registry with the executor that is send as argument. > > - #add: > > Will add an object to the registry, and use as executor a 'shallow copy' of the object. > > Some conclusions to be made from this: > 1) If the executor points strongly to the object that we want to collect, it will never be collected. That is why the #add: message creates a copy of the object. > 2) If we do not provide an explicit executor, the registered object should already contain all information required for the finalization (like file handlers or external pointers). If not, the shallow copy will not be able to finalize correctly. > > Also: > - Using weak objects/references do not guarantee that #finalize will be called, you need to put your object inside the registry! > - Using weak objects/references do not guarantee that your object will be magically collected. You can still cause memory leaks! > > ======================================================================== > 2. A weak story > ======================================================================== > > Pharo and Squeak use historically the weak registry mentioned above. Because of the limitations that we mentioned, a different kind of weak structure called Ephemerons is required/more useful. To overcome some of these limitations, Igor (Hi Igor! maybe you're reading :)) implemented a couple of years ago a new finalization mechanism that, IIANM, worked as follows: > > - Some weak objects could have a first instance variable with a special linked list > - When the object was about to be collected, instead it was removed from the weak structure and put into its container's linked list > - On the image side, a special process iterated all special linked lists and executed #finalize on the weak objects > > This mechanism was called NewFinalization, in contrast with what was called LegacyFinalization. Of course these names are context dependent, since today's Pharo is back to the so called legacy one ;). NewFinalization was implemented as the default finalization mechanim in Pharo, both in VM and image side. But the VM changes remained in the Pharo branch of development. After some discussions, I remember Igor and Eliot agreed that what they actually needed were Ephemerons, and since Eliot had started working on Spur at that time, he said he would provide Ephemeric classes with the new object format. > > Basically, for those interested, an ephemeron is an association > > weak key -> strong value > > with the special quality that upon garbage collection all references to the weak key that are computed from the strong value (directly or indirectly) are taken as weak. This allows the collection of the weak key even if the strong value points to it, but requires some more machinery in the GC/VM. You can read more in here [1]. > > Until a couple of months/weeks ago, Pharo was using the NewFinalization mechanism with it's special image and VM support. And Squeak was using the 'Legacy' one. And then Spur arrived. > > So Spur arrived, and Eliot and Esteban made a lot of effort to simplify the VM's maintenance, and they merged both branches. As a conclusion, Pharo Spur VM did not support any more NewFinalization. This provoked at first some leaks because objects were not being finalized. A couple of weeks ago, we migrated back the image code to use the 'Legacy' mechanism, see issue 17537 [2]. > > And then finalization was not working either. Nor #finalize was being called on executors, nor objects in the weak registry were collected. As a symptom, opening any tool will cause 30 new everlasting registrations into the weakregistry, and no tools were collected. > > > ======================================================================== > 3. The cause > ======================================================================== > > After lots of digging, we finally found what was the particular issue causing objects in the weak registry to not be collected. In some words, it is caused by the normal belief that "weak objects are magical", which caused that weak references and finalizers are really spread over the system with no proper care. And particularly related to the usage of announcements. > > To explain better, I made some pictures for you :) > > > ***First, imagine you have a morph with its own local announcer. You subscribe to two events, and the graph will look like this. > > <strong.png> > > - the announcer knows two strong subscriptions > - the subscriptions know the announcer to be able to unregister > - the subscriptions know the registered object to send the message in case the event happens > > This forms a closed graph that will be collected. No problem so far. > > > ***Second, let's see what happens if we use weak subsriptions: > > <weak.png> > > - the announcer know two weak subscriptions > - these weak subscriptions know the announcer strongly to be able to unregister > - they also know the subscriber object but weakly > - THE difference is made by the weak registry: a global object that manages when and how objects are finalized. In the case of announcers, the weak registry will store weakly the subscriber morph, and strongly the weak announcer subscription. > > So far so good also: the references to the morph are weak. When the morph is collected, the weak registry will execute finalize on the announcement subscriptions. The subscriptions will unregister from the morph. > > > ***The really problematic case is the third one: mixing weak and strong subscriptions in the same announcer. > > <both.png> > > The object graph is just a mixture of the two other ones. One weak subscription and one strong subscription. BUT: > > - there is a strong path from a global object (the weak registry) to the subscriber (the morph) > - then the morph is never collected > - the weak registry never finalizes the weak announcement subscription > - the graph remains there forever. > > > And these are the simple cases that show the problem. Imagine that you can have this same configuration but in cycles/chains among different morphs/announcements. Plus this is aggravated by evil globals (e.g., the theme and the HandMorph remembers the last focused morph, the system window class remembers the last top window even if it was closed...). > > > ======================================================================== > 4. The solution? > ======================================================================== > > Our solution for the moment is simple. We would like to enforce the following two rules for announcements: > > - announcers local to a morph should only be used strongly. YES, this may cause small hiccups and leaks, for example if you register a morph A to the announcer to another morph B. But in the long term, these two will form a closed graph and will be collected. > > - announcers used globally, such as the System announcer, should be used only and uniquely in a weak manner. Like that we ensure that they are loosely coupled for real. > > So, please, please, do not use weak announcements unless you're really sure of what you're doing. At least, until we have ephemerons and we are sure everything works as expected. Ephemerons would solve this in a more natural way: if we model the weak registry subscription as an ephemeron, any reference to the weak #key that arrives from the #value will be treated as weak also. > > Other action points we are working on: > - fixing tools to follow the rules above > - We are also writing tests to check that tools (gt*, Nautilus, Rubric, FT) do not leak. > - chasing other small memory leaks created by stepping, focus global variables... > > > ((fogbugz allIssues select: [ :each | each relatedToLeak ]) > flatCollect: [ :each | each participants ]) > do: #thanks > > > > [1] https://en.wikipedia.org/wiki/Ephemeron > [2] https://pharo.fogbugz.com/f/cases/17537/SystemAnnouncer-has-far-too-many-su… -- www.tudorgirba.com www.feenk.com "Things happen when they happen, not when you talk about them happening."

April 13, 2016

Re: [Pharo-dev] NewExternalWebBrowser in Pharo 5

by Sven Van Caekenberghe

> On 13 Apr 2016, at 14:33, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Esteban, > > expected you to be in holiday ;) > >> Torsten, you rule! :) > > Thanks - but such things are easy to provide now. It would not be possible without NativeBoost from Igor > or all your work in providing the UFFI. But also QualityAssistent, STHub, Catalog, Versionner, ... > helped me to quickly provide that. > > So Pharo is a community effort - each small step counts and makes us all faster and better for the next. > So we all rule - and especially Pharo rules! > >> ps: is this on catalog? > > Yes - the docu mentions that already - it will soon appear in catalog. The config is prepared and available in the MetaRepo. > > As you know the catalog grabber only runs each 24hours - so we have to wait until tomorrow before it is visible. So stay > patient or trigger the grabber manually. I do not have access to it. :( > > When I implemented config browser back in Pharo 2.0 I directly grabbed the configs from the MetaRepo. So this worked lively > and one can see directly the changes. So in Pharo 4 this new project is already visible in Configuration Browser. > > In Pharo 5 with Catalog now one always has to wait one day before the effect is visible on http://catalog.pharo.org > > So I would say that we need something more lively for the speed at which Pharo progresses also for > Catalog again. BTW, CatalogProvider now caches image side too, for 24 hours. You can do CatalogProvider default reset to force a reload, but that won't make the generation of new catalogs faster. >> pps: we need to enhance the catalog to provide more and better information to users about packages available... > > Yes - I would like to see something similar to "Ubuntu Software center" in the future. With a picture, styled > description, ... > > But one step after the other. Step by step it goes. > > Bye > T. >

April 13, 2016