Re: [Pharo-project] Hints and clues for a Pharo newb

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Hints and clues for a Pharo newb

Eliot Miranda-2
 


On Wed, Apr 21, 2010 at 4:34 PM, Hernán Morales Durand <[hidden email]> wrote:
2010/4/21 Lukas Renggli <[hidden email]>:
>> thisContext is a special object for representing an activation in a
>> stack frame in a stack-based VM.
>
> Actually "thisContext" represents *the current* activation/stack-frame.
>
>    foo: anObject
>         ^ thisContext at: 1
>
> is the same as
>
>    foo: anObject
>         ^ anObject
>

Of course, "this" refers to "the current" in common language usage.

>> There are two kinds of contexts:
>> Method Contexts and Block Contexts.
>
> Actually in Pharo images there are only instances of MethodContext.
> Though you can ask the context if it comes from a block by sending the
> message #isExecutingBlock.
>

Actually in Pharo there is a BlockContext class, which is not
instantiated anymore after the introduction of the closure compiler?

Right.
 
In other Smalltalks aBlockContext is the resulting context of a block
activation during its evaluation and is activated by sending
#value,.this fills thisContext with the execution information inside
the block.

and it is now with the closure compiler.  Or rather a new context is created when a BlockClosure is sent the value message.  The context is an instance of methodContext though.
 
In Squeak (or the old compiler) block contexts were created using
#blockCopy:, now I see #closureNumCopied:numArgs:. Does this means
BlockContext could be completely removed and replaced with
MethodContext semantics? I've removed the BlockContext class and used
Pharo a little bit with no problems, maybe some Decompiler issues in
the Debugger...

Yes.  But MethodContext behaves differently depending on whether its closureOrNil inst var is nil (a normal method) or a BlockClosure (an activation of a block).  If nil, ^-returns return to the context's sender.  If not nil ^-returns return from the home context, found by following the outerContext chain through the closureOrNil inst var.  So we no longer need BlockContext.

This also means we only need one context class, and some time I'd like to merge the two ContextPart and MethodContext classes into a single Context class.  Possibly the name should be ExecutionContext or MethodOrBlockContext or?  Suggestions?


Now, test yourself before evaluating :) what should be the result of
this expression?

[: arg | arg perform: #isExecutingBlock ] value: thisContext

It depends on whether the expression is executed at method level or at block level.  As a test this should be:

testIsExecutingBlock
    self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == false.
    [self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == true] value

Can somebody justify the result?

isExecutingBlock answers if the receiver is executing a block or not. It does not answer whether the context in which isExecutingBlock is sent is executing a block or not.  Remember that

    [:arg| arg == thisContext] value: thisContext

is false.  thisContext is rebound within every actual method or block scope.

HTH

Eliot


>> Context creation is optimized in the VM in most Smalltalks, so it's
>> only really created as an object in the environment (reified) when
>> it's specifically needed through "thisContext".
>
> In Pharo contexts are not reified like that. Stack-frames are actual
> objects at all times. However, for speed reasons, their creation and
> garbage-collection is optimized by the VM. Stack frames get
> automatically recycled if nobody refers to them.
>

I think is what I said :)

But its not a property of Pharo.  It is a property of the VM.  In Cog contexts are not actual objects all the time, only when needed.  And Cog runs Pharo images just as it runs Squeak images.  So it would be incorrect to say "in Pharo" and better to say "in the standard Squeak VM".


>> There are several applications related with computational reflection
>> (Reflective Programming, Meta-Programming, MOP, etc) which makes use
>> of the current context.
>
> Also: exception handling, generators, continuations, co-routines, ...
>
> For another fun use of "thisContext" check this Stack-Overflow question:
>
> http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only-language-to-define-a-whiletrue-message-without-r
>
> Lukas
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Hints and clues for a Pharo newb

Colin Putney


On 2010-04-21, at 5:04 PM, Eliot Miranda <[hidden email]> wrote:

> This also means we only need one context class, and some time I'd like to merge the two ContextPart and MethodContext classes into a single Context class.  Possibly the name should be ExecutionContext or MethodOrBlockContext or?  Suggestions?

I suggest ActivationContext.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Hints and clues for a Pharo newb

stephane ducasse-2
In reply to this post by Eliot Miranda-2

> Yes.  But MethodContext behaves differently depending on whether its closureOrNil inst var is nil (a normal method) or a BlockClosure (an activation of a block).  If nil, ^-returns return to the context's sender.  If not nil ^-returns return from the home context, found by following the outerContext chain through the closureOrNil inst var.  So we no longer need BlockContext.


Hi Elliot

I was wondering why you do not use two classes and you do the nil check?

