@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