On Wed, Mar 1, 2017 at 10:06 AM, Offray Vladimir Luna C��rdenas <offray.luna@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.luna@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