> This also means we only need one context class, and some time I'd like to merge the two ContextPart and MethodContext classes into a single Context class.  Possibly the name should be ExecutionContext or MethodOrBlockContext or?  Suggestions?
>
>
> Now, test yourself before evaluating :) what should be the result of
> this expression?
>
> [: arg | arg perform: #isExecutingBlock ] value: thisContext
>
> It depends on whether the expression is executed at method level or at block level.  As a test this should be:
>
> testIsExecutingBlock
>     self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == false.
>     [self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == true] value
>
> Can somebody justify the result?
>
> isExecutingBlock answers if the receiver is executing a block or not. It does not answer whether the context in which isExecutingBlock is sent is executing a block or not.  Remember that
>
>     [:arg| arg == thisContext] value: thisContext
>
> is false.  thisContext is rebound within every actual method or block scope.
>
> HTH
>
> Eliot
>
>
> >> Context creation is optimized in the VM in most Smalltalks, so it's
> >> only really created as an object in the environment (reified) when
> >> it's specifically needed through "thisContext".
> >
> > In Pharo contexts are not reified like that. Stack-frames are actual
> > objects at all times. However, for speed reasons, their creation and
> > garbage-collection is optimized by the VM. Stack frames get
> > automatically recycled if nobody refers to them.
> >
>
> I think is what I said :)
>
> But its not a property of Pharo.  It is a property of the VM.  In Cog contexts are not actual objects all the time, only when needed.  And Cog runs Pharo images just as it runs Squeak images.  So it would be incorrect to say "in Pharo" and better to say "in the standard Squeak VM".
>
>
> >> There are several applications related with computational reflection
> >> (Reflective Programming, Meta-Programming, MOP, etc) which makes use
> >> of the current context.
> >
> > Also: exception handling, generators, continuations, co-routines, ...
> >
> > For another fun use of "thisContext" check this Stack-Overflow question:
> >
> > http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only-language-to-define-a-whiletrue-message-without-r
> >
> > Lukas
> >
> > --
> > Lukas Renggli
> > www.lukas-renggli.ch
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Hints and clues for a Pharo newb

stephane ducasse-2
In reply to this post by Colin Putney

Yes this is a nice name


On Apr 22, 2010, at 6:06 AM, Colin Putney wrote:

>
>
> On 2010-04-21, at 5:04 PM, Eliot Miranda <[hidden email]> wrote:
>
>> This also means we only need one context class, and some time I'd like to merge the two ContextPart and MethodContext classes into a single Context class.  Possibly the name should be ExecutionContext or MethodOrBlockContext or?  Suggestions?
>
> I suggest ActivationContext.
>
> Colin
>

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Hints and clues for a Pharo newb

Eliot Miranda-2
In reply to this post by stephane ducasse-2
 


On Thu, Apr 22, 2010 at 12:49 AM, stephane ducasse <[hidden email]> wrote:

> Yes.  But MethodContext behaves differently depending on whether its closureOrNil inst var is nil (a normal method) or a BlockClosure (an activation of a block).  If nil, ^-returns return to the context's sender.  If not nil ^-returns return from the home context, found by following the outerContext chain through the closureOrNil inst var.  So we no longer need BlockContext.


Hi Elliot

I was wondering why you do not use two classes and you do the nil check?

One reason is backward compatibility.  The existing VM ensures that closureOrNil (which used to be called receiverMap) is nil.  The other is the internal workings of the VM.  The nil test is done by the VM on every ^-return.  The VM isn't going to waste time sending a message.  It is going to do a nil test.

In fact in Cog the VM doesn't even do a nil test since in machine code the JIT knows at compile time whether an ^-return is within a block or not, and in the stack interpreter whether a frame is a block activation is indicated by a status bit in the method field of a frame.

So don't think Smalltalk code, think optimized VM internals.  We're not going to waste time instantiating some object just to tag a structure as not being a block activation.

HTH
Eliot
 

> This also means we only need one context class, and some time I'd like to merge the two ContextPart and MethodContext classes into a single Context class.  Possibly the name should be ExecutionContext or MethodOrBlockContext or?  Suggestions?
>
>
> Now, test yourself before evaluating :) what should be the result of
> this expression?
>
> [: arg | arg perform: #isExecutingBlock ] value: thisContext
>
> It depends on whether the expression is executed at method level or at block level.  As a test this should be:
>
> testIsExecutingBlock
>     self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == false.
>     [self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == true] value
>
> Can somebody justify the result?
>
> isExecutingBlock answers if the receiver is executing a block or not. It does not answer whether the context in which isExecutingBlock is sent is executing a block or not.  Remember that
>
>     [:arg| arg == thisContext] value: thisContext
>
> is false.  thisContext is rebound within every actual method or block scope.
>
> HTH
>
> Eliot
>
>
> >> Context creation is optimized in the VM in most Smalltalks, so it's
> >> only really created as an object in the environment (reified) when
> >> it's specifically needed through "thisContext".
> >
> > In Pharo contexts are not reified like that. Stack-frames are actual
> > objects at all times. However, for speed reasons, their creation and
> > garbage-collection is optimized by the VM. Stack frames get
> > automatically recycled if nobody refers to them.
> >
>
> I think is what I said :)
>
> But its not a property of Pharo.  It is a property of the VM.  In Cog contexts are not actual objects all the time, only when needed.  And Cog runs Pharo images just as it runs Squeak images.  So it would be incorrect to say "in Pharo" and better to say "in the standard Squeak VM".
>
>
> >> There are several applications related with computational reflection
> >> (Reflective Programming, Meta-Programming, MOP, etc) which makes use
> >> of the current context.
> >
> > Also: exception handling, generators, continuations, co-routines, ...
> >
> > For another fun use of "thisContext" check this Stack-Overflow question:
> >
> > http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only-language-to-define-a-whiletrue-message-without-r
> >
> > Lukas
> >
> > --
> > Lukas Renggli
> > www.lukas-renggli.ch
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] Hints and clues for a Pharo newb

