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