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

Re: [Pharo-dev] Memory leaks

by Torsten Bergmann

Jan. 31, 2017

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

by Denis Kudriashov

2017-01-31 18:53 GMT+01:00 Stephan Eggermont <stephan(a)stack.nl>: > >> * white toolbar (according to theme background color) >> >> >> That doesn't work well. Don't mix styles like this, that is >> confusing. >> >> >> Why? It was by intention. Idea to make toolbar with same color as main >> table panels. And they have default background color >> > > - The whole window uses visible separation, except for the toolbar. > Ok. - It is unclear where the toolbar applies to > - The color and style of the radio buttons differs from other UI elements > - The color of the tabs and tab panel are incorrect, the inactive tabs > take away attention. I always said that UI needs much more work. But my question was to your "don't mix styles". Do you think it looks worse than before? I am not designer and would be very appreciate if somebody paint how it should be.

Jan. 31, 2017

Re: [Pharo-dev] Memory leaks

by Alexandre Bergel

Hi John, Your tool is truly a gem! Yesterday I spent a couple of hours using #pointersTo to track some Roassal objects. But I was unsuccessful. Your tool help me immediately spot kept references. In particular, the following invocation frees all the Roassal and Athens surface objects: Clipboard startUp: true. GTPlayBook reset. RubEditingState allInstances do: [ :i | i undoManager reset. ]. CairoBackendCache soleInstance flush Should be included in the image. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jan 31, 2017, at 1:00 AM, John Brant <brant(a)refactoryworkers.com> wrote: > >> On Jan 30, 2017, at 3:57 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> >> The problem is still present. >> Looking at the pointers >> >> There was an object reference crawler no? I remember someone worked on this? I tried sending #pointersTo but I without much success on identifying the cause of this leak. >> >> Any idea? >> > > I donât know if there is an existing object reference crawler, but I ported mine from VW. It finds the shortest paths so it is good for finding the reference that is causing the memory leak. > > MCHttpRepository > location: 'http://www.smalltalkhub.com/mc/JohnBrant/ReferenceFinder/main' > user: '' > password: ââ > > Once loaded, you can evaluate something like "ReferenceFinder findPathToInstanceOf: MyClassâ. That will return a reference path or nil if no path exists from the Smalltalk global to an instance of MyClass. If you want to find a path to a particular instance, you can use âReferenceFinder findPathTo: myInstâ. > > In the past, Iâve found that NECController and some compiler infrastructure (I forget the class) have been culprits for memory leaks with their caches. > > > John Brant

Jan. 31, 2017

Re: [Pharo-dev] [Ann] Calypso update: method browser and better UI

by Stephan Eggermont

On 31/01/17 14:45, Denis Kudriashov wrote: > > 2017-01-31 1:20 GMT+01:00 Stephan Eggermont > <stephan(a)stack.nl > <mailto:stephan@stack.nl>>: > > Nice! > > * white toolbar (according to theme background color) > > > That doesn't work well. Don't mix styles like this, that is > confusing. > > > Why? It was by intention. Idea to make toolbar with same color as main > table panels. And they have default background color - The whole window uses visible separation, except for the toolbar. - It is unclear where the toolbar applies to - The color and style of the radio buttons differs from other UI elements - The color of the tabs and tab panel are incorrect, the inactive tabs take away attention. Stephan

Jan. 31, 2017

Re: [Pharo-dev] Strange behaviour of GTInspector

by Nicolai Hess

2017-01-31 17:05 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > Hi. > > It seams that click on cell with value of variable in GTInspector > activates selection only when mouse moves. It feels like slow selection. > It not happens when cell with name is clicked. > > Try inspect 10@30 and select 10 or 30 to see the problem. > Yes, see 17578 <https://pharo.fogbugz.com/f/cases/17578/GTInspector-recognizes-a-mouse-clic…> GTInspector recognizes a mouse click only after moving the mouse