stephane ducasse-2

thanks for the explanation  I see the intention.
I was curious.

Stef

On Apr 22, 2010, at 6:55 PM, Eliot Miranda wrote:

>
>
> On Thu, Apr 22, 2010 at 12:49 AM, stephane ducasse <[hidden email]> wrote:
>
> > Yes.  But MethodContext behaves differently depending on whether its closureOrNil inst var is nil (a normal method) or a BlockClosure (an activation of a block).  If nil, ^-returns return to the context's sender.  If not nil ^-returns return from the home context, found by following the outerContext chain through the closureOrNil inst var.  So we no longer need BlockContext.
>
>
> Hi Elliot
>
> I was wondering why you do not use two classes and you do the nil check?
>
> One reason is backward compatibility.  The existing VM ensures that closureOrNil (which used to be called receiverMap) is nil.  The other is the internal workings of the VM.  The nil test is done by the VM on every ^-return.  The VM isn't going to waste time sending a message.  It is going to do a nil test.
>
> In fact in Cog the VM doesn't even do a nil test since in machine code the JIT knows at compile time whether an ^-return is within a block or not, and in the stack interpreter whether a frame is a block activation is indicated by a status bit in the method field of a frame.
>
> So don't think Smalltalk code, think optimized VM internals.  We're not going to waste time instantiating some object just to tag a structure as not being a block activation.
>
> HTH
> Eliot
>  
>
> > This also means we only need one context class, and some time I'd like to merge the two ContextPart and MethodContext classes into a single Context class.  Possibly the name should be ExecutionContext or MethodOrBlockContext or?  Suggestions?
> >
> >
> > Now, test yourself before evaluating :) what should be the result of
> > this expression?
> >
> > [: arg | arg perform: #isExecutingBlock ] value: thisContext
> >
> > It depends on whether the expression is executed at method level or at block level.  As a test this should be:
> >
> > testIsExecutingBlock
> >     self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == false.
> >     [self assert: ([: arg | arg perform: #isExecutingBlock ] value: thisContext) == true] value
> >
> > Can somebody justify the result?
> >
> > isExecutingBlock answers if the receiver is executing a block or not. It does not answer whether the context in which isExecutingBlock is sent is executing a block or not.  Remember that
> >
> >     [:arg| arg == thisContext] value: thisContext
> >
> > is false.  thisContext is rebound within every actual method or block scope.
> >
> > HTH
> >
> > Eliot
> >
> >
> > >> Context creation is optimized in the VM in most Smalltalks, so it's
> > >> only really created as an object in the environment (reified) when
> > >> it's specifically needed through "thisContext".
> > >
> > > In Pharo contexts are not reified like that. Stack-frames are actual
> > > objects at all times. However, for speed reasons, their creation and
> > > garbage-collection is optimized by the VM. Stack frames get
> > > automatically recycled if nobody refers to them.
> > >
> >
> > I think is what I said :)
> >
> > But its not a property of Pharo.  It is a property of the VM.  In Cog contexts are not actual objects all the time, only when needed.  And Cog runs Pharo images just as it runs Squeak images.  So it would be incorrect to say "in Pharo" and better to say "in the standard Squeak VM".
> >
> >
> > >> There are several applications related with computational reflection
> > >> (Reflective Programming, Meta-Programming, MOP, etc) which makes use
> > >> of the current context.
> > >
> > > Also: exception handling, generators, continuations, co-routines, ...
> > >
> > > For another fun use of "thisContext" check this Stack-Overflow question:
> > >
> > > http://stackoverflow.com/questions/2500483/is-there-a-way-in-a-message-only-language-to-define-a-whiletrue-message-without-r
> > >
> > > Lukas
> > >
> > > --
> > > Lukas Renggli
> > > www.lukas-renggli.ch
> > >
> > > _______________________________________________
> > > Pharo-project mailing list
> > > [hidden email]
> > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> > >
> >
> > _______________________________________________
> > Pharo-project mailing list
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> >
>
>