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

Re: [Pharo-dev] Making Seaside work in Pharo 4

by Luc Fabresse

2015-03-26 15:16 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 26 Mar 2015, at 15:12, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > > > 2015-03-26 12:04 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > >> Marcus Denker-4 wrote >> > It was in the âprivateâ category and as such removed when there where no >> > senders anymore after a >> > cleanup. >> >> Ahh, I like that practice! >> > > I was thinking that the deprecation pragma should be used (to warn users) > and a lint rule added (to help users preparing migration) and then the > method can be safely removed in the next version. > I know that it is fastidious to do so perhaps it is an idea to improve > tools on that front. > > > The problem is that it is hard to do when the code changes a lot. e.g. > maybe the method even makes no sense conceptually anymore? Private methods > are about private implementation detailsâ¦. keeping a system working with > deprecation for private methods I think is near impossible. > ah now I understand. you mean that the method was private *initially*. ok, I wrongly understood that you moved the method in the "private" protocol to signal that it will be removed in the next release. So ok you are right, private methods can change and external should not rely on it. Luc > > Marcus > >

March 26, 2015

Re: [Pharo-dev] collecting Pharo 4.0 Contributors

by Damien Cassou

Damien Cassou <damien.cassou(a)gmail.com> writes: > I pair programmed with Jean-Christophe Bach on a few bug fixes. but Jean-Christophe Bach is not :-) -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

March 26, 2015

Re: [Pharo-dev] Making Seaside work in Pharo 4

by Marcus Denker

> On 26 Mar 2015, at 15:12, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > > > 2015-03-26 12:04 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com>>: > Marcus Denker-4 wrote > > It was in the âprivateâ category and as such removed when there where no > > senders anymore after a > > cleanup. > > Ahh, I like that practice! > > I was thinking that the deprecation pragma should be used (to warn users) and a lint rule added (to help users preparing migration) and then the method can be safely removed in the next version. > I know that it is fastidious to do so perhaps it is an idea to improve tools on that front. > The problem is that it is hard to do when the code changes a lot. e.g. maybe the method even makes no sense conceptually anymore? Private methods are about private implementation detailsâ¦. keeping a system working with deprecation for private methods I think is near impossible. Marcus

March 26, 2015

Re: [Pharo-dev] Making Seaside work in Pharo 4

by Luc Fabresse

2015-03-26 12:04 GMT+01:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Marcus Denker-4 wrote > > It was in the âprivateâ category and as such removed when there where no > > senders anymore after a > > cleanup. > > Ahh, I like that practice! > I was thinking that the deprecation pragma should be used (to warn users) and a lint rule added (to help users preparing migration) and then the method can be safely removed in the next version. I know that it is fastidious to do so perhaps it is an idea to improve tools on that front. Luc > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Making-Seaside-work-in-Pharo-4-tp4814663p4815270.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

March 26, 2015

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

by Ben Coman

On Thu, Mar 26, 2015 at 12:35 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > "Ben Coman" wrote > >The word that I feel best applies to Doru's need is <sample>, to return a > fully initialised sample instance that you can play with in the > >Inspector. When you double-click a method so tagged you can think of it > as "give me a sample" of yourself. > > What would you think of "exemplar" and "give me an examplar of yourself"? > > I missed responding directly to this. Sorry, that just sounds wrong. :) "Give me an example of yourself" is better, and "give me a sample of yourself" better again. cheers -ben

March 26, 2015

Re: [Pharo-dev] could the size of Playground be reduced a bit

by Johan Fabry

Excellent solution, thanks! > On Mar 25, 2015, at 20:47, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > In the latest GT-Playground and GT-Inspector you get the following behavior: > - you can resize the windows, and the windows spawned afterwards will remember the dimensions, or > - you can explicitly specify the size you prefer in the settings browser. > > https://pharo.fogbugz.com/f/cases/14541/Editing-the-default-inspector-windo… <https://pharo.fogbugz.com/f/cases/14541/Editing-the-default-inspector-windo…> > > Cheers, > Doru > > > On Wed, Mar 25, 2015 at 11:43 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> wrote: > oh resizing is already mandatory I am afraid. When the object inspected is big, there is no other option but to resize the whole window. And many if not most useful Pharo objects worth inspecting are big. > I rarely have to resize it (arguably I'm not using to full potential); but my point was that there should be sensible defaults for both primary (most common) use cases. You can never satisfy everyone 100%. > > Plus resizing windows is part of the experience of using a window GUI system. > As a long time user of dwm the very idea of resizing windows with mouse is repulsive to me. (I still struggle in this respect with Pharo... but I have a dream. :)) > > Peter > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow" ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile

