- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]
by GitHub June 30, 2014

June 30, 2014

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

1 0

[pharo-project/pharo-core] 091e69: 40055
by GitHub June 30, 2014

June 30, 2014

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 091e69a4d07cb65c1b95d0972dc08116dd22d64e https://github.com/pharo-project/pharo-core/commit/091e69a4d07cb65c1b95d097… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-30 (Mon, 30 Jun 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script55.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40055.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Slot.package/InstanceVariableSlot.class/instance/testing/isSpecial.st A Slot.package/Slot.class/instance/testing/isSpecial.st R Slot.package/SlotClassBuilder.class/instance/deprecated/client_.st M Slot.package/SlotClassBuilder.class/instance/private/apply_.st R System-ObjectStorage.package/extension/SmalltalkImage/instance/storeDataOn_.st M Tool-Profilers.package/MessageTally.class/instance/collecting leaves/leavesInto_fromSender_.st M Tool-Profilers.package/MessageTally.class/instance/comparing/sonsOver_.st M Tool-Profilers.package/MessageTally.class/instance/printing/printOn_.st M Tool-Profilers.package/QSystemTally.class/instance/testing/isPrimitives.st A Tool-Profilers.package/SpaceTally.class/class/fileout/printSpaceAnalysis.st M Tool-Profilers.package/SpaceTally.class/instance/fileout/printSpaceAnalysis.st M Tool-Profilers.package/TimeProfiler.class/instance/accessing-computed/leaveItems.st A Traits.package/TClassDescription.class/instance/slots/usesSpecialSlot.st Log Message: ----------- 40055 13441 Small code critique cleanup in Tools https://pharo.fogbugz.com/f/cases/13441 13442 add test to classes for checking non-ivar slots are used https://pharo.fogbugz.com/f/cases/13442 13443 remove #storeDataOn: from SmalltalkImage https://pharo.fogbugz.com/f/cases/13443 http://files.pharo.org/image/40/40055.zip

1 0

caturing key pressed
by Pablo R. Digonzelli June 30, 2014

June 30, 2014

Hi all , I need to capture the key pressed in a Spec TextModel and ListModel. Can someone give orientation? TIA Ing. Pablo Digonzelli Software Solutions IP-Solutiones SRL Metrotec SRL 25 de Mayo 521 Email: pdigonzelli(a)softsargentina.com pdigonzelli(a)gmail.com Cel: 5493815982714

1 0

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
by Goubier Thierry June 30, 2014

June 30, 2014

