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
>>>>
>>>
>>
>