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

Re: [Pharo-dev] Existing <script> <example> pragmas and new GT needs

by Tudor Girba

Hi Torsten, Thanks for the long email. The first part summarizes the situation reasonably well, except that you are putting the same pot <example> annotated methods and methods having example* selectors. To try to clear the water I thought I would answer with an almost equally long email :). I am not trying to redefine anything. We had the discussion about renaming the original <gtExample> into <example> some months ago and since then we only used <example> to mean what my description is: an initialized object. There are indeed many methods named example* that have a loose meaning that is different than the clearly defined <example> methods, but that does not mean that <example> was ever used for anything else than what my definition. In the Pharo image there are current 96 methods annotated with <example> or <example:>, and in fact, the only one method of these that does not preserve the meaning of <example> appeared in the recently integrated Athens version 3.1. This method executes a demo that requires a key press to end. So, who would you say is changing the meaning of an existing state of facts? :) Now, let's discuss why having an example concept defined as an "initialized object" is actually valuable. In order to run examples, you need the well initialized object. So, you can have: GLMBrick class>>exampleZindex <example: 'Example of z-index support in Brick'> ^ GLMBrick new ... and then GLMBrick class>>exampleZindexOpen " self exampleZindexOpen " self exampleZindex openInBrickWindowLabeled: 'Z-Index example' But, the interesting thing is that you can also use the example object for other purposes. For example, you can embed the object in a browser, or you can run automatic smoke tests. Specifically, given that GT proposes the idea of moldable tools that others can easily extend, it is also a challenge to test these extensions. Having examples for each of the extended classes makes this endeavor easily possible. And then we can also start considering the work on seeing tests as a whole as nothing but examples with assertions that depend on each other, but let's talk about that at another time. There is great value that comes from the simple and clearly defined concept of <example>. Btw, I think we should avoid talking about "for GT's purpose" because it sounds as if GT would be an alien that should be put in quarantine :) Cheers, Doru On Tue, Mar 24, 2015 at 8:56 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Tudor and all, > > to understand the issue one has to know: > > ------------------------------------------------------------------------------------------ > There are two pragmas in Pharo 4 that were already introduced and > integrated: > > <script> / <script:> - one can use this to mark methods (of any > signature) > as development scripts. One can use it on > instance side > and an class side methods to run the method > or some > code while developing without having to > leave the browser. > After completion Nautilus shows that the > method finished > > Think of a class "MyKillerProjectDatabase" > with a class > side method "start". > You can click this to run - but it does not > serve as an > example. A script is just "SOMETHING TO > RUN". The code > of the script may be too easy or to > complicated to serve > as an example. > > See also #14647, #14747 and #14995 for > details. > > <example> - Nautilus in the past already honored class > side exampleXXX > methods to have a "play" icon to easily > visually see examples > and just run them. > > With the <example> pragma one can > explicitly mark a method as > an example method and we do not have to > rely on the method name. > So we can use #tryThisOutForExample as > selector name as well now. > > It also allows to search for examples, > build an example browser > for newbees, ... > > An example shows the usage of a class or > code (usually to get > an initial idea). The pragma also only > works on class side methods. > > Think of existing classes like EditableList > or WidgetExamples > that provide example methods starting with > exampleXXX. > The user sees in the browser directly that > this is an example he > can run or look at to understand the > details because the author > offered it as "SOMETHING TO LEARN FROM". > > See also #14646 > and #15225 for details > > So (even only at the second look) there is a distinction between a > "script" and an "example". > Being a script does not automagically make a method an example. And yes: a > method can also > be both and both pragmas can be used. > > The history of these two is explained in > https://pharo.fogbugz.com/f/cases/15225/useless-play-icon-in-nautilus > and I already use this in several projects. > > > -------------------------------------------------------------------------------------------- > > Now it looks like Tudor is in need of a pragma for GT tools to provide > "example data". > > @Tudor: > I do not understand why you now abuse/try to redefine the meaning of this > existing <example> pragma > for your special purposes/needs or try to exchange one against the other > as in new issue #15229. > > According to your own comment in issue #15225 your definition of an > "example" is something > "to offer an initialized object that can be used for documentation or > testing purposes." > > I have to strongly disagree on this as this is ONLY TRUE FOR A FEW CASES. > Look at our image, look at > how people write example (methods): > > NOT ALL class side example methods necessarily return an initialized > objects but are still examples. > I already explained in the above issue that there are lots of example > methods that one just run > (either from the comment or from Nautilus icon) like > EditableListExampel(class)>>example, ... > They DO NOT return an initialized instance. > > Look at the "examples" in class WidgetExamples or others. None of them > provide an initialized instance! > > So the right definition for an "example" is: > "to offer runnable code that can be used for documentation or testing > purposes." > > > So PLEASE if you are in need of such a new thing where only initialized > instances are returned from > code then DO NOT REDEFINE existing and used pragmas like the integrated > <example> pragma. > > PLEASE use an OWN NEW PRAGMA for GT purposes like <exampleData>, > <exampleInstance>, <gtExampleInstance> > or whatever. I would also find an "exampleInstance" pragma name then more > intention revealing. > > Thanks a lot in in advance! > > Bye > T. > > > -- www.tudorgirba.com "Every thing has its own flow"