March 26, 2015

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

by Tudor Girba

Hi, I/we do not want to impose anything on anyone. <gtExample> was introduced a long time (more than 1 year) ago in GT/Moose. It is used both for documentation purposes and for generic stress tests for the Inspector and Spotter (and let's not even count that the concept offers an alternative to SUnit testing that we will pursue in the near future). It got integrated in Pharo and then renamed to <example> 6 months ago (in October) after a public discussion on this mailing list. It later got mixed with the example* selectors as part of #isExampleMethod and used in Nautilus with a looser interpretation to essentially trigger the example. This debate started 7 days before the release. The reason why the debate started is that exactly one method started to use it differently than all other <example> methods from the Pharo image. While this debate fired on, GT does not build and cannot be integrated, even though in parallel we work like mad to meet the deadline and fix all issues that are being reported. And the way the debate took place is also borderline for my taste, too. I do not appreciate being shout at. I am not mad, but please do not expect me to be happy either. I also find it discouraging that people talk about GT as if it would not be Pharo or as if we would want to force people to do things. We are indeed a standalone team with an own set of ideas, but we do not want to force our work on anyone. As the decision was to make GT a central part of Pharo, we kindly ask you to treat us as part of Pharo. We never shied away from debates and listening to people. In fact, we think we are going over the board with actively listening and reacting. We can still debate the <example>, but not now. We have a release to meet. We can talk about it afterwards. But, for this to happen, I also kindly ask you to remove the <example> check from #isExampleMethod. This would allow us to start from a clean slate in Pharo 5. Cheers, Doru On Thu, Mar 26, 2015 at 12:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Okâ¦ my 2c: > > Basically there is a difference between an âexampleâ and a prototype, > which is what the gtExample intends to do. Exemplar is just another way to > name a prototype. > Sorry to make you sad and tiredâ¦ but when you introduce such an important > new tool as all the gtools are, you cannot expect people to accept all your > choices âas isââ¦ and debate is the only way to achieve some consensus. > > Esteban > > ps: we are just days from release and we are all stressed a lotâ¦ so lets > take a breath and consider things with the appropriate distance. We are not > talking about the cure for cancer here, just the right name for a pragma, > in a method. > > > On 26 Mar 2015, at 10:02, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Hi Tudor, > > > >> We will rename <example> back to <gtExample> and keep the API as it is. > That will leave Pharo 4 with one <example> method while the other 100 will > >use <gtExample>. This will be available with the next GT integration. > > > > As I already wrote (and Guillermo equally pointed out): most of them are > there because you created/introduced many extension > > methods with GT to provide these sample instances like in $a for > Charater or 42 for Integer, ... > > Which is completely valid to demonstrate how usefull your new extension > is. But it is because you investigated so far more to > > demonstrate this new mechanism. > > > > > > And yes, currently we have just one <example> in the image (beside some > other in external projects). But if we do not > > want to rely on the exampleXXX pattern anymore we will mark the typical > example methods with <example> in the future and would > > have around 140 in the latest image: > > > > |coll| > > coll := IdentitySet new. > > Object withAllSubclassesDo: [:aClass | > > aClass class selectorsDo: [:selector | > > (selector beginsWith: 'example') ifTrue: [ coll add: selector > ] > > ]]. > > ^coll > > > > If we dont mark them I agree that there are only a few counterwise. > > > > But again: from my side it is not about the current numbers. It is about > the future mechanism, clear and > > understandable concepts and naming. > > > > The usualy exampleXXX demos for code fits well with <example> from the > name and mentally. "Example" > > is a very generous term for something to look at and learn. > > > > In Pharo one can now demonstrate in the new GT inspector lively ready > made instances! > > You feature and the research bound to it is not only important but a > real improvement. > > I like that and I'm sure this will push us forward a lot. > > > > Still IMHO mentally using <example> for depicting "code to look at" does > fit namewise and > > conceptualy very well with the known and usual example methods in the > image or external > > packages. Some of them provide an instance, but many of them just show > how to use code. > > > > And yes: I would the new GT mechanism to use a term and pragma name that > better depicts > > what should be provided from the one who uses it: typical example > instances or exemplars > > of the class. > > > > When one creates a class > > > > Object subclass: #RevolutionarySystem > > instanceVariableNames: 'name' > > classVariableNames: '' > > category: 'The-World' > > > > he can implement a class side method to use the new mechanism: > > > > uniqueExemplar > > <exemplar> > > > > ^RevolutionarySystem called: 'Pharo' > > > > And this class side method returns an exemplary instance. If such a > method should > > also serves as an example method (in the tradition of a code example to > look at) > > one can even mark it with both pragmas. > > > >> The decision has nothing to do with arguments. > > > > Why do you negotiate instead of (at a minimum) ellaborate what you think > of the made > > proposal to use "exemplar" for the new GT mechanism. > > > > See the definition for <exemplar>: > > > > http://dictionary.reference.com/browse/exemplar > > "a model or pattern to be copied or imitated" > > "a typical example or instance" > > > > http://www.thefreedictionary.com/exemplar > > "One that is worthy of imitation; a perfect example or model" > > "One that is typical or representative" > > > > http://www.merriam-webster.com/dictionary/exemplar > > "an admired person or thing that is considered an example that > deserves to be copied" > > "a typical example" > > > > http://www.ldoceonline.com/dictionary/exemplar > > "formal a good or typical example" > > > > http://www.dict.cc/?s=exemplar > > "instance" > > "specimen" > > "sample" > > > > All the 100 instances now returns by GT extension are such exemplars: > they are > > typical instances like $a or 42 one can use as a model or pattern to be > copied > > or imitated. > > > > Would'nt that perfectly fit with what you intended with your new > feature: the preview > > should help people to just inspect a class, look at the new "e.g." tab > and learn from > > premade instances? > > > >> The release is too important and we got distracted from the goal. > > > > No doubt that the release is important and fixing it NOW from the > technical side is easy > > as I demonstrated with the changeset. I guess rolling back <gtExample> > would take you > > more time than reviewing it. > > > > Before doing any action on your side I would really like to know your > opinion about > > <exemplar>. I'm fine when you can not accept it - but please tell me > about the reasons. > > > > Bye > > T. > > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

March 26, 2015

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

by Ben Coman

On Thu, Mar 26, 2015 at 9:19 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Wed, Mar 25, 2015 at 9:33 PM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >> - Modeling Examples to Test and Understand Software, Markus Gaelli, PhD >> Thesis, 2006 >> http://scg.unibe.ch/archive/phd/gaelli-phd.pdf >> > >> - JExample: Exploiting Dependencies Between Tests to Improve Defect >> Localization, Kuhn etal, 2008 >> http://scg.unibe.ch/archive/papers/Kuhn08aJExample.pdf >> > (Phexample is also available on SmalltalkHub) >> > > > In spite of the first using "example" as a metaphor and the second using > "example" in its name, these are references are about composable tests, not > examples. While a test can serve as an example, a test is a different > concept than an "Example". So yes, its a great idea to explicitly define > dependencies between tests by them returning instances to be used by other > tests, but there are plenty of examples that do not follow that pattern, > nor should all examples be forced to follow that pattern, nor should they > be force to be tagged something other than an <example>. > > Language is a funny thing. Dictionaries tend to list all "possible" > meanings and don't necessarily indicate which are the more common usage. > The supporters of "exemplar" seems to have a German background, and maybe > the German word "exemplar" is an exact match, but it seems the meaning has > evolved since English imported it. As a native english speaker, to me > "exemplar" has an immediate sense of being too exotic for the purpose, and > also more a meaning of "the BEST example/instance of..." - which I think > overstates the purpose here. > > I have marked the more common meanings and underlined significant words in > the the supplied dictionary meanings... > > On Thu, Mar 26, 2015 at 5:02 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > >> what you think of the made proposal to use "exemplar" for the new GT >> mechanism. >> >> See the definition for <exemplar>: >> >> http://www.thefreedictionary.com/exemplar >> more this --> "One that is _worthy_ of imitation; a _perfect_ example >> or model" >> less this --> "One that is typical or representative" > > >> http://www.merriam-webster.com/dictionary/exemplar >> more this --> "an _admired_ person or thing that is considered an >> example that _deserves_ to be copied" >> less this --> "a typical example" >> >> http://www.dict.cc/?s=exemplar >> "instance" >> "specimen" >> "sample" >> > > > Note that the german-english dictionary also proposes "sample", which to > me seems the most suitable for the intent of returning an item for > inspection... > > http://www.merriam-webster.com/dictionary/sample > "a representative part or a single item from a larger whole or group > especially _when-presented-for-inspection_ or shown as evidence of quality > : specimen" > http://www.thefreedictionary.com/sample "A specimen taken for analysis or testing" Sorry I also meant to add, that specimen could also work... http://www.thefreedictionary.com/specimen "An individual, item, or part representative of a class or whole." http://www.merriam-webster.com/dictionary/specimen "Something (such as an animal or plant) collected as an example of a particular kind of thing ; a small amount or piece of something that can be tested or examined" ...but that I liked <sample> since it rhymes with <example> (Together these would be ample for a needs - daboomboom!) cheers -ben

March 26, 2015

Re: [Pharo-dev] Some Memory Leak

by Sven Van Caekenberghe

Wow! > On 26 Mar 2015, at 14:24, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > Now, with Alain's help, also the memory leak from Rubric is solved. > All fixes will be in the next version, which will hopefully be ready today. > > Cheers, > Andrei > > On Wed, Mar 25, 2015 at 7:05 PM, stepharo <stepharo(a)free.fr> wrote: > +1 > > > Le 25/3/15 11:52, Sven Van Caekenberghe a Ã©crit : > > YES! > > My image went from 65Mb to 34Mb (it contains Seaside/Bootstrap and several resources). > > Thanks a lot, you guys (and everybody else who contributes) rock! > > Let's hope this solves the issue. > > On 25 Mar 2015, at 11:26, Andrei Chis <chisvasileandrei(a)gmail.com> wrote: > > To load the latest version in an image execute: > > { { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }. > { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. > { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. > { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. > { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. > { 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }. > } do: [ :spec | > Gofer new > smalltalkhubUser: spec second project: spec third; > package: spec first; > load ]. > ConfigurationOfGToolkitCore loadDevelopment. > > Then run cleanUp: > > Smalltalk cleanUp: true except: #() confirming: false. > > Now only the latest instance of playground/spotter is not garbaged collected, but that would be fixed very soon. > > > Cheers, > Andrei > > > > > On Wed, Mar 25, 2015 at 11:21 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Please tell us when this gets integrated so that we can test the effect. > > Or to go faster, please give some instructions (an executable expression) that we can execute in the latest image to load the relevant changes. > > We need more eyeballs. > > On 25 Mar 2015, at 09:50, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Up to now, we identified two issues that lead to objects not being garbage collected: > > - GLMHintableActionButtonBrick triggers a singleton asynctask that was not cleaned after the task was ready. Now, that problem should be solved in GT. > > - RubFindReplaceService has a Singleton class variable. At the same time, RubFindReplaceService also keeps a reference to the textArea which is part of the morph tree and will prevent the whole UI that includes it to be garbage collected. We are working on dealing with this issue. > > There might be other issues. We need to keep looking. > > Cheers, > Doru > > > > On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo(a)free.fr> wrote: > Hi henrik > > your analyses are great. > What do you think about > > GTSpotterStep>>#candidates > > ^ candidates ifNil: [ > candidates := GTSpotterCandidatesList new. > candidates announcer weak subscribe: GTSpotterCandidateAdded do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. > candidates announcer weak subscribe: GTSpotterAllCandidatesAdded do: [ self selectFirst ]. > candidates announcer weak subscribe: GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. > candidates ] > > Le 24/3/15 21:38, Henrik Sperre Johansen a Ã©crit : > > 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. > > > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > > > > >

March 26, 2015

Re: [Pharo-dev] Some Memory Leak

by Andrei Chis

Now, with Alain's help, also the memory leak from Rubric is solved. All fixes will be in the next version, which will hopefully be ready today. Cheers, Andrei On Wed, Mar 25, 2015 at 7:05 PM, stepharo <stepharo(a)free.fr> wrote: > +1 > > > Le 25/3/15 11:52, Sven Van Caekenberghe a Ã©crit : > > YES! >> >> My image went from 65Mb to 34Mb (it contains Seaside/Bootstrap and >> several resources). >> >> Thanks a lot, you guys (and everybody else who contributes) rock! >> >> Let's hope this solves the issue. >> >> On 25 Mar 2015, at 11:26, Andrei Chis <chisvasileandrei(a)gmail.com> >>> wrote: >>> >>> To load the latest version in an image execute: >>> >>> { { 'ConfigurationOfRubric'. 'AlainPlantec'. 'Rubric' }. >>> { 'ConfigurationOfGlamourCore'. 'Moose'. 'Glamour' }. >>> { 'ConfigurationOfGTInspectorCore'. 'Moose'. 'GToolkit' }. >>> { 'ConfigurationOfGTPlaygroundCore'. 'Moose'. 'GToolkit' }. >>> { 'ConfigurationOfGTSpotter'. 'Moose'. 'GToolkit' }. >>> { 'ConfigurationOfGToolkitCore'. 'Moose'. 'GToolkit' }. >>> } do: [ :spec | >>> Gofer new >>> smalltalkhubUser: spec second project: spec third; >>> package: spec first; >>> load ]. >>> ConfigurationOfGToolkitCore loadDevelopment. >>> >>> Then run cleanUp: >>> >>> Smalltalk cleanUp: true except: #() confirming: false. >>> >>> Now only the latest instance of playground/spotter is not garbaged >>> collected, but that would be fixed very soon. >>> >>> >>> Cheers, >>> Andrei >>> >>> >>> >>> >>> On Wed, Mar 25, 2015 at 11:21 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >>> wrote: >>> Please tell us when this gets integrated so that we can test the effect. >>> >>> Or to go faster, please give some instructions (an executable >>> expression) that we can execute in the latest image to load the relevant >>> changes. >>> >>> We need more eyeballs. >>> >>> On 25 Mar 2015, at 09:50, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>> >>>> Up to now, we identified two issues that lead to objects not being >>>> garbage collected: >>>> >>>> - GLMHintableActionButtonBrick triggers a singleton asynctask that was >>>> not cleaned after the task was ready. Now, that problem should be solved in >>>> GT. >>>> >>>> - RubFindReplaceService has a Singleton class variable. At the same >>>> time, RubFindReplaceService also keeps a reference to the textArea which is >>>> part of the morph tree and will prevent the whole UI that includes it to be >>>> garbage collected. We are working on dealing with this issue. >>>> >>>> There might be other issues. We need to keep looking. >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>> >>>> On Wed, Mar 25, 2015 at 8:52 AM, stepharo <stepharo(a)free.fr> wrote: >>>> Hi henrik >>>> >>>> your analyses are great. >>>> What do you think about >>>> >>>> GTSpotterStep>>#candidates >>>> >>>> ^ candidates ifNil: [ >>>> candidates := GTSpotterCandidatesList new. >>>> candidates announcer weak subscribe: GTSpotterCandidateAdded >>>> do: [ self candidates hasOnlyOneItem ifTrue: [ self selectFirst ] ]. >>>> candidates announcer weak subscribe: >>>> GTSpotterAllCandidatesAdded do: [ self selectFirst ]. >>>> candidates announcer weak subscribe: >>>> GTSpotterAllCandidatesRemoved do: [ self selected: nil ]. >>>> candidates ] >>>> >>>> Le 24/3/15 21:38, Henrik Sperre Johansen a Ã©crit : >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >>> >> >> > >

March 26, 2015