On Wed, Mar 1, 2017 at 10:06 AM, Offray Vladimir Luna Cárdenas <
offray.l...@mutabit.com> wrote:
>
> On 28/02/17 02:12, Ben Coman wrote:
>
>
>
> On Tue, Feb 28, 2017 at 11:28 AM, Offray Vladimir Luna Cárdenas <
> offray.l...@mutabit.com> wrote:
>
>> Hi,
>>
>> I would like to store the object resulting from executing a playground.
>> This would imply two steps:
>>
>> - Knowing that the playground content was executed (via the play button
>> or its shortcuts Ctrl + Shift + g or Ctrl + g).
>> - Getting the results of that execution. For example if the result at the
>> end is a string or a dictionary, I would like to get that string or
>> dictionary.
>>
>> Any pointers on how to make that will be welcomed.
>>
>> Cheers,
>>
>> Offray
>>
>> Ps: I still get lost when I search by myself trying to answer questions
>> like the ones above. I imagine that in some way is related with
>> evaluationAction and presentations, by looking for the source code of "do
>> it and go", but still I can't get a functional code snippet to start
>> prototyping.
>>
>>
> In playground, if you evaluate "self halt. 42" at top of the debug stack
> you'll see method...
> Undefined>>DoIt
> self halt.
> ^ 42
>
> where stepping
> OVER returns 42 into "value" variable in OpalCompiler>>evaluate
> OVER returns 42 into "result" variable in RubSmalltalkEditor>>evaluate:
> andDo:
> at the end of which stepping
> INTO "^aBlock value: result" takes you to
> RubSmalltalkEditor>>highlightEvaluateAndDo:,
> where
> INTO "[:result | aBlock value: result]" takes you to
> GLMPharoScriptPResentation(GLMRubricSmalltalkCodePresentation)>>
> executionSelectionActions
>
>
> Wow that was pretty insightful! Thanks Ben. I still don't know when to use
> Over or Into,
>
It helps to observe the three types of stepping behavior side by side.
I've devised a little demo.
First, to help keep track of the windows, hack this mod into
RubSmalltalkEditor>>debug:receiver:in:
debugSession := guineaPig newDebugSessionNamed: ('debug ' ,
aCompiledMethod selector printString asUppercase) startedAt: context.
In playground evaluate...
Object subclass: #DebugDemo
instanceVariableNames: ''
classVariableNames: ''
package: 'DebugDemo'.
In playground evaluate...
#('over' 'through' 'into') do: [ :demoMethodName|
DebugDemo compile: demoMethodName , '
x := 0.
#(1 2) do: [:n | x := x + 1].
self inform: x printString.'.
RubSmalltalkEditor new debug: (DebugDemo>>(demoMethodName
asSymbol)) receiver: nil in: nil.
].
Arrange the three debug windows side by side, left to right, OVER, THROUGH,
INTO.
1. Moving left to right, click once on each window's related "step" button
- OVER then THROUGH then INTO.
While views remain the same, repeat 1.
2. When views diverge, keep clicking INTO until it matches THROUGH.
3. While THROUGH and INTO views remain the same, keep alternately clicking
these.
When they diverge return to 2.
When all views are the same, return to 1.
The key thing to observe with the INTO window, is that sending #value: to
the array gets you to the same place as THROUGH got in one step. It skips
through the block support infrastructure.
i think maybe it would help to rearrange the "step" buttons in order of
increasing detail. i.e. OVER, THROUGH, INTO.
Also maybe the "through" icon could be a right arrow inside square brackets
like this... [-->].
That would probably look neater without the underline.
To put the terminology into perspective, I've contrived a poor analogy of...
A method being a path along the ground.
http://www.instructables.com/id/How-to-lay-pathpatiowalkway-and-build-slabs/
Each slab is a message send. Under each slab is an offshoot tunnel with
further slabs along it.
The quickest way down the path is to step OVER each slab(message send)
because you don't care what is happening beneath the slab.
Sometimes you need to know everything that is going on underneath, so you
lift up the slab and go INTO the tunnel and step on each of the slabs in
the tunnel.
Now to stretch the analogy, consider that a block is held at the end #do:
tunnel. You are interested in the individual steps of the block, but not
in all the steps of the tunnel (which is the support infrastructure that
iterates a collection sending #value: to each element), so you fly THROUGH
the tunnel without touching the individual steps, and just step the slabs
of the block held at the end. Phew!
So in summary,
INTO steps into every message send.
OVER and THROUGH are similar, but the first steps over blocks, and the
latter steps through blocks.
HTH,
cheers -ben
