The Trunk: Kernel-dtl.331.mcz

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

The Trunk: Kernel-dtl.331.mcz

commits-2
David T. Lewis uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-dtl.331.mcz

==================== Summary ====================

Name: Kernel-dtl.331
Author: dtl
Time: 18 December 2009, 11:32:44 am
UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e
Ancestors: Kernel-bs.330

Add BlockClosure>>sender required for MessageTally class>>tallySends:

Harvested from Pharo (nice 4/14/2009 19:09).

=============== Diff against Kernel-bs.330 ===============

Item was added:
+ ----- Method: BlockClosure>>sender (in category 'debugger access') -----
+ sender
+ "Answer the context that sent the message that created the receiver."
+
+ ^outerContext sender!


Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.331.mcz

Eliot Miranda-2
Hi David,

    Interesting!  To my mind that definition is incorrect.  I would expect the sender of a block to be the sender of the enclosing method, in which case the definition would arguably be

BlockClosure methods for accessing
sender
^self home sender

A block activation's caller would be it's sender slot, so within a block you might refer to thisContext caller.  But what is arguably a bug in my implementation is that within a block activation thisContext sender refers to the caller (the sender of value: to the activation's block) not to the sender of the enclosing method.

I think I may have screwed up badly here and that the correct implementations should be

MethodContext methods for accessing
caller
^closureOrNil
ifNil: [self error: 'this is a method activation and so has no caller']
ifNotNil: [sender]

sender
^closureOrNil
ifNil: [sender]
ifNotNil: [closureOrNil outerContext sender]

BlockClosure methods for accessing
sender
^outerContext sender

and either

BlockClosure methods for accessing
caller
"Since a BlockClosure is by definition not an activation it does not have a caller.
 It has a sender because it is always created within the context of a method."
^nil

or

BlockClosure methods for accessing
caller
^self error: 'this is an inactive block and so has no caller'


I believe the pre-closure definitions are
ContextPart methods for accessing
sender
^sender

BlockContext methods for accessing
caller
^sender

which to my mind is missing

BlockContext methods for accessing
sender
^home sender

What do people think the right definitions should be?

On Fri, Dec 18, 2009 at 8:36 PM, <[hidden email]> wrote:
David T. Lewis uploaded a new version of Kernel to project The Trunk:
http://source.squeak.org/trunk/Kernel-dtl.331.mcz

==================== Summary ====================

Name: Kernel-dtl.331
Author: dtl
Time: 18 December 2009, 11:32:44 am
UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e
Ancestors: Kernel-bs.330

Add BlockClosure>>sender required for MessageTally class>>tallySends:

Harvested from Pharo (nice 4/14/2009 19:09).

=============== Diff against Kernel-bs.330 ===============

Item was added:
+ ----- Method: BlockClosure>>sender (in category 'debugger access') -----
+ sender
+       "Answer the context that sent the message that created the receiver."
+
+       ^outerContext sender!





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.331.mcz

Andreas.Raab
Eliot Miranda wrote:

>     Interesting!  To my mind that definition is incorrect.  I would
> expect the sender of a block to be the sender of the enclosing method,
> in which case the definition would arguably be
>
> BlockClosure methods for accessing
> sender
> ^self home sender
>
> A block activation's caller would be it's sender slot, so within a block
> you might refer to thisContext caller.  But what is arguably a bug in my
> implementation is that within a block activation thisContext sender
> refers to the caller (the sender of value: to the activation's block)
> not to the sender of the enclosing method.

How about instead of faking out BlockClosure>>sender we fix MessageTally
along the lines of:

MessageTally>>tallySendsTo:inBlock:showTree:

   prev := aBlock asContextWithSender: thisContext.

This should work just as well if I understand the intent of the change
correctly.

Cheers,
   - Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Re: The Trunk: Kernel-dtl.331.mcz

David T. Lewis
On Sat, Dec 19, 2009 at 01:12:25PM +0100, Andreas Raab wrote:

> Eliot Miranda wrote:
> >    Interesting!  To my mind that definition is incorrect.  I would
> >expect the sender of a block to be the sender of the enclosing method,
> >in which case the definition would arguably be
> >
> >BlockClosure methods for accessing
> >sender
> >^self home sender
> >
> >A block activation's caller would be it's sender slot, so within a block
> >you might refer to thisContext caller.  But what is arguably a bug in my
> >implementation is that within a block activation thisContext sender
> >refers to the caller (the sender of value: to the activation's block)
> >not to the sender of the enclosing method.
>
> How about instead of faking out BlockClosure>>sender we fix MessageTally
> along the lines of:
>
> MessageTally>>tallySendsTo:inBlock:showTree:
>
>   prev := aBlock asContextWithSender: thisContext.
>
> This should work just as well if I understand the intent of the change
> correctly.

FYI, Nicolas Cellier is the original author, I just copied his
implementation into Squeak because I noticed the broken MessageTally.

Dave
 

Reply | Threaded
Open this post in threaded view
|

Re: Re: The Trunk: Kernel-dtl.331.mcz

Eliot Miranda-2
In reply to this post by Andreas.Raab


On Sat, Dec 19, 2009 at 4:12 AM, Andreas Raab <[hidden email]> wrote:
Eliot Miranda wrote:
   Interesting!  To my mind that definition is incorrect.  I would expect the sender of a block to be the sender of the enclosing method, in which case the definition would arguably be

BlockClosure methods for accessing
sender
^self home sender

A block activation's caller would be it's sender slot, so within a block you might refer to thisContext caller.  But what is arguably a bug in my implementation is that within a block activation thisContext sender refers to the caller (the sender of value: to the activation's block) not to the sender of the enclosing method.

How about instead of faking out BlockClosure>>sender we fix MessageTally along the lines of:

MessageTally>>tallySendsTo:inBlock:showTree:

 prev := aBlock asContextWithSender: thisContext.

This should work just as well if I understand the intent of the change correctly.

That's right.  In the Teleplace codebase we simply use asContext:

tallySendsTo: receiver inBlock: aBlock showTree: treeOption
...
thisContext sender
runSimulated: (prev := aBlock asContext)
contextAtEachStep:
[:current |
...
 

Cheers,
 - Andreas





Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.331.mcz

Igor Stasenko
In reply to this post by Eliot Miranda-2
2009/12/19 Eliot Miranda <[hidden email]>:

> Hi David,
>     Interesting!  To my mind that definition is incorrect.  I would expect
> the sender of a block to be the sender of the enclosing method, in which
> case the definition would arguably be
> BlockClosure methods for accessing
> sender
> ^self home sender
> A block activation's caller would be it's sender slot, so within a block you
> might refer to thisContext caller.  But what is arguably a bug in my
> implementation is that within a block activation thisContext sender refers
> to the caller (the sender of value: to the activation's block) not to the
> sender of the enclosing method.
> I think I may have screwed up badly here and that the correct
> implementations should be
> MethodContext methods for accessing
> caller
> ^closureOrNil
> ifNil: [self error: 'this is a method activation and so has no caller']
> ifNotNil: [sender]
> sender
> ^closureOrNil
> ifNil: [sender]
> ifNotNil: [closureOrNil outerContext sender]
> BlockClosure methods for accessing
> sender
> ^outerContext sender
> and either
> BlockClosure methods for accessing
> caller
> "Since a BlockClosure is by definition not an activation it does not have a
> caller.
>  It has a sender because it is always created within the context of a
> method."
> ^nil
> or
> BlockClosure methods for accessing
> caller
> ^self error: 'this is an inactive block and so has no caller'
>
> I believe the pre-closure definitions are
> ContextPart methods for accessing
> sender
> ^sender
> BlockContext methods for accessing
> caller
> ^sender
> which to my mind is missing
> BlockContext methods for accessing
> sender
> ^home sender
> What do people think the right definitions should be?


i think the intent of this fix was to match the:

|x y |
x := thisContext sender.
[ y := thisContext sender ] value.
x == y

Since thisContext variable value depending on scope, where it used.

The really interesting question to answer is:

either we threat thisContext as implicitly declared in method's scope only:

someMethod
| thisContext |

[ [ [ [ x := thisContext ] ] ] ]

or threat as implicitly (re)declared at each level of scoping:

someMethod
| thisContext |

[| thisContext | [| thisContext | [| thisContext | [| thisContext | x
:= thisContext ] ] ] ]


> On Fri, Dec 18, 2009 at 8:36 PM, <[hidden email]> wrote:
>>
>> David T. Lewis uploaded a new version of Kernel to project The Trunk:
>> http://source.squeak.org/trunk/Kernel-dtl.331.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Kernel-dtl.331
>> Author: dtl
>> Time: 18 December 2009, 11:32:44 am
>> UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e
>> Ancestors: Kernel-bs.330
>>
>> Add BlockClosure>>sender required for MessageTally class>>tallySends:
>>
>> Harvested from Pharo (nice 4/14/2009 19:09).
>>
>> =============== Diff against Kernel-bs.330 ===============
>>
>> Item was added:
>> + ----- Method: BlockClosure>>sender (in category 'debugger access') -----
>> + sender
>> +       "Answer the context that sent the message that created the
>> receiver."
>> +
>> +       ^outerContext sender!
>>
>>
>
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: The Trunk: Kernel-dtl.331.mcz

Eliot Miranda-2


On Wed, Dec 23, 2009 at 12:27 PM, Igor Stasenko <[hidden email]> wrote:
2009/12/19 Eliot Miranda <[hidden email]>:
> Hi David,
>     Interesting!  To my mind that definition is incorrect.  I would expect
> the sender of a block to be the sender of the enclosing method, in which
> case the definition would arguably be
> BlockClosure methods for accessing
> sender
> ^self home sender
> A block activation's caller would be it's sender slot, so within a block you
> might refer to thisContext caller.  But what is arguably a bug in my
> implementation is that within a block activation thisContext sender refers
> to the caller (the sender of value: to the activation's block) not to the
> sender of the enclosing method.
> I think I may have screwed up badly here and that the correct
> implementations should be
> MethodContext methods for accessing
> caller
> ^closureOrNil
> ifNil: [self error: 'this is a method activation and so has no caller']
> ifNotNil: [sender]
> sender
> ^closureOrNil
> ifNil: [sender]
> ifNotNil: [closureOrNil outerContext sender]
> BlockClosure methods for accessing
> sender
> ^outerContext sender
> and either
> BlockClosure methods for accessing
> caller
> "Since a BlockClosure is by definition not an activation it does not have a
> caller.
>  It has a sender because it is always created within the context of a
> method."
> ^nil
> or
> BlockClosure methods for accessing
> caller
> ^self error: 'this is an inactive block and so has no caller'
>
> I believe the pre-closure definitions are
> ContextPart methods for accessing
> sender
> ^sender
> BlockContext methods for accessing
> caller
> ^sender
> which to my mind is missing
> BlockContext methods for accessing
> sender
> ^home sender
> What do people think the right definitions should be?


i think the intent of this fix was to match the:

|x y |
x := thisContext sender.
[ y := thisContext sender ] value.
x == y

NI don't think so.  Within a block thisContext is not a BlockClosure but a MethodContext (note not a BlockContext).  The fix was for BlockClosure not ContextPart et al.  Again "[] home sender" is the right approach (see below).

(*) That it is a MethodContext is a historical accident.  My closure implementation discards BlockContext.  Some time we should merge ContextPart and MethodContext into a single class Context.


Since thisContext variable value depending on scope, where it used.

The really interesting question to answer is:

either we threat thisContext as implicitly declared in method's scope only:

someMethod
| thisContext |

[ [ [ [ x := thisContext ] ] ] ]

or threat as implicitly (re)declared at each level of scoping:

someMethod
| thisContext |

[| thisContext | [| thisContext | [| thisContext | [| thisContext | x
:= thisContext ] ] ] ]

Not so interesting :)  It has to be the latter because you have to be able to name the current context.  If you need to mention the former you write "thisContext home".  And so "aClosureOrContext home sender" will answer the enclosing method activation's sending context for both blocks and contexts.



> On Fri, Dec 18, 2009 at 8:36 PM, <[hidden email]> wrote:
>>
>> David T. Lewis uploaded a new version of Kernel to project The Trunk:
>> http://source.squeak.org/trunk/Kernel-dtl.331.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Kernel-dtl.331
>> Author: dtl
>> Time: 18 December 2009, 11:32:44 am
>> UUID: 20ffffda-86bc-47a7-8eae-cd11b55aa65e
>> Ancestors: Kernel-bs.330
>>
>> Add BlockClosure>>sender required for MessageTally class>>tallySends:
>>
>> Harvested from Pharo (nice 4/14/2009 19:09).
>>
>> =============== Diff against Kernel-bs.330 ===============
>>
>> Item was added:
>> + ----- Method: BlockClosure>>sender (in category 'debugger access') -----
>> + sender
>> +       "Answer the context that sent the message that created the
>> receiver."
>> +
>> +       ^outerContext sender!
>>
>>
>
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.