Jan. 31, 2017

Re: [Pharo-dev] Strange behaviour of GTInspector

by Andrei Chis

Nice bug :) Most likely comes from GLMTreeMorphNodeModel>>#rowMorphForColumn: and GLMEditableLabelBrick. Right now GLMEditableLabelBrick uses an alarm to detect if the user double clicked on the column. Seems that the alarm is not triggered if the mouse does not move. Andrei On Tue, Jan 31, 2017 at 5:05 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > It seams that click on cell with value of variable in GTInspector > activates selection only when mouse moves. It feels like slow selection. > It not happens when cell with name is clicked. > > Try inspect 10@30 and select 10 or 30 to see the problem. >

Jan. 31, 2017

Strange behaviour of GTInspector

by Denis Kudriashov

Hi. It seams that click on cell with value of variable in GTInspector activates selection only when mouse moves. It feels like slow selection. It not happens when cell with name is clicked. Try inspect 10@30 and select 10 or 30 to see the problem.

Jan. 31, 2017

Added Event for: Pharo Sprint March 3

by denker

Hi, The next Pharo Sprint will be March 3. https://association.pharo.org/event-2451866 <https://association.pharo.org/event-2451866> Infos can be update (e.g. if people organise other face-to-face meetings). Marcus

Jan. 31, 2017

Fwd: PharoDays: Possible dates

by Marcus Denker

Hi, I have updated the poll with some dates in May. If you can not come at any date but would be interested in general, please respond with the âcan not make itâ option. Marcus > Hello, > > First for the board only: We checked with Stef what dates would make sense > The best here is April, either before or after school holidays. > > I made a doodle: > > > http://doodle.com/poll/f8n5zhv7p8fqwyih <http://doodle.com/poll/f8n5zhv7p8fqwyih> > > > if this looks ok I would send it around to get an impression what people think. > > Marcus

Jan. 31, 2017

Re: [Pharo-dev] Memory leaks

by John Brant

On 01/31/2017 06:45 AM, stepharong wrote: > thierry > > we have pointersTo and I imagine that it is not good enough. > Do you confirm? #pointersTo appears to be the same as #allReferences and #allOwners in other Smalltalk implementations. These methods are terrible for finding the reason for the memory leak. To find the root of the problem, you start with some object you think should have been GCed. The #pointersTo gives you which objects reference that object. Then you iterate picking some object in the previous pointersTo list and asking for its pointersTo until you get to the class variable or class instance variable that is the real root of the problem. The difficulty with this process is "picking some object" from the pointersTo list to do another pointersTo. You may pick an object that is part of the inspectors that you are using. Another common problem is picking an object that you have already seen (cycles). I don't know about the Pharo implementation, but some of the other implementations also have a problem of having implementation objects showing in the pointersTo list (i.e., objects that were created by the pointersTo process). As for the ease of use, I have an image where I just closed my work window, and see that I still have some PBVariableNodes laying around. If I execute "PBVariableNode allInstances first pointersTo" I get an array with 2 items. The first is an array with 4 items and the second is an array with 11587 items. Now, I would need to pick which of these I would need to do pointersTo. If I use my ReferenceFinder, I can do "ReferenceFinder findPathTo: PBVariableNode allInstances first" or even "ReferenceFinder findPathToInstanceOf: PBVariableNode". This will give me an array where the first object is the Smalltalk system dictionary and the last object is a PBVariableNode. In my case, I see a reference path goes through the ASTCache. That object is holding on, somewhat indirectly, to my anonymous class that is no longer being held by anything else. Therefore, I concluded that either the ASTCache needs to be changed so that it no longer caches items for anonymous classes, or I need to change my code to remove all methods from the anonymous class before exiting (since the ASTCache uses a weak key cache on the compiled method). BTW, the reference path also shows that it would have been wise to pick the array of 11587 items to do the pointersTo analysis on above. John Brant

Jan. 31, 2017