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

Integration Problem

by Sean P. DeNigris

I followed the video directions to try and integrate a fix. Unfortunately, my startup script class got included in the update and broke the Jenkins build (which can't find the mcz). What do I do now? ----- Cheers, Sean -- View this message in context: http://forum.world.st/Integration-Problem-tp4739543.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 27, 2014

Re: [Pharo-dev] Null Object Pattern

by Sean P. DeNigris

On Jan 24, 2014, at 3:14 PM, Carlo-2 [via Smalltalk] <ml-node+s1294792n4739153h31(a)n4.nabble.com> wrote: > 3. Created a class NullWorld and overrode the #ifNil:ifNotNil Thanks! I'll check that out :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Null-Object-Pattern-tp4738574p4739535.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 27, 2014

Re: [Pharo-dev] Two videos to explain what we do when integrating a fix.

by Sean P. DeNigris

Pharo4Stef wrote > Should put them on youtbue but I dod not how. I'm still having problems viewing the second one. Will you host it somewhere else pleeeeease? I want to learn!!! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Two-videos-to-explain-what-we-do-when-integrating-a-f… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 27, 2014

Re: [Pharo-dev] Roassal Visualization for control flow graph issues

by Alexandre Bergel

Oups, you need to remove "edges: v elementsAsEdgeâ in the script. Similar code using Roassal2, with bezier curves Cheers, Alexandre On Jan 26, 2014, at 11:17 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Sorry about the delay in my answer. > I am not sure to understand. You can specify any edged to drive a layout. Simply send #userDefinedEdges: to a layout. Here an example: > <Screen Shot 2014-01-26 at 11.15.41 PM.png> > > Circle = classes, size = number of methods; gray links = inheritance; blue links = dependencies; layout = force based layout on the inheritance links > > The force layout is driven by the inheritance links only. Dependencies links are not considered by the layout. > -=-=-=-=-=-=-=-=-=-=-=-=-=-= > | v inheritanceEdges shape | > v := ROView new. > shape := ROEllipse new color: (Color red alpha: 0.4); size: [ :e | e model numberOfMethods / 5 max: 5]. > v addAll: (shape elementsOn: Collection withAllSubclasses). > > "Defining edges from inheritance" > inheritanceEdges := > ROEdge buildEdgesFromObjects: Collection withAllSubclasses from: #superclass to: #yourself inView: v. > > "Defining edges from dependencies" > Collection withAllSubclasses do: [ :cls | > cls methods do: [ :cm | > ((cm literals select: [ :l | l class == Association and: [ l value notNil ] ]) collect: #value) do: [ :depClass | (cls ~~ depClass and: [ Collection withAllSubclasses includes: depClass ]) ifTrue: [ > > ROEdge buildEdgesFromAssociations: { cls -> depClass } using: (ROLine new color: (Color blue alpha: 0.1)) inView: v ] ] ] > ]. > > > "Layout the whole thing" > ROForceBasedLayout new > userDefinedEdges: inheritanceEdges; > on: v elementsNotEdge edges: v elementsAsEdge. > > "Open the view" > v open > -=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Cheers, > Alexandre > > > On Jan 15, 2014, at 11:32 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > >> Alex, >> >> I remember to have talked to Mathieu about the making layouts ignore some edges when drawing visualizations and I think he gave it a try as well. I think that can be helpful in Clement's case (back jumps are ignored in the layout). >> Do you remember to have integrated something in Roassal on these lines from Mathieu's work? >> >> Usman >> >> >> On Tue, Jan 14, 2014 at 6:20 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> Hi ClÃ©ment, >> >> Thanks for your nice words. >> Layouts provided by Roassal are well known generic algorithm. Creating a new layout is not complicated at all. Just subclass ROLayout and override the hook methods. Creating a layout for your need is not easy. Have you tried to google for a layout? If you find one, it should be rather easy to implement it. >> >> Alexandre >> >> >> On Jan 14, 2014, at 12:50 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >> >> > Hello Roassal developers, >> > >> > A few time ago Usman Bhatti showed me Roassal. Today I decided to use it for my daily work on a project that aims to optimize Pharo's methods. >> > >> > Firstly I am quite impressed by the quality of Roassal, I am currently using the Roassal + Mondrian builder and I have a visual representation which is very close to what I want after 1 hour of work with the help of Usman. Good job guys. >> > >> > Here are 2 examples of what I use: >> > >> > exampleIfTrueIfFalse2 >> > | a b | >> > a := true. >> > a >> > ifTrue: [ >> > false ifTrue: [ ^ b := 1 ] ifFalse: [ b := 2 ] ] >> > ifFalse: [ >> > true ifTrue: [ b := 4 ] ifFalse: [ b := 5 ] ]. >> > ^ b >> > >> > <Screen Shot 2014-01-14 at 4.14.49 PM.png> >> > >> > Here there's one rectangle for each basic block, entrance/exits are basic blocks with bigger borders, and borders in red represents the "hot path", which the path the execution flow most frequently uses (based on native code counters added at some spots in the method by Cogit). >> > >> > Another example: >> > >> > exampleToDo >> > >> > 1 to: 10 do: [ :i | >> > self kick: i ] >> > >> > <Screen Shot 2014-01-14 at 4.36.47 PM.png> >> > >> > Now I have a few issues with the layout. I am currently using the narrowTreeLayout which seems to be the best for my visualisation. >> > >> > issue 1: When branches merges, which is in a tree when a node has 2 or more parents, or when I have a #ifTrue:ifFalse:, the child is not well aligned horizontally. Here in the first visualisation I showed, BasicBlock 5 is below but not in the middle of Basic block 8,7 and 4 (horizontally). I put a minimal width for each basic block to make it better but it's still not perfect. >> > issue 2: (most important issue) I cannot display back jumps because then all the graph is missdrawn, therefore I need to remember where they are instead of visualizing them all the time (I cannot display the back jump from basic block 3 to basic block 2 in the second representation. In addition, the back jump edge, when well displayed, overlaps the basic blocks visualizations. >> > >> > Here is an example of what I would like for the edges and basic block positions: >> > >> > <Screen Shot 2014-01-14 at 4.27.32 PM.png> >> > >> > As you can see, here exit is in the middle of B2 and B5 horizontally, which is not the case in my roassal visualization. >> > In addition, there's a back jump from B6 to B4 that I cannot display (or all the visual representation goes nuts). The edge for the back jump does not overlap with the basic blocks. In this graph, arrows follow a grid. I don't care that arrows are diagonals instead of a mix of horizontal and vertical lines but I would like to be able to see nicely the back jumps as in this graph. >> > >> > Do you have an idea on what layout/view options I could use with Roassal +Mondrian to have a better result ? >> > >> > I tried to create my own layout but after 2 hours I understood this cost too much time for my planning (or perhaps I'm just too dumb to do it fast :-( ). >> > >> > Anyway, the representation I have now is good enough for me to use it. But a better one would be better, especially for back jumps :-). >> > >> > Thanks for any help. >> > >> > Clement >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 27, 2014

Re: [Pharo-dev] Roassal Visualization for control flow graph issues

by Alexandre Bergel

Hi! Sorry about the delay in my answer. I am not sure to understand. You can specify any edged to drive a layout. Simply send #userDefinedEdges: to a layout. Here an example: Circle = classes, size = number of methods; gray links = inheritance; blue links = dependencies; layout = force based layout on the inheritance links The force layout is driven by the inheritance links only. Dependencies links are not considered by the layout. -=-=-=-=-=-=-=-=-=-=-=-=-=-= | v inheritanceEdges shape | v := ROView new. shape := ROEllipse new color: (Color red alpha: 0.4); size: [ :e | e model numberOfMethods / 5 max: 5]. v addAll: (shape elementsOn: Collection withAllSubclasses). "Defining edges from inheritance" inheritanceEdges := ROEdge buildEdgesFromObjects: Collection withAllSubclasses from: #superclass to: #yourself inView: v. "Defining edges from dependencies" Collection withAllSubclasses do: [ :cls | cls methods do: [ :cm | ((cm literals select: [ :l | l class == Association and: [ l value notNil ] ]) collect: #value) do: [ :depClass | (cls ~~ depClass and: [ Collection withAllSubclasses includes: depClass ]) ifTrue: [ ROEdge buildEdgesFromAssociations: { cls -> depClass } using: (ROLine new color: (Color blue alpha: 0.1)) inView: v ] ] ] ]. "Layout the whole thing" ROForceBasedLayout new userDefinedEdges: inheritanceEdges; on: v elementsNotEdge edges: v elementsAsEdge. "Open the view" v open -=-=-=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre On Jan 15, 2014, at 11:32 AM, Usman Bhatti <usman.bhatti(a)gmail.com> wrote: > Alex, > > I remember to have talked to Mathieu about the making layouts ignore some edges when drawing visualizations and I think he gave it a try as well. I think that can be helpful in Clement's case (back jumps are ignored in the layout). > Do you remember to have integrated something in Roassal on these lines from Mathieu's work? > > Usman > > > On Tue, Jan 14, 2014 at 6:20 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi ClÃ©ment, > > Thanks for your nice words. > Layouts provided by Roassal are well known generic algorithm. Creating a new layout is not complicated at all. Just subclass ROLayout and override the hook methods. Creating a layout for your need is not easy. Have you tried to google for a layout? If you find one, it should be rather easy to implement it. > > Alexandre > > > On Jan 14, 2014, at 12:50 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > Hello Roassal developers, > > > > A few time ago Usman Bhatti showed me Roassal. Today I decided to use it for my daily work on a project that aims to optimize Pharo's methods. > > > > Firstly I am quite impressed by the quality of Roassal, I am currently using the Roassal + Mondrian builder and I have a visual representation which is very close to what I want after 1 hour of work with the help of Usman. Good job guys. > > > > Here are 2 examples of what I use: > > > > exampleIfTrueIfFalse2 > > | a b | > > a := true. > > a > > ifTrue: [ > > false ifTrue: [ ^ b := 1 ] ifFalse: [ b := 2 ] ] > > ifFalse: [ > > true ifTrue: [ b := 4 ] ifFalse: [ b := 5 ] ]. > > ^ b > > > > <Screen Shot 2014-01-14 at 4.14.49 PM.png> > > > > Here there's one rectangle for each basic block, entrance/exits are basic blocks with bigger borders, and borders in red represents the "hot path", which the path the execution flow most frequently uses (based on native code counters added at some spots in the method by Cogit). > > > > Another example: > > > > exampleToDo > > > > 1 to: 10 do: [ :i | > > self kick: i ] > > > > <Screen Shot 2014-01-14 at 4.36.47 PM.png> > > > > Now I have a few issues with the layout. I am currently using the narrowTreeLayout which seems to be the best for my visualisation. > > > > issue 1: When branches merges, which is in a tree when a node has 2 or more parents, or when I have a #ifTrue:ifFalse:, the child is not well aligned horizontally. Here in the first visualisation I showed, BasicBlock 5 is below but not in the middle of Basic block 8,7 and 4 (horizontally). I put a minimal width for each basic block to make it better but it's still not perfect. > > issue 2: (most important issue) I cannot display back jumps because then all the graph is missdrawn, therefore I need to remember where they are instead of visualizing them all the time (I cannot display the back jump from basic block 3 to basic block 2 in the second representation. In addition, the back jump edge, when well displayed, overlaps the basic blocks visualizations. > > > > Here is an example of what I would like for the edges and basic block positions: > > > > <Screen Shot 2014-01-14 at 4.27.32 PM.png> > > > > As you can see, here exit is in the middle of B2 and B5 horizontally, which is not the case in my roassal visualization. > > In addition, there's a back jump from B6 to B4 that I cannot display (or all the visual representation goes nuts). The edge for the back jump does not overlap with the basic blocks. In this graph, arrows follow a grid. I don't care that arrows are diagonals instead of a mix of horizontal and vertical lines but I would like to be able to see nicely the back jumps as in this graph. > > > > Do you have an idea on what layout/view options I could use with Roassal +Mondrian to have a better result ? > > > > I tried to create my own layout but after 2 hours I understood this cost too much time for my planning (or perhaps I'm just too dumb to do it fast :-( ). > > > > Anyway, the representation I have now is good enough for me to use it. But a better one would be better, especially for back jumps :-). > > > > Thanks for any help. > > > > Clement > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 27, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Esteban Lorenzano

can you propose a fix? On 26 Jan 2014, at 22:56, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > On Sun, Jan 26, 2014 at 10:50 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > On Sun, Jan 26, 2014 at 4:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I looked more into it, and here is a smaller example: > Gofer new > smalltalkhubUser: 'Moose' project: 'MooseAlgos'; > package: 'Moose-Algos-Graph'; > load > > This one does open the debugger, so the other emergency evaluator issue comes from somewhere else. > > The problem seems to come from a Trait being defined in this package, and loading this trait triggers ClassModifiedClassDefinition which stumbles in > > ClassModifiedClassDefinition>>isPropagation > "If there is not slot changes, I can assume that there is a propagation (the change is in one of the superclasses)" > self oldClassDefinition layout ifNil: [ ^ false ]. > > ^ self newClassDefinition layout instanceVariables = self oldClassDefinition layout instanceVariables > > > Despite of the name of ClassModifiedClassDefinition, it is announced also when traits are modified. I don't know if Trait should implement #layout... but it is not. > > I reproduced using this: > > Trait named: #DDDD. > Trait > named: #DDDD > uses: {TSortable} > category: 'a'. > > I guess that ClassModifiedClassDefinition is not only being announced when a class changed but also it is being announced when its superclass changed (in the case, "propagated"). So the purpose of #isPropagation is the check that. But I'm not sure this announcement should be done for the subclasses... > > > > Yes, when a class is redefined, the change is announced for subclasses also. Maybe we shouldn't, no? > > code to reproduce: > > > aClass := Object subclass: #A. > aClass subclass: #B. > > anns := OrderedCollection new. > SystemAnnouncer uniqueInstance > when: ClassModifiedClassDefinition > send: #add: > to: anns. > > Object > subclass: #A > instanceVariableNames: 'a'. > > anns. ---> > an OrderedCollection(a ClassModifiedClassDefinition a ClassModifiedClassDefinition) > > > > MartÃn >

Jan. 26, 2014

[pharo-project/pharo-core] 412f1e: 30722

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 412f1eb831271cf2cac517a307a9568c88c3d8b4 https://github.com/pharo-project/pharo-core/commit/412f1eb831271cf2cac517a3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-26 (Sun, 26 Jan 2014) Changed paths: A FileSystem-Core.package/AbstractFileReference.class/instance/streams-compatibility/binaryReadStream.st A FileSystem-Core.package/AbstractFileReference.class/instance/streams-compatibility/binaryReadStreamDo_.st A FileSystem-Core.package/AbstractFileReference.class/instance/streams-compatibility/binaryReadStreamDo_ifAbsent_.st A FileSystem-Core.package/AbstractFileReference.class/instance/streams-compatibility/binaryReadStreamIfAbsent_.st A FileSystem-Core.package/FileLocator.class/instance/streams-compatibility/binaryReadStream.st A FileSystem-Core.package/FileReference.class/instance/streams-compatibility/binaryReadStream.st A FileSystem-Core.package/FileSystem.class/instance/public/binaryReadStreamOn_.st A FileSystem-Disk.package/FileHandle.class/instance/streams-compatibility/binaryReadStream.st A FileSystem-Memory.package/MemoryFileSystemFile.class/instance/streams-compatibility/binaryReadStream.st A FileSystem-Memory.package/MemoryHandle.class/instance/streams-compatibility/binaryReadStream.st A FileSystem-Tests-Core.package/FileSystemTest.class/instance/tests-streams-compatibility/testBinaryReadStream.st A FileSystem-Tests-Core.package/FileSystemTest.class/instance/tests-streams-compatibility/testBinaryReadStreamDo.st A FileSystem-Tests-Core.package/FileSystemTest.class/instance/tests-streams-compatibility/testBinaryReadStreamDoIfAbsent.st A FileSystem-Tests-Core.package/FileSystemTest.class/instance/tests-streams-compatibility/testBinaryReadStreamIfAbsent.st M FreeType.package/FontChooser.class/instance/accessing/pointSizeList.st M FreeType.package/FontChooserMorph.class/instance/accessing/previewText.st M FreeType.package/FontChooserMorph.class/instance/interface building/newFontList.st M FreeType.package/FontChooserMorph.class/instance/interface building/newFontStyleList.st M FreeType.package/FontChooserMorph.class/instance/private/widthRequiredFor_from_noLessThan_.st A Polymorph-Widgets.package/LabelMorph.class/instance/accessing/adoptPaneColor_.st A Polymorph-Widgets.package/LabelMorph.class/instance/accessing/getEnabledSelector.st A Polymorph-Widgets.package/LabelMorph.class/instance/accessing/getEnabledSelector_.st R Polymorph-Widgets.package/LabelMorph.class/instance/as yet unclassified/disable.st R Polymorph-Widgets.package/LabelMorph.class/instance/as yet unclassified/enable.st R Polymorph-Widgets.package/LabelMorph.class/instance/as yet unclassified/getEnabledSelector.st R Polymorph-Widgets.package/LabelMorph.class/instance/as yet unclassified/getEnabledSelector_.st R Polymorph-Widgets.package/LabelMorph.class/instance/as yet unclassified/interactionState_.st R Polymorph-Widgets.package/LabelMorph.class/instance/as yet unclassified/updateEnabled.st R Polymorph-Widgets.package/LabelMorph.class/instance/as yet unclassified/updateText.st A Polymorph-Widgets.package/LabelMorph.class/instance/protocol/disable.st A Polymorph-Widgets.package/LabelMorph.class/instance/protocol/enable.st A Polymorph-Widgets.package/LabelMorph.class/instance/protocol/interactionState_.st A Polymorph-Widgets.package/LabelMorph.class/instance/update/updateText.st A Polymorph-Widgets.package/LabelMorph.class/instance/updating/updateEnabled.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script375.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30722.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30722 12259 FileSystem memory reads/writes using a binary stream by default https://pharo.fogbugz.com/f/cases/12259 12683 Color change of LabelModel when used with openWorldWithSpec https://pharo.fogbugz.com/f/cases/12683 12704 clean FontMorphChooser https://pharo.fogbugz.com/f/cases/12704 http://files.pharo.org/image/30/30722.zip

Jan. 26, 2014

[pharo-project/pharo-core]

by GitHub

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

Jan. 26, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Martin Dias

On Sun, Jan 26, 2014 at 10:50 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > On Sun, Jan 26, 2014 at 4:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> I looked more into it, and here is a smaller example: >> Gofer new >> smalltalkhubUser: 'Moose' project: 'MooseAlgos'; >> package: 'Moose-Algos-Graph'; >> load >> >> This one does open the debugger, so the other emergency evaluator issue >> comes from somewhere else. >> >> The problem seems to come from a Trait being defined in this package, and >> loading this trait triggers ClassModifiedClassDefinition which stumbles in >> >> ClassModifiedClassDefinition>>isPropagation >> "If there is not slot changes, I can assume that there is a propagation >> (the change is in one of the superclasses)" >> self oldClassDefinition layout ifNil: [ ^ false ]. >> ^ self newClassDefinition layout instanceVariables = self >> oldClassDefinition layout instanceVariables >> >> > Despite of the name of ClassModifiedClassDefinition, it is announced also > when traits are modified. I don't know if Trait should implement #layout... > but it is not. > > I reproduced using this: > > Trait named: #DDDD. > Trait > named: #DDDD > uses: {TSortable} > category: 'a'. > > I guess that ClassModifiedClassDefinition is not only being announced when > a class changed but also it is being announced when its superclass changed > (in the case, "propagated"). So the purpose of #isPropagation is the check > that. But I'm not sure this announcement should be done for the > subclasses... > > > Yes, when a class is redefined, the change is announced for subclasses also. Maybe we shouldn't, no? code to reproduce: aClass := Object subclass: #A. aClass subclass: #B. anns := OrderedCollection new. SystemAnnouncer uniqueInstance when: ClassModifiedClassDefinition send: #add: to: anns. Object subclass: #A instanceVariableNames: 'a'. anns. ---> an OrderedCollection(a ClassModifiedClassDefinition a ClassModifiedClassDefinition) MartÃn

Jan. 26, 2014

Re: [Pharo-dev] strange error in latest 3.0 -

by Martin Dias

On Sun, Jan 26, 2014 at 4:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I looked more into it, and here is a smaller example: > Gofer new > smalltalkhubUser: 'Moose' project: 'MooseAlgos'; > package: 'Moose-Algos-Graph'; > load > > This one does open the debugger, so the other emergency evaluator issue > comes from somewhere else. > > The problem seems to come from a Trait being defined in this package, and > loading this trait triggers ClassModifiedClassDefinition which stumbles in > > ClassModifiedClassDefinition>>isPropagation > "If there is not slot changes, I can assume that there is a propagation > (the change is in one of the superclasses)" > self oldClassDefinition layout ifNil: [ ^ false ]. > ^ self newClassDefinition layout instanceVariables = self > oldClassDefinition layout instanceVariables > > Despite of the name of ClassModifiedClassDefinition, it is announced also when traits are modified. I don't know if Trait should implement #layout... but it is not. I reproduced using this: Trait named: #DDDD. Trait named: #DDDD uses: {TSortable} category: 'a'. I guess that ClassModifiedClassDefinition is not only being announced when a class changed but also it is being announced when its superclass changed (in the case, "propagated"). So the purpose of #isPropagation is the check that. But I'm not sure this announcement should be done for the subclasses...

Jan. 26, 2014