March 24, 2015

Re: [Pharo-dev] Some Memory Leak

by Andrei Chis

Hi Henry, Thanks for the feedback. Don't stop :) In this case I think the memory lead comes from the class variables of GLMHintableActionButtonBrick. Clearing them up removes all instances of playground and spotter from my image. We need to find a better design for that. Cheers, Andrei On Tue, Mar 24, 2015 at 9:38 PM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > A tiny bit of code review while I'm at it... > > GTSpotterResultsBrick >> initialize > super initialize > self band hSpaceFill. > self announcer weak subscribe: GLMBrickScrollPositionChanged send: > #onScrolled to: self > > This is a tempting, but sneaky anti-pattern, you should never, ever, ever > have to subscribe to your own announcer: > The reason for calling it an anti-pattern is; if your code actually depends > on this, it means other sources might invoke changes in you indirectly > through your announcer, which quickly becomes debugging hell if you allow > it, and something screws up. (I speak from experience) > > It's much easier to understand when done directly, in this case that means > extending the super method where announcement is made: > > GTSpotterResultsBrick >> privateScrollPosition:anInteger > super privateScrollPosition:anInteger. > self onScrolled > > Cheers, > Henry > > P.S. Announcements are objects, they are intended to hold the data > subscribers might be interested in. > Whenever you find yourself writing something like: > someAnnouncer announce: SomeAnnouncement new > ask yourself twice if that may lead to subscribers accessing state that > would more naturally be part of the announcement through other channels > (such as keeping extra instvars, etc). > > > > -- > View this message in context: > http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 24, 2015

Re: [Pharo-dev] Some Memory Leak

by Henrik Sperre Johansen

A tiny bit of code review while I'm at it... GTSpotterResultsBrick >> initialize super initialize self band hSpaceFill. self announcer weak subscribe: GLMBrickScrollPositionChanged send: #onScrolled to: self This is a tempting, but sneaky anti-pattern, you should never, ever, ever have to subscribe to your own announcer: The reason for calling it an anti-pattern is; if your code actually depends on this, it means other sources might invoke changes in you indirectly through your announcer, which quickly becomes debugging hell if you allow it, and something screws up. (I speak from experience) It's much easier to understand when done directly, in this case that means extending the super method where announcement is made: GTSpotterResultsBrick >> privateScrollPosition:anInteger super privateScrollPosition:anInteger. self onScrolled Cheers, Henry P.S. Announcements are objects, they are intended to hold the data subscribers might be interested in. Whenever you find yourself writing something like: someAnnouncer announce: SomeAnnouncement new ask yourself twice if that may lead to subscribers accessing state that would more naturally be part of the announcement through other channels (such as keeping extra instvars, etc). -- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814912.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 24, 2015

Re: [Pharo-dev] Glamour List Presentation get selection index

by Andrei Chis

Hi, No. Currently from a GLMListPresentation you can just get the selected element. Cheers, Andrei On Tue, Mar 24, 2015 at 7:40 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi, > > is it possible, to get selection index from GLMListPresentation? > > Cheers > Uko > >

March 24, 2015

Re: [Pharo-dev] Which one to use? [WAS: Re: GLMBrick whats next?]

