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
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, marcus.denker@inria.fr 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."
On 14 Jun 2016, at 09:47, marcus.denker@inria.fr 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
Marcus, On Fri, Jun 17, 2016 at 4:03 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 14 Jun 2016, at 09:47, marcus.denker@inria.fr 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
On 18 Jun 2016, at 05:29, Eliot Miranda <eliot.miranda@gmail.com> 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
On 18 Jun 2016, at 06:55, Marcus Denker <marcus.denker@inria.fr> wrote:
On 18 Jun 2016, at 05:29, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> 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.
On Sat, Jun 18, 2016 at 12:17 AM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 18 Jun 2016, at 06:55, Marcus Denker <marcus.denker@inria.fr> wrote:
On 18 Jun 2016, at 05:29, Eliot Miranda <eliot.miranda@gmail.com> 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
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
Awesome! Doru
On Jun 21, 2016, at 11:19 AM, Marcus Denker <marcus.denker@inria.fr> 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."
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
On 21 Jun 2016, at 16:48, stepharo <stepharo@free.fr> 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
participants (5)
-
Eliot Miranda -
Marcus Denker -
marcus.denker＠inria.fr
-
stepharo -
Tudor Girba