I'm trying to see if I could do it in a cleaner way, and I found it! On partial updates, AltBrowser is able to cleanly delete the node morphs because it sends #noteRemovalOfAll: aCollection to MorphTreeMorph, which has the selection testing and removal code. Which means changing MorphTreeMorph>>updateContentsWithPreviouslyExpanded: aNodeList nodeList := nil. self noteRemovalOfAll: self allNodeMorphs. "<-- Changed" (self nodeList isNil or: [ self nodeList isEmpty ]) ifTrue: [ nodeList := nil. ^ self emptySelection ]. self addSubmorphsFromNodeList: self currentNodelist previouslyExpanded: aNodeList It solves the problem. However, I don't like this that much overall, because delete is never sent to the node morphs themselves, and this seems very wrong to me. Thierry Le 30/06/2014 16:56, Goubier Thierry a Ã©crit : > It would solve the selection kept while updating the full list, but it > won't solve partial updates. You would also be apparently deselecting > and reselecting when appending elements to the list. > > Thierry > > Le 30/06/2014 16:15, Nicolai Hess a Ã©crit : >> How about this change, if it rebuilds the whole list, we can savely >> remove the selection, or not? >> >> MorphTreeMorph>> >> addSubmorphsFromNodeList: aNodeList previouslyExpanded: expandedNodeList >> | morphList | >> morphList := OrderedCollection new. >> self >> addMorphsTo: morphList >> from: aNodeList >> withExpandedItems: expandedNodeList >> atLevel: 0. >> self insertNewMorphs: morphList. >> self listManager emptySelection. "<--- >> added" >> self listManager updateSelectionFromModel. >> self roots do: [:r | r updateChildrenRecursively]. >> self updateColumnMorphs >> >> >> >> >> 2014-06-30 15:35 GMT+02:00 Goubier Thierry <thierry.goubier(a)cea.fr >> <mailto:thierry.goubier@cea.fr>>: >> >> Ok, I have the test case showing the problem. >> >> | c w t | >> c := ClassTreeExample new. >> w := c openOn: Collection. >> t := c dependents last. >> t expandAll. >> t selectAll. >> c updateList. >> t listManager selectedMorphList do: [ :each | self assert: ( t >> allNodeMorphs includes: each ) ] >> >> Fail on the final assert. Switching to single selection hold the >> same error. >> >> Interestingly, reselecting cleans the selectedMorphList. >> >> | c w t | >> c := ClassTreeExample new. >> w := c openOn: Collection. >> t := c dependents last. >> t expandAll. >> t selectAll. >> c updateList. >> t setSelectedMorph: t allNodeMorphs first. >> t listManager selectedMorphList do: [ :each | self assert: ( t >> allNodeMorphs includes: each ) ] >> >> This one has no error. >> >> Changing the way Nautilus maintain the selection would work. Forcing >> selectedMorphList to be cleaned up on addition / removal in the list >> would be nice too (but possible update code can delete the node >> morphs by itself). >> >> Thierry >> >> >> Le 30/06/2014 10:15, Johan Brichau a Ã©crit : >> >> Hi Nicolai, >> >> >> Do you have a method selected in the browser? >> As the memory leak happens via the selectedMorphs instvar, it >> requires a package to be selected (and maybe even a method). >> >> Before and after the load. I do this and notice the increase. >> >> Smalltalk garbageCollect. >> MorphTreeNodeMorph allInstances size. >> >> It really only becomes problematic (i.e. out-of-mem) when you >> load large projects. Maybe MOOSE will qualify? >> >> Yes, I was astonished as well when I noticed that every update >> was rebuilding the entire set of Morphs. It's the easiest >> solution of course but it does impose a lot of overhead. >> First, I will see how to solve that leaking problem. Then I will >> take a look at the update itself. >> >> I can only spend some of my free time on this, so I will >> continue tonight. >> >> best, >> Johan >> >> On 30 Jun 2014, at 09:09, Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>> wrote: >> >> 2014-06-29 22:31 GMT+02:00 Johan Brichau <johan(a)inceptive.be >> <mailto:johan@inceptive.be>>: >> >> On 27 Jun 2014, at 14:00, Goubier Thierry >> <thierry.goubier(a)cea.fr <mailto:thierry.goubier@cea.fr>> >> wrote: >> >> It seems to depend on the Nautilus window state. If >> you've just opened it, then nothing seems to be amiss. >> If you start to select things in it, you start to see >> time spent in updateClassView, but why? >> >> >> I just found that the instances are being kept by the >> MorphTreeListManager#__selectedMorphs instvar. So, that >> observation is correct: you need to have a package selected. >> >> What seems to happen is that on every package load, the >> Nautilus package tree is updated (which means a >> PackageTreePackageNodeModel is created for each package in >> the image via #asNautilusNodeWithModel:). >> This update does not clear the selectedMorphs list and just >> this single reference seem to keep the entire package tree >> model and its Morphs in memory. >> >> There were 496 morphs in the selectedMorphs list and when I >> cleaned that, all trailing Morphs and PackageNodeModelNodes >> (and all the other garbage) could be gc'ed. >> >> On to investigating the growth of the selectedMorphs >> variable... >> >> Johan >> >> >> Yes, we had quite some bugs with this package tree update >> in the past. What I don't understand is, why >> is the whole tree removed and rebuild, maybe this is a >> common strategy in Morphic, update a list ore tree >> will always rebuild the whole morph structure? But it >> happens even if the structure is the same and >> just this little package/dirty package icon is updated. >> >> Another issue is this "selected package/package selection". >> The tree (and for example the >> category list and/or method list" as well), stores the >> selection on multiple ways, in the model >> (PackageTreeNautilus), the >> UI (PackageTreeNautilusUi) and the treelist morph. Once as a >> SelectedTreeNode, a Package from Nautilus Model and >> once as a PackgeTreeSelection/__PackageTreeTagSelection. >> I find it pretty confusing. >> >> >> BTW, I still can not reproduce this memory leak behavior. I >> tried this: >> >> [ Gofer new smalltalkhubUser: 'ObjectProfile' >> project: 'Roassal2'; >> package: 'ConfigurationOfRoassal2'; >> load. >> (Smalltalk at: #ConfigurationOfRoassal2) load ] timeToRun. >> >> with and without an open SystemBrowser. But the load time and >> memory consumption is the same. >> >> >> Nicolai >> >> >> >> >> >> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 >> <tel:%2B33%20%280%29%201%2069%2008%2032%2092> / 83 95 >> >> > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