by Alain Plantec

> > I donât get it sorry. > > Padding by ten pixels to the left: > > | leftMargin aParserButton | > leftMargin := Morph new > width: 10; > hResizing: #shrinkWrap; > vResizing: #spaceFill. > aParserButton := PluggableButtonMorph on: self getState: nil action: #parse. > aParserButton > hResizing: #spaceFill; > vResizing: #shrinkWrap; > label: 'Parse'. > AlignmentMorph newRow > vResizing: #shrinkWrap; > hResizing: #spaceFill; > layoutInset: 0; > addMorph: aParserButton; > addMorph: leftMargin; > openInWorld Regarding this example, AlignmentMorph is a submorph of Morph with a layout policy. you can do the same with bloc. No time now but i will implement this example in my doc. > > Mind you, I consider Bloc a very good choice, but I fear that we're not able to stress it enough with hard, very advanced GUIs to ensure we're not loosing power compared to Morphic. yes, there is a risk, this is why we should progress carefully and not too fast thanks Alain

March 24, 2015

Re: [Pharo-dev] Some Memory Leak

by Henrik Sperre Johansen

Along the lines of Nicolas' hint, here's one example of what you can *not* do, and expect to work (just the other way around): GLMPagerScrollBrick pagerModel: aModel pagerModel := aModel. -snip- pagerModel announcer weak when: GLMPagePushed send: #onPagePushed: to: self. -snip- In a workspace: pager:= GLMPagerModel new. brick := GLMPagerScrollBrick new. brick pagerModel: pager. brick := nil. Smalltalk garbageCollect. pager announcer subscriptions numberOfSubscriptions. --> 8 And, with a small addition of early exit after nilling pagerModel if aModel is nil: (pager announcer subscriptions instVarNamed: #subscriptions) anyOne subscriber pagerModel: nil. Smalltalk garbageCollect. pager announcer subscriptions numberOfSubscriptions. --> 0 In other words: You can NOT hold references to Announcers in an object that subscribes to it weakly. Cheers, Henry -- View this message in context: http://forum.world.st/Some-Memory-Leak-tp4814779p4814906.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

March 24, 2015

Existing <script> <example> pragmas and new GT needs

by Torsten Bergmann

Hi Tudor and all, to understand the issue one has to know: ------------------------------------------------------------------------------------------ There are two pragmas in Pharo 4 that were already introduced and integrated: <script> / <script:> - one can use this to mark methods (of any signature) as development scripts. One can use it on instance side and an class side methods to run the method or some code while developing without having to leave the browser. After completion Nautilus shows that the method finished Think of a class "MyKillerProjectDatabase" with a class side method "start". You can click this to run - but it does not serve as an example. A script is just "SOMETHING TO RUN". The code of the script may be too easy or to complicated to serve as an example. See also #14647, #14747 and #14995 for details. <example> - Nautilus in the past already honored class side exampleXXX methods to have a "play" icon to easily visually see examples and just run them. With the <example> pragma one can explicitly mark a method as an example method and we do not have to rely on the method name. So we can use #tryThisOutForExample as selector name as well now. It also allows to search for examples, build an example browser for newbees, ... An example shows the usage of a class or code (usually to get an initial idea). The pragma also only works on class side methods. Think of existing classes like EditableList or WidgetExamples that provide example methods starting with exampleXXX. The user sees in the browser directly that this is an example he can run or look at to understand the details because the author offered it as "SOMETHING TO LEARN FROM". See also #14646 and #15225 for details So (even only at the second look) there is a distinction between a "script" and an "example". Being a script does not automagically make a method an example. And yes: a method can also be both and both pragmas can be used. The history of these two is explained in https://pharo.fogbugz.com/f/cases/15225/useless-play-icon-in-nautilus and I already use this in several projects. -------------------------------------------------------------------------------------------- Now it looks like Tudor is in need of a pragma for GT tools to provide "example data". @Tudor: I do not understand why you now abuse/try to redefine the meaning of this existing <example> pragma for your special purposes/needs or try to exchange one against the other as in new issue #15229. According to your own comment in issue #15225 your definition of an "example" is something "to offer an initialized object that can be used for documentation or testing purposes." I have to strongly disagree on this as this is ONLY TRUE FOR A FEW CASES. Look at our image, look at how people write example (methods): NOT ALL class side example methods necessarily return an initialized objects but are still examples. I already explained in the above issue that there are lots of example methods that one just run (either from the comment or from Nautilus icon) like EditableListExampel(class)>>example, ... They DO NOT return an initialized instance. Look at the "examples" in class WidgetExamples or others. None of them provide an initialized instance! So the right definition for an "example" is: "to offer runnable code that can be used for documentation or testing purposes." So PLEASE if you are in need of such a new thing where only initialized instances are returned from code then DO NOT REDEFINE existing and used pragmas like the integrated <example> pragma. PLEASE use an OWN NEW PRAGMA for GT purposes like <exampleData>, <exampleInstance>, <gtExampleInstance> or whatever. I would also find an "exampleInstance" pragma name then more intention revealing. Thanks a lot in in advance! Bye T.

