Hi Michael,

if you have control over the methods involved (i.e. only "your" methods)  
then you can add a temp var like
  | activation |
  activation _ whatsoever.

You can access that temp var in, say context ctx, with
  ctx tempAt: index

This of course only if you somehow would know the position (index).

Another approach is to make the activation variable always the first  
message argument, like in
myMethod: activation with: more

This way (ctx tempAt: 1) always refers to the activation variable (which  
is, BTW, the way I usually extend BlockContext). Note that you can do  
thisContext tempAt: 1 put: anotherValue.

The above is only good for MethodContext; BlockContext is much more  
complicated.

But if you had no solution working with tempAt: you'd also have no  
solution for modifying the VM...

Hope that helps.

/Klaus

On Sat, 12 Nov 2005 16:33:10 +0100, Michael Haupt <mhaupt at gmail.com> wrote:

> Hi,
>
> On 11/12/05, stéphane ducasse <ducasse at iam.unibe.ch> wrote:
>> I see that Smalltalk is still living in darmstadt :) or resurrecting.
>> Say hello to mira from me.
>
> sure. :-) Smalltalk has never been dead here. We've even used it in a
> software design course.
>
>> Can you tell us what you would like to do just an idea?
>
> It's about aspect-oriented programming (of course; it's Darmstadt
> after all...) and control flow matching. The way AspectS performs
> control flow matching is by looking at the call stack, which might
> take quite some time when the stack is deep.
>
> So, I had the idea of attaching the information "this activation
> (i.e., context) is inside that control flow" to the context directly.
> I believe it will make the checks more efficient.
>
> Also, I'd like to propagate the control flows to contexts that are
> created from existing contexts.
>
>> I'm curious to also know this answer to your question.
>
> It'd be great if you could help me. :-)
>
> Best,
>
> Michael Haupt
>
>