1 0

Re: [Pharo-dev] Nautilus memory leak/hog crashing Pharo
by Goubier Thierry June 30, 2014

June 30, 2014

Le 27/06/2014 13:02, Goubier Thierry a Ã©crit : > Ok then, a simple profile should do it. Sort of, it doesn't show up that clearly. > I'll have a look. It seems to depend on the Nautilus window state. If you've just opened it, then nothing seems to be amiss. If you start to select things in it, you start to see time spent in updateClassView, but why? > I did profile loading Roassal2 with AltBrowser yesterday evening and > updates on the browser take 15% of the execution time... Will optimize > that. Went from 15% to 2~3% of Roassal2 loading time :) Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

4 9

[pharo-project/pharo-core] 706bfe: 40054
by GitHub June 30, 2014

June 30, 2014

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 706bfe3124647c874c0a9d3657a17eff50cc0075 https://github.com/pharo-project/pharo-core/commit/706bfe3124647c874c0a9d36… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-30 (Mon, 30 Jun 2014) Changed paths: R Nautilus.package/Nautilus.class/class/browser compatibility/openBrowser.st R Nautilus.package/Nautilus.class/class/browser compatibility/openBrowserView_label_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script54.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40054.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/Browser.class/class/instance creation/open.st R Tools.package/Browser.class/class/instance creation/openBrowser.st R Tools.package/ChangeList.class/class/instance creation/openAsMorph_name_multiSelect_.st M Tools.package/ChangeList.class/class/instance creation/open_name_multiSelect_.st M Tools.package/ChangeList.class/definition.st R Tools.package/ChangeList.class/instance/accessing/showsVersions.st R Tools.package/ChangeList.class/instance/filter streaming/selectAllConflicts.st M Tools.package/ChangeList.class/instance/initialization-release/openAsMorphName_multiSelect_.st M Tools.package/ChangeList.class/instance/initialization-release/optionalButtonRow.st R Tools.package/ChangeList.class/instance/initialization-release/wantsPrettyDiffOption.st A Tools.package/ChangeList.class/instance/menu actions/selectAllConflicts.st M Tools.package/ChangeList.class/instance/viewing access/contents.st M Tools.package/ChangeList.class/instance/viewing access/contents_.st R Tools.package/ChangeList.class/instance/viewing access/diffedVersionContents.st R Tools.package/ChangeList.class/instance/viewing access/restoreDeletedMethod.st Log Message: ----------- 40054 13436 delete empty packages Tabs and NewList https://pharo.fogbugz.com/f/cases/13436 13434 No need for #openBrowser https://pharo.fogbugz.com/f/cases/13434 13435 Clean ChangeList https://pharo.fogbugz.com/f/cases/13435 http://files.pharo.org/image/40/40054.zip

1 0

[pharo-project/pharo-core]
by GitHub June 30, 2014

June 30, 2014

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

1 0

Re: [Pharo-dev] Pharo and Amber relationship
by Stephan Eggermont June 30, 2014

June 30, 2014

Sean wrote: >Have you checked it out lately? The current procedure seems very streamlined... > ># Install the CLI tools (only needs to be done once per computer) >sudo npm install -g amber-cli Are you serious? That is like saying you can install Pharo by double-clicking a Pharo image. That misses a few steps. And there are several ways to install prerequisites, some of which don't work at all, others cannot be upgraded. Stephan

4 3

Supporting deep into pharo
by stepharo June 30, 2014

June 30, 2014

Hi! Maybe one of Deep into Pharoâs reader can write a review on: http://www.amazon.com/Deep-into-Pharo-Alexandre-Bergel/dp/3952334162 This will help everybody by promoting our favorite language... Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.

2 1

http://files.pharo.org/platform/Pharo3.0-win.zip looks like dead
by phil＠highoctane.be June 30, 2014

June 30, 2014

Not downloading.... Annoying, I wanted to demo Pharo to someone from scratch :-( Phil

3 4