March 24, 2015

Fuel issue tracker now on github

by Max Leske

Hi folks Weâve moved the issue tracker from Google code to github: https://github.com/theseion/fuel/issues <https://github.com/theseion/fuel/issues>. Cheers, Max

March 24, 2015

Glamour List Presentation get selection index

by Yuriy Tymchuk

Hi, is it possible, to get selection index from GLMListPresentation? Cheers Uko

March 24, 2015

Re: [Pharo-dev] Some Memory Leak

by Nicolas Cellier

2015-03-24 17:22 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > > > On 24 Mar 2015, at 16:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > >> On 24 Mar 2015, at 16:50, Andrei Chis <chisvasileandrei(a)gmail.com> > wrote: > >> > >> There are lot of spotter objects that do not get garbaged collected > >> > >> GTSpotter allInstances size --> 29 in my image > > > > I got 10 now. > > > > But can they cause megabytes to be locked up ? > > If they work like Nautilus then thereâs a huge tree attached to every one, > with morphs, weak references, contextsâ¦ > I think there was (and maybe there still is) a problem with detection of > circular dependencies and weak references. If you register actions in the > EventManager (or whatever itâs called now) make sure that they are cleared. > > Then, there used to be a class variable somewhere that held on to the > single instance of some kind of work space factory (or some such thing) > which strongly holds on to stuff and prevents garbage collection. > > I donât know what has been cleaned by now but thereâs a lot of potential > for such thingsâ¦ > > I had to write some code a while ago to get rid of window instances that > wouldnât be garbage collected. Iâve attached the file outs, maybe someone > can use them (they are for Pharo 1.3 though, so maybe not of too much useâ¦) > > Cheers, > Max > > it sounds similar to http://lists.squeakfoundation.org/pipermail/beginners/2008-July/004731.html If we have some WeakKeyAssociation, but the same key is also used on the value side, then we never reclaim... But we wouldn't do that, would we? Well we did... http://bugs.squeak.org/view.php?id=7119 Nicolas > > > > > >> On Tue, Mar 24, 2015 at 4:16 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >> Yes, there are clearly objects lying around. I suspect it has to do > with Playground or Inspector, but I am not sure. > >> > >> Doru > >> > >> On Tue, Mar 24, 2015 at 4:13 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> > >>> On 24 Mar 2015, at 15:18, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> > >>> Hi, > >>> > >>> There seems to be some kind of memory leak in recent Pharo 4.0 images. > Image size (as saved on disk) seems to be growing very rapidly under normal > use (development with Nautilus, Spotter, GTPlayground, GTInspector and > Monticello, debugging). Numbers go from the initial 20Mb to 100s of Mb and > they seem to increase constantly, over a period of days. > >> > >> Are you saying that the static image size is growing? Dynamic growth > could easily be explained by leaks in NativeBoost for instance. But static > image size means that there are objects lying around that shouldnât (at > least that should be easier to debug). > >> > >>> > >>> One way to look at memory use is with > >>> > >>> SpaceTally printSpaceAnalysis > >>> > >>> but that takes a while. > >>> > >>> Please help us find and fix this issue. > >>> > >>> Thanks, > >>> > >>> Sven > >>> > >>> > >> > >> > >> > >> > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow" > >> > > > > > > >

March 24, 2015