Detecting the context/producer of code change announcements
Hi everybody, I'm writing you to discuss about a new feature for Pharo. I would like to know your opinions and ideas. Thanks in advance. My point is that there are operations like "MC version load", "change set file in", "RB refactoring execution", or "class copy" that produce code change announcements (e.g. ClassAdded or MethodAdded), but subscribers can't know that. I mean, a subscriber that listens a ClassAdded can't know if it is product of a "high-level" operation, or if it was manually performed by the user in the Nautilus browser. I think Pharo should provide a way to detect this information, because it can be very useful. For example, I can tell you about a tool I work on: Epicea. Epicea logs code changes while developer works (like traditionally done with the .changes file), and the user can browse, undo and redo changes. Now, imagine that your vm crashed and then you want to recover "lost" changes... you don't want to see hundreds of changes produced by Monticello when loading packages: in this case, such changes are noise and make you waste time when selecting what to redo. In Epicea package I have a workaround for detecting some "high-level" operations, but Epicea would need support from Pharo for a nice implementation. Brainstorming on implementations. I think announcements are a good mechanism to implement this feature. A simple approach is to provide *begin* and *end* *announcements* (e.g. *MCVersionLoadBegin* and *MCVersionLoadEnd*). Then, somebody that subscribes to such announcements can have a stack or state machine to know the context where each code change announcement is produced. It would look like: MCVersionLoader >> load ... SystemAnnouncer uniqueInstance announce: (*MCVersionLoadBegin* versionName: ...). [ ... produce code changes ... ] *ensure:* [ SystemAnnouncer uniqueInstance announce: (*MCVersionLoadEnd* versionName: ...) ]. which may be re-written with a convenience method as: ... SystemAnnouncer uniqueInstance *announceBefore*: (MCVersionLoadBegin versionName: ...) *announceAfter*: (MCVersionLoadEnd versionName: ...) *do: *[ ... produce code changes ... ] but, going one step further, we could reify the concept of announcement *begin* and *end* like: ... *announcement := (MCVersionLoad versionName: ...).* SystemAnnouncer uniqueInstance announceBefore: (*AnnouncementBegin* of: announcement) announceAfter: (*AnnouncementEnd* of: announcement) do: [ ... produce code changes ... ] which could be re-written as: ... SystemAnnouncer uniqueInstance *announceBeforeAndAfter*: (MCVersionLoad versionName: ...) *do*: [ ... produce code changes ... ] I think any approach can work, but I'd love to have some feedback. Kind regards, MartÃn
On Wed, Jun 10, 2015 at 11:13 PM, Martin Dias <tinchodias@gmail.com> wrote:
Hi everybody,
I'm writing you to discuss about a new feature for Pharo. I would like to know your opinions and ideas. Thanks in advance.
My point is that there are operations like "MC version load", "change set file in", "RB refactoring execution", or "class copy" that produce code change announcements (e.g. ClassAdded or MethodAdded), but subscribers can't know that. I mean, a subscriber that listens a ClassAdded can't know if it is product of a "high-level" operation, or if it was manually performed by the user in the Nautilus browser.
I think Pharo should provide a way to detect this information, because it can be very useful. For example, I can tell you about a tool I work on: Epicea. Epicea logs code changes while developer works (like traditionally done with the .changes file), and the user can browse, undo and redo changes. Now, imagine that your vm crashed and then you want to recover "lost" changes... you don't want to see hundreds of changes produced by Monticello when loading packages: in this case, such changes are noise and make you waste time when selecting what to redo. In Epicea package I have a workaround for detecting some "high-level" operations, but Epicea would need support from Pharo for a nice implementation.
Brainstorming on implementations.
I think announcements are a good mechanism to implement this feature. A simple approach is to provide begin and end announcements (e.g. MCVersionLoadBegin and MCVersionLoadEnd). Then, somebody that subscribes to such announcements can have a stack or state machine to know the context where each code change announcement is produced. It would look like:
MCVersionLoader >> load ... SystemAnnouncer uniqueInstance announce: (MCVersionLoadBegin versionName: ...). [ ... produce code changes ... ] ensure: [ SystemAnnouncer uniqueInstance announce: (MCVersionLoadEnd versionName: ...) ].
which may be re-written with a convenience method as: ... SystemAnnouncer uniqueInstance announceBefore: (MCVersionLoadBegin versionName: ...) announceAfter: (MCVersionLoadEnd versionName: ...) do: [ ... produce code changes ... ]
but, going one step further, we could reify the concept of announcement begin and end like: ... announcement := (MCVersionLoad versionName: ...). SystemAnnouncer uniqueInstance announceBefore: (AnnouncementBegin of: announcement) announceAfter: (AnnouncementEnd of: announcement) do: [ ... produce code changes ... ]
which could be re-written as: ... SystemAnnouncer uniqueInstance announceBeforeAndAfter: (MCVersionLoad versionName: ...) do: [ ... produce code changes ... ]
I think any approach can work, but I'd love to have some feedback.
Kind regards, MartÃn
The first thought that occurs to me is whether Announcements can be hierarchical. So the "low-level" announcements have a "high-level" announcement as their parent. Then the "recover changes" interface shows only the high-level changes at the first tree level, but you can still drill down to disable individual "low-level" changes. Sorry, in trying to think of an opinion for begin/end pattern I come up blank. Not enough experience with it. cheers -ben
On 10 Jun 2015, at 17:13, Martin Dias <tinchodias@gmail.com> wrote:
Hi everybody,
I'm writing you to discuss about a new feature for Pharo. I would like to know your opinions and ideas. Thanks in advance.
My point is that there are operations like "MC version load", "change set file in", "RB refactoring execution", or "class copy" that produce code change announcements (e.g. ClassAdded or MethodAdded), but subscribers can't know that. I mean, a subscriber that listens a ClassAdded can't know if it is product of a "high-level" operation, or if it was manually performed by the user in the Nautilus browser.
I think Pharo should provide a way to detect this information, because it can be very useful. For example, I can tell you about a tool I work on: Epicea. Epicea logs code changes while developer works (like traditionally done with the .changes file), and the user can browse, undo and redo changes. Now, imagine that your vm crashed and then you want to recover "lost" changes... you don't want to see hundreds of changes produced by Monticello when loading packages: in this case, such changes are noise and make you waste time when selecting what to redo. In Epicea package I have a workaround for detecting some "high-level" operations, but Epicea would need support from Pharo for a nice implementation.
Brainstorming on implementations.
I think announcements are a good mechanism to implement this feature. A simple approach is to provide begin and end announcements (e.g. MCVersionLoadBegin and MCVersionLoadEnd). Then, somebody that subscribes to such announcements can have a stack or state machine to know the context where each code change announcement is produced. It would look like:
MCVersionLoader >> load ... SystemAnnouncer uniqueInstance announce: (MCVersionLoadBegin versionName: ...). [ ... produce code changes ... ] ensure: [ SystemAnnouncer uniqueInstance announce: (MCVersionLoadEnd versionName: ...) ].
which may be re-written with a convenience method as: ... SystemAnnouncer uniqueInstance announceBefore: (MCVersionLoadBegin versionName: ...) announceAfter: (MCVersionLoadEnd versionName: ...) do: [ ... produce code changes ... ]
but, going one step further, we could reify the concept of announcement begin and end like: ... announcement := (MCVersionLoad versionName: ...). SystemAnnouncer uniqueInstance announceBefore: (AnnouncementBegin of: announcement) announceAfter: (AnnouncementEnd of: announcement) do: [ ... produce code changes ... ]
which could be re-written as: ... SystemAnnouncer uniqueInstance announceBeforeAndAfter: (MCVersionLoad versionName: ...) do: [ ... produce code changes ... ]
I think any approach can work, but I'd love to have some feedback.
I like the idea. What Iâm afraid of is however, that the dependency between begin and end announcements is implicit in your examples. The only things that tell you that they belong together are the convenience implementation on SystemAnnouncer and the naming. Iâm not familiar enough with announcements to post example code. The other thing would maybe be to force subscribers to subscribe to both announcements (again, not sure how). My point is, I want to look at one of the announcements and see that I have to work with a set of announcements. Benâs idea of hierarchichal announcements sounds pretty interesting. Maybe this is too restricting but how about saying: there exists a dependency between two announcements A and B such that whenever A is being announced, B has to have been announced before (Iâll leave the implementation to others :p). The other thing would be to clean up the announcer situation⦠Maybe the announcers should be hierarchical, not the announcements. Doru did a presentation at ESUG about an idea for a logging framework that uses announcements by using different announcers for different levels of interest (https://youtu.be/keqdqFu1ejk?t=10m55s <https://youtu.be/keqdqFu1ejk?t=10m55s>). That way, if youâre interested in what MC does in the abyss of MC hell you can subscribe to the MCAbyssAnnouncer, if you want high level change events you subscribe to the MCInterestingChangeAnnouncer. I hope you can make some use of my ramblings (last exam tomorrow, just taking a break here :) ) Cheers, Max
Kind regards, MartÃn
On Wed, Jun 10, 2015 at 11:29 AM, Max Leske <maxleske@gmail.com> wrote:
On 10 Jun 2015, at 17:13, Martin Dias <tinchodias@gmail.com> wrote:
Hi everybody,
<snip>
The other thing would be to clean up the announcer situation⦠Maybe the announcers should be hierarchical, not the announcements. Doru did a presentation at ESUG about an idea for a logging framework that uses announcements by using different announcers for different levels of interest (https://youtu.be/keqdqFu1ejk?t=10m55s). That way, if youâre interested in what MC does in the abyss of MC hell you can subscribe to the MCAbyssAnnouncer, if you want high level change events you subscribe to the MCInterestingChangeAnnouncer.
I'm not sure how the hierarchical announcers would help Ben's issue (as I
see it). I would think the logging would like to know that an MC install is happening, and log the MC install (and parameters, probably - like what was decided on a MERGE), and then ignore all of the actual class/method/doit's that come out of that load. EXCEPT, of course, and Syntax fixes done by the users during that load - those would want to be caught as non-MC derived. And a nice playback would be constructed to automatically apply them next time. (Wish list....) If you have two announcers, you'd need to detect the beginning of the MC install, and ignore the class/method announcements until you get the end of the MC install. And you'd have to make sure the MC install always signals an end - else you could ignore all manual changes afterwards. And, if the user could be saving other code while the MC is loading, you'd loose those changes - since you are ignoring them. That said, I'm unclear on how you'd signal the hiercarchical announcements that Ben mentions. Class/Method announcements not originated by MC would be base change announcements; those originated from MC would be the MCChange Announcement sub-classes + the MC generated announcement (started load, etc). Just thoughts. -cbc
I hope you can make some use of my ramblings (last exam tomorrow, just taking a break here :) )
Cheers, Max
Kind regards, MartÃn
@Max: I watched the presentation but I'm not sure how to apply it in this case. (Last exam!? good!) @Ben: I agree that there are not only 2 levels, high-level and low-level announcements but a hierarchy. For example, a "MCVersionLoad" could have a "MetacelloProjectLoad" as a parent. @Chris (and all): Thanks for your feedback. I'm in for any solution that can be implemented fast and be integrated soon in Pharo 5, because I want to use this feature without my workarounds that override the system in a nasty way. Before I didn't mention that I considered Job as a possible solution. Job represents a task to run. For example: [ :bar | bar increment. (Delay forSeconds: 1) wait. bar increment. (Delay forSeconds: 1) wait. ] asJob title: 'Loading'; min: 1; max: 3; run But, additionally to that basic function: - Each Job knows its parent. - Job class implements #current which looks up the next job in the execution stack (using Exception), or nil if none. The current (but fixable) limitation of Job is that it only holds a title string, but not a more complex object for describing itself. I mean, when a listener receives a ClassAdded, it could lookup parent jobs for one with a high-level operation associated. MCVersionLoader >> load ... [ ... produce code changes ... ] asJob title: 'Loading'; description: (MCVersionLoad versionName: ...) run. MyListener >> classAdded: ... Job lookupParent: [ :job | job description isHighLevelOperation ] ifPresent: [ ... ] ifAbsent: [ ... ] Regards, Martin On Wed, Jun 10, 2015 at 11:33 PM, Chris Cunningham <cunningham.cb@gmail.com> wrote:
On Wed, Jun 10, 2015 at 11:29 AM, Max Leske <maxleske@gmail.com> wrote:
On 10 Jun 2015, at 17:13, Martin Dias <tinchodias@gmail.com> wrote:
Hi everybody,
<snip>
The other thing would be to clean up the announcer situation⦠Maybe the announcers should be hierarchical, not the announcements. Doru did a presentation at ESUG about an idea for a logging framework that uses announcements by using different announcers for different levels of interest (https://youtu.be/keqdqFu1ejk?t=10m55s). That way, if youâre interested in what MC does in the abyss of MC hell you can subscribe to the MCAbyssAnnouncer, if you want high level change events you subscribe to the MCInterestingChangeAnnouncer.
I'm not sure how the hierarchical announcers would help Ben's issue (as I
see it). I would think the logging would like to know that an MC install is happening, and log the MC install (and parameters, probably - like what was decided on a MERGE), and then ignore all of the actual class/method/doit's that come out of that load. EXCEPT, of course, and Syntax fixes done by the users during that load - those would want to be caught as non-MC derived. And a nice playback would be constructed to automatically apply them next time. (Wish list....)
If you have two announcers, you'd need to detect the beginning of the MC install, and ignore the class/method announcements until you get the end of the MC install. And you'd have to make sure the MC install always signals an end - else you could ignore all manual changes afterwards. And, if the user could be saving other code while the MC is loading, you'd loose those changes - since you are ignoring them.
That said, I'm unclear on how you'd signal the hiercarchical announcements that Ben mentions. Class/Method announcements not originated by MC would be base change announcements; those originated from MC would be the MCChange Announcement sub-classes + the MC generated announcement (started load, etc).
Just thoughts.
-cbc
I hope you can make some use of my ramblings (last exam tomorrow, just taking a break here :) )
Cheers, Max
Kind regards, MartÃn
Hi Martin, I believe your job example express better what you need, so what I would propose would be a notion of parent in the normal code announcements, containing, in a hierarchical way, the higher level context information. But implementing that parent in the announcements will be difficult, so I'd take either your job solution, or a notification (RequestContextNotification); the notification handler would then be able to provide the context when this notification is signaled (and, of course, this would be hierarchical). A pre/post announcement doesn't work: you cannot guarantee that things happening between those two belongs to this context because it may be done in different processes. Regards, Thierry Le 11 juin 2015 14:05, "Martin Dias" <tinchodias@gmail.com> a écrit :
@Max: I watched the presentation but I'm not sure how to apply it in this
case. (Last exam!? good!)
@Ben: I agree that there are not only 2 levels, high-level and low-level
announcements but a hierarchy. For example, a "MCVersionLoad" could have a "MetacelloProjectLoad" as a parent.
@Chris (and all): Thanks for your feedback. I'm in for any solution that
can be implemented fast and be integrated soon in Pharo 5, because I want to use this feature without my workarounds that override the system in a nasty way.
Before I didn't mention that I considered Job as a possible solution. Job
represents a task to run. For example:
[ :bar | bar increment. (Delay forSeconds: 1) wait. bar increment. (Delay forSeconds: 1) wait. ] asJob title: 'Loading'; min: 1; max: 3; run
But, additionally to that basic function:
- Each Job knows its parent. - Job class implements #current which looks up the next job in the
execution stack (using Exception), or nil if none.
The current (but fixable) limitation of Job is that it only holds a title
string, but not a more complex object for describing itself. I mean, when a listener receives a ClassAdded, it could lookup parent jobs for one with a high-level operation associated.
MCVersionLoader >> load ... [ ... produce code changes ... ] asJob title: 'Loading'; description: (MCVersionLoad versionName: ...) run.
MyListener >> classAdded: ... Job lookupParent: [ :job | job description isHighLevelOperation ] ifPresent: [ ... ] ifAbsent: [ ... ]
Regards, Martin
On Wed, Jun 10, 2015 at 11:33 PM, Chris Cunningham <
cunningham.cb@gmail.com> wrote:
On Wed, Jun 10, 2015 at 11:29 AM, Max Leske <maxleske@gmail.com> wrote:
On 10 Jun 2015, at 17:13, Martin Dias <tinchodias@gmail.com> wrote:
Hi everybody,
<snip>
The other thing would be to clean up the announcer situation⦠Maybe the
announcers should be hierarchical, not the announcements. Doru did a presentation at ESUG about an idea for a logging framework that uses announcements by using different announcers for different levels of interest (https://youtu.be/keqdqFu1ejk?t=10m55s). That way, if youâre interested in what MC does in the abyss of MC hell you can subscribe to the MCAbyssAnnouncer, if you want high level change events you subscribe to the MCInterestingChangeAnnouncer.
I'm not sure how the hierarchical announcers would help Ben's issue (as I see it). I would think the logging would like to know that an MC install is happening, and log the MC install (and parameters, probably - like what was decided on a MERGE), and then ignore all of the actual class/method/doit's that come out of that load. EXCEPT, of course, and Syntax fixes done by the users during that load - those would want to be caught as non-MC derived. And a nice playback would be constructed to automatically apply them next time. (Wish list....)
If you have two announcers, you'd need to detect the beginning of the MC install, and ignore the class/method announcements until you get the end of the MC install. And you'd have to make sure the MC install always signals an end - else you could ignore all manual changes afterwards. And, if the user could be saving other code while the MC is loading, you'd loose those changes - since you are ignoring them.
That said, I'm unclear on how you'd signal the hiercarchical announcements that Ben mentions. Class/Method announcements not originated by MC would be base change announcements; those originated from MC would be the MCChange Announcement sub-classes + the MC generated announcement (started load, etc).
Just thoughts.
-cbc
I hope you can make some use of my ramblings (last exam tomorrow, just
taking a break here :) )
Cheers, Max
Kind regards, MartÃn
On Thu, Jun 11, 2015 at 2:29 AM, Max Leske <maxleske@gmail.com> wrote:
On 10 Jun 2015, at 17:13, Martin Dias <tinchodias@gmail.com> wrote:
Hi everybody,
I'm writing you to discuss about a new feature for Pharo. I would like to know your opinions and ideas. Thanks in advance.
My point is that there are operations like "MC version load", "change set file in", "RB refactoring execution", or "class copy" that produce code change announcements (e.g. ClassAdded or MethodAdded), but subscribers can't know that. I mean, a subscriber that listens a ClassAdded can't know if it is product of a "high-level" operation, or if it was manually performed by the user in the Nautilus browser.
I think Pharo should provide a way to detect this information, because it can be very useful. For example, I can tell you about a tool I work on: Epicea. Epicea logs code changes while developer works (like traditionally done with the .changes file), and the user can browse, undo and redo changes. Now, imagine that your vm crashed and then you want to recover "lost" changes... you don't want to see hundreds of changes produced by Monticello when loading packages: in this case, such changes are noise and make you waste time when selecting what to redo. In Epicea package I have a workaround for detecting some "high-level" operations, but Epicea would need support from Pharo for a nice implementation.
Brainstorming on implementations.
I think announcements are a good mechanism to implement this feature. A simple approach is to provide begin and end announcements (e.g. MCVersionLoadBegin and MCVersionLoadEnd). Then, somebody that subscribes to such announcements can have a stack or state machine to know the context where each code change announcement is produced. It would look like:
MCVersionLoader >> load ... SystemAnnouncer uniqueInstance announce: (MCVersionLoadBegin versionName: ...). [ ... produce code changes ... ] ensure: [ SystemAnnouncer uniqueInstance announce: (MCVersionLoadEnd versionName: ...) ].
which may be re-written with a convenience method as: ... SystemAnnouncer uniqueInstance announceBefore: (MCVersionLoadBegin versionName: ...) announceAfter: (MCVersionLoadEnd versionName: ...) do: [ ... produce code changes ... ]
but, going one step further, we could reify the concept of announcement begin and end like: ... announcement := (MCVersionLoad versionName: ...). SystemAnnouncer uniqueInstance announceBefore: (AnnouncementBegin of: announcement) announceAfter: (AnnouncementEnd of: announcement) do: [ ... produce code changes ... ]
which could be re-written as: ... SystemAnnouncer uniqueInstance announceBeforeAndAfter: (MCVersionLoad versionName: ...) do: [ ... produce code changes ... ]
I think any approach can work, but I'd love to have some feedback.
I like the idea. What Iâm afraid of is however, that the dependency between begin and end announcements is implicit in your examples. The only things that tell you that they belong together are the convenience implementation on SystemAnnouncer and the naming. Iâm not familiar enough with announcements to post example code. The other thing would maybe be to force subscribers to subscribe to both announcements (again, not sure how). My point is, I want to look at one of the announcements and see that I have to work with a set of announcements.
Benâs idea of hierarchichal announcements sounds pretty interesting. Maybe this is too restricting but how about saying: there exists a dependency between two announcements A and B such that whenever A is being announced, B has to have been announced before (Iâll leave the implementation to others :p).
The other thing would be to clean up the announcer situation⦠Maybe the announcers should be hierarchical, not the announcements. Doru did a presentation at ESUG about an idea for a logging framework that uses announcements by using different announcers for different levels of interest (https://youtu.be/keqdqFu1ejk?t=10m55s). That way, if youâre interested in what MC does in the abyss of MC hell you can subscribe to the MCAbyssAnnouncer, if you want high level change events you subscribe to the MCInterestingChangeAnnouncer.
Just a *very* divergent thought that I'm not sure is a good idea... maybe the parent announcement could hold the announcer of its children. cheers -ben
I hope you can make some use of my ramblings (last exam tomorrow, just taking a break here :) )
Cheers, Max
Kind regards, MartÃn
2015-06-11 16:49 GMT+02:00 Ben Coman <btc@openinworld.com>:
Just a *very* divergent thought that I'm not sure is a good idea... maybe the parent announcement could hold the announcer of its children.
The problem is then that all tools which are not interested in the parent announcement because they only deal with the low level stuff (system browser, RPackageOrganizer and friends: MessageList, Spotter, Critics browser, Finder, Versionner, Inspector, anything which listen to a code change basically) have to still listen to the parent and, on reception, subscribe to the low-level announcement, and then unsubscribe on the parent end announcement. Another issue is, when introducing a new class of activity such as SprintInRMOD, you then need to rewrite all the listeners to add the relevant: ... on: SprintInRMOD do: [:a | a childAnnouncer on: MethodChange do: ... ] Kind of messy. For me, what Martin is trying to do is currently handled in a way by MC and RB: write all your code operations as abstract operations on a model of the code, group them into a composite (RBCompositeChange or something like that), and apply them all in one go. But all this structure is flattened in the change set, and may be interleaved with other changes happening at the same time. I'd take Martin's job idea :) plus specific announcements for the start and end. Thierry
cheers -ben
I hope you can make some use of my ramblings (last exam tomorrow, just taking a break here :) )
Cheers, Max
Kind regards, MartÃn
Hi Thierry, On Jun 11, 2015, at 8:16 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2015-06-11 16:49 GMT+02:00 Ben Coman <btc@openinworld.com>:
Just a *very* divergent thought that I'm not sure is a good idea... maybe the parent announcement could hold the announcer of its children.
The problem is then that all tools which are not interested in the parent announcement because they only deal with the low level stuff (system browser, RPackageOrganizer and friends: MessageList, Spotter, Critics browser, Finder, Versionner, Inspector, anything which listen to a code change basically) have to still listen to the parent and, on reception, subscribe to the low-level announcement, and then unsubscribe on the parent end announcement.
It seems to me that with Ben's suggestion there need only be the low-level announcement, and that subscribers interested in the higher-level context could fetch it by asking the announcement for its context.
Another issue is, when introducing a new class of activity such as SprintInRMOD, you then need to rewrite all the listeners to add the relevant: ... on: SprintInRMOD do: [:a | a childAnnouncer on: MethodChange do: ... ]
Kind of messy.
For me, what Martin is trying to do is currently handled in a way by MC and RB: write all your code operations as abstract operations on a model of the code, group them into a composite (RBCompositeChange or something like that), and apply them all in one go. But all this structure is flattened in the change set, and may be interleaved with other changes happening at the same time.
I'd take Martin's job idea :) plus specific announcements for the start and end.
Thierry
cheers -ben
I hope you can make some use of my ramblings (last exam tomorrow, just taking a break here :) )
Cheers, Max
Kind regards, MartÃn
Hi Eliot, Le 13/06/2015 06:54, Eliot Miranda a écrit :
Hi Thierry,
On Jun 11, 2015, at 8:16 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2015-06-11 16:49 GMT+02:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>:
Just a *very* divergent thought that I'm not sure is a good idea... maybe the parent announcement could hold the announcer of its children.
The problem is then that all tools which are not interested in the parent announcement because they only deal with the low level stuff (system browser, RPackageOrganizer and friends: MessageList, Spotter, Critics browser, Finder, Versionner, Inspector, anything which listen to a code change basically) have to still listen to the parent and, on reception, subscribe to the low-level announcement, and then unsubscribe on the parent end announcement.
It seems to me that with Ben's suggestion there need only be the low-level announcement, and that subscribers interested in the higher-level context could fetch it by asking the announcement for its context.
I reacted to the fact Ben said announcer, not announcement... Reregistering announcers in code-aware tools is not something you do often [1] One aspect I forgot is the performance issues linked with announcements. On package loads, a huge number of announcements is generated, and just simple things like tracking those to refresh the display of a system browser needs to be optimised to avoid degrading performance significantly. Thierry [1] https://github.com/ThierryGoubier/AltBrowser/blob/pharo5/Alt-Browser.package...
Thanks for the discussion. I'm considering the ideas; I want to propose something concrete very soon. If I understand well, the two positions are: * to extend Job with a 'description' object; * to extend system announcements, so they know their 'parent' announcement; in both cases, the subscriber can lookup into the hierarchy of "tasks" that produced an announcement. MartÃn On Sat, Jun 13, 2015 at 8:06 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Eliot,
Le 13/06/2015 06:54, Eliot Miranda a écrit :
Hi Thierry,
On Jun 11, 2015, at 8:16 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2015-06-11 16:49 GMT+02:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>:
Just a *very* divergent thought that I'm not sure is a good idea... maybe the parent announcement could hold the announcer of its children.
The problem is then that all tools which are not interested in the parent announcement because they only deal with the low level stuff (system browser, RPackageOrganizer and friends: MessageList, Spotter, Critics browser, Finder, Versionner, Inspector, anything which listen to a code change basically) have to still listen to the parent and, on reception, subscribe to the low-level announcement, and then unsubscribe on the parent end announcement.
It seems to me that with Ben's suggestion there need only be the low-level announcement, and that subscribers interested in the higher-level context could fetch it by asking the announcement for its context.
I reacted to the fact Ben said announcer, not announcement... Reregistering announcers in code-aware tools is not something you do often [1]
One aspect I forgot is the performance issues linked with announcements. On package loads, a huge number of announcements is generated, and just simple things like tracking those to refresh the display of a system browser needs to be optimised to avoid degrading performance significantly.
Thierry
[1] https://github.com/ThierryGoubier/AltBrowser/blob/pharo5/Alt-Browser.package...
I'm going in the direction of the Job. I started by doing some clean up in the implementation, together with Guille in a useful pair-programming session. The issue needs approval for integration: https://pharo.fogbugz.com/f/cases/15833/Remove-Notifications-from-Job-implem... MartÃn On Wed, Jun 17, 2015 at 7:03 PM, Martin Dias <tinchodias@gmail.com> wrote:
Thanks for the discussion. I'm considering the ideas; I want to propose something concrete very soon.
If I understand well, the two positions are:
* to extend Job with a 'description' object; * to extend system announcements, so they know their 'parent' announcement;
in both cases, the subscriber can lookup into the hierarchy of "tasks" that produced an announcement.
MartÃn
On Sat, Jun 13, 2015 at 8:06 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
Hi Eliot,
Le 13/06/2015 06:54, Eliot Miranda a écrit :
Hi Thierry,
On Jun 11, 2015, at 8:16 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:
2015-06-11 16:49 GMT+02:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>:
Just a *very* divergent thought that I'm not sure is a good idea... maybe the parent announcement could hold the announcer of its children.
The problem is then that all tools which are not interested in the parent announcement because they only deal with the low level stuff (system browser, RPackageOrganizer and friends: MessageList, Spotter, Critics browser, Finder, Versionner, Inspector, anything which listen to a code change basically) have to still listen to the parent and, on reception, subscribe to the low-level announcement, and then unsubscribe on the parent end announcement.
It seems to me that with Ben's suggestion there need only be the low-level announcement, and that subscribers interested in the higher-level context could fetch it by asking the announcement for its context.
I reacted to the fact Ben said announcer, not announcement... Reregistering announcers in code-aware tools is not something you do often [1]
One aspect I forgot is the performance issues linked with announcements. On package loads, a huge number of announcements is generated, and just simple things like tracking those to refresh the display of a system browser needs to be optimised to avoid degrading performance significantly.
Thierry
[1] https://github.com/ThierryGoubier/AltBrowser/blob/pharo5/Alt-Browser.package...
participants (6)
-
Ben Coman -
Chris Cunningham -
Eliot Miranda -
Martin Dias -
Max Leske -
Thierry Goubier