Smalltalk › Pharo › Pharo Smalltalk Developers

Better #haltOnce: per haltOnce state, auto-enable

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

11 messages Options

Marcus Denker-4

Better #haltOnce: per haltOnce state, auto-enable

Hi,

Yesterday we improved #haltOnce to be more like a “once” BreakPoint:

-> state per *each* haltOnce send
(this means you can put two in one method and they are independent)
-> when putting a haltOnce, it is enabled by default
-> The global menu entry just resets all haltOnce to be active again.

Interesting is how trivial this was to implement… in class Halt
once
| node |
node := thisContext sender sender sourceNodeExecuted.
(node hasProperty: #haltOnce) ifTrue: [^self].
node propertyAt: #haltOnce put: true.
^ self signal.

This means, we get the AST node of the “haltOnce” message send. Then we put an annotation there.
To reset all (enable all), the global many just does:

#haltOnce senders do: #recompile.

Done.

This will be in 60082.

Marcus

Tudor Girba-2

Re: Better #haltOnce: per haltOnce state, auto-enable

Wow!

I particularly love how straightforward it is to distinguish between two haltOnce.

Amazing work.

Cheers,
Doru

> On Jun 14, 2016, at 9:47 AM, [hidden email] wrote:
>
> Hi,
>
> Yesterday we improved #haltOnce to be more like a “once” BreakPoint:
>
> -> state per *each* haltOnce send
> (this means you can put two in one method and they are independent)
> -> when putting a haltOnce, it is enabled by default
> -> The global menu entry just resets all haltOnce to be active again.
>
> Interesting is how trivial this was to implement… in class Halt
> once
> | node |
> node := thisContext sender sender sourceNodeExecuted.
> (node hasProperty: #haltOnce) ifTrue: [^self].
> node propertyAt: #haltOnce put: true.
> ^ self signal.
>
>
> This means, we get the AST node of the “haltOnce” message send. Then we put an annotation there.
> To reset all (enable all), the global many just does:
>
> #haltOnce senders do: #recompile.
>
> Done.
>
> This will be in 60082.
>
> Marcus
>
>
>

--
www.tudorgirba.com
www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem understanding."

Marcus Denker-4

Re: Better #haltOnce: per haltOnce state, auto-enable

In reply to this post by Marcus Denker-4

> On 14 Jun 2016, at 09:47, [hidden email] wrote:
>
> Hi,
>
> Yesterday we improved #haltOnce to be more like a “once” BreakPoint:
>
> -> state per *each* haltOnce send
> (this means you can put two in one method and they are independent)
> -> when putting a haltOnce, it is enabled by default
> -> The global menu entry just resets all haltOnce to be active again.
>
> Interesting is how trivial this was to implement… in class Halt
> once
> | node |
> node := thisContext sender sender sourceNodeExecuted.
> (node hasProperty: #haltOnce) ifTrue: [^self].
> node propertyAt: #haltOnce put: true.
> ^ self signal.
>
>
> This means, we get the AST node of the “haltOnce” message send. Then we put an annotation there.

haltOnCount: can be implemented using AST send-site per node state, too:

onCount: anInteger
"Halt on the anInteger-th time through"
<debuggerCompleteToSender>
| node |
node := thisContext sender sender sourceNodeExecuted.
(node hasProperty: #haltCount) ifFalse: [
node propertyAt: #haltCount put: 0.
].
node propertyAt: #haltCount put: (node propertyAt: #haltCount) + 1.
((node propertyAt: #haltCount) = anInteger) ifTrue: [ ^self signal ].

Marcus

Eliot Miranda-2

Re: Better #haltOnce: per haltOnce state, auto-enable

Marcus,

On Fri, Jun 17, 2016 at 4:03 AM, Marcus Denker <[hidden email]> wrote:

> On 14 Jun 2016, at 09:47, [hidden email] wrote:
>
> Hi,
>
> Yesterday we improved #haltOnce to be more like a “once” BreakPoint:
>
> -> state per *each* haltOnce send
> (this means you can put two in one method and they are independent)
> -> when putting a haltOnce, it is enabled by default
> -> The global menu entry just resets all haltOnce to be active again.
>
> Interesting is how trivial this was to implement… in class Halt
> once
> | node |
> node := thisContext sender sender sourceNodeExecuted.
> (node hasProperty: #haltOnce) ifTrue: [^self].
> node propertyAt: #haltOnce put: true.
> ^ self signal.
>
>
> This means, we get the AST node of the “haltOnce” message send. Then we put an annotation there.

haltOnCount: can be implemented using AST send-site per node state, too:

onCount: anInteger
"Halt on the anInteger-th time through"
<debuggerCompleteToSender>
| node |
node := thisContext sender sender sourceNodeExecuted.
(node hasProperty: #haltCount) ifFalse: [
node propertyAt: #haltCount put: 0.
].
node propertyAt: #haltCount put: (node propertyAt: #haltCount) + 1.
((node propertyAt: #haltCount) = anInteger) ifTrue: [ ^self signal ].

Marcus

Yes, but using the byte code pc is a much much cheaper key, and just as unique.

_,,,^..^,,,_

best, Eliot

Marcus Denker-4

Re: Better #haltOnce: per haltOnce state, auto-enable

On 18 Jun 2016, at 05:29, Eliot Miranda <[hidden email]> wrote:

Marcus,

Marcus

Yes, but using the byte code pc is a much much cheaper key, and just as unique.

But why would I care to make this efficient? It’s a debug feature…

And doing it on the AST is very nice for other reasons, e.g. as I next step I will

add icons in the Editor for all the halt sends. For haltOnce, this will show the state

and toggle the haltOnce to be “on” again.

The editor uses the AST for this, and therefore it can be done with just 5 lines of code.

In general the question is: Am I willing to pay in terms of resources for abstraction?

Marcus

Marcus Denker-4

Re: Better #haltOnce: per haltOnce state, auto-enable

On 18 Jun 2016, at 06:55, Marcus Denker <[hidden email]> wrote:

On 18 Jun 2016, at 05:29, Eliot Miranda <[hidden email]> wrote:

Marcus,

Marcus

Yes, but using the byte code pc is a much much cheaper key, and just as unique.

But why would I care to make this efficient? It’s a debug feature…

And doing it on the AST is very nice for other reasons, e.g. as I next step I will
add icons in the Editor for all the halt sends. For haltOnce, this will show the state
and toggle the haltOnce to be “on” again.

So, first version (to be improved)… could this be implemented in term of byte code offset. Of course.

Would it be nice? I doubt.

Eliot Miranda-2

Re: Better #haltOnce: per haltOnce state, auto-enable

On Sat, Jun 18, 2016 at 12:17 AM, Marcus Denker <[hidden email]> wrote:

On 18 Jun 2016, at 06:55, Marcus Denker <[hidden email]> wrote:

On 18 Jun 2016, at 05:29, Eliot Miranda <[hidden email]> wrote:

Marcus,

Marcus

Yes, but using the byte code pc is a much much cheaper key, and just as unique.

But why would I care to make this efficient? It’s a debug feature…

And doing it on the AST is very nice for other reasons, e.g. as I next step I will
add icons in the Editor for all the halt sends. For haltOnce, this will show the state
and toggle the haltOnce to be “on” again.

So, first version (to be improved)… could this be implemented in term of byte code offset. Of course.
Would it be nice? I doubt.

Alas, poor Occam. I knew him well.

_,,,^..^,,,_

best, Eliot

Marcus Denker-4

Re: Better #haltOnce: per haltOnce state, auto-enable

In reply to this post by Marcus Denker-4

Hi,

Another small iteration: now you can mouse over the Icon of #halOnce and #haltOnCount: and the
current state is displayed (if the haltOnce is active, the count of the #haltOnCount:).

this is in 60 update 101

Marcus

Tudor Girba-2

Re: Better #haltOnce: per haltOnce state, auto-enable

Awesome!

Doru

> On Jun 21, 2016, at 11:19 AM, Marcus Denker <[hidden email]> wrote:
>
> Hi,
>
> Another small iteration: now you can mouse over the Icon of #halOnce and #haltOnCount: and the
> current state is displayed (if the haltOnce is active, the count of the #haltOnCount:).
>
> this is in 60 update 101
>
> Marcus

--
www.tudorgirba.com
www.feenk.com

"It's not how it is, it is how we see it."

stepharo

Re: Better #haltOnce: per haltOnce state, auto-enable

In reply to this post by Marcus Denker-4

marcus

do you expect to have object centric debugging features in the near future?

Stef

Le 21/6/16 à 11:19, Marcus Denker a écrit :
> Hi,
>
> Another small iteration: now you can mouse over the Icon of #halOnce and #haltOnCount: and the
> current state is displayed (if the haltOnce is active, the count of the #haltOnCount:).
>
> this is in 60 update 101
>
> Marcus
>

Marcus Denker-4

Re: Better #haltOnce: per haltOnce state, auto-enable

> On 21 Jun 2016, at 16:48, stepharo <[hidden email]> wrote:
>
> marcus
>
> do you expect to have object centric debugging features in the near future?
>

Yes, we have already support for it using conditions on meta links… I want to use
that first and later look into optimising (so the condition doe not slow down all the
other objects). But for debugging, it should be ok.

Marcus