Smalltalk - How to "skip" messages when debugging

Author

How to "skip" messages when debugging

Karl-Heinz Fandrey

2005-02-16, 4:05 pm

Hello,

I have a dream that would simplify debugging of forwarding/dispatching code.
Imagen that we use a dispatching method like

MyDispatchingClass>>dispatch: aString to: aValueHolder
avalueHolder value perform: aString asSymbol

When using this functionality, I don't want the debugger to step into this
dispatching method but step immediatly into the following message. I.e. if
I press "Step Into" within

MyClass>>test
(MyDispatchingClass new) dispatch: 'printString' to: 1 asValue

I want the debugger to stop in

Integer>>printString

Is there a way to achieve this currently? Or does anybody can give me a hint
how to implement those behavior? I would like something like tagging the
method with a pragma to mark where stepInto should occur, e.g.

MyDispatchingClass>>dispatch: aString to: aValueHolder
<stepInto: #perform>
avalueHolder value perform: aString asSymbol

Of course, this should work also for nested methods!

Thanks,

Willi

Terry Raymond

2005-02-18, 3:59 am

Willi

Your best bet would be to create another step
button. If you look at the debugger code that
does the step-into-block you will see that in some
places it continues bytecode simulation until it
finds the correct method. You want to do this
sort of thing. However, you are also creating
a potential problem. What happens if you hit
the button when it will never encounter your special
method, will it keep running forever?

Karl-Heinz Fandrey <auchWilli@t-online.de> wrote in
news:cv05s3$ru7$02$1@news.t-online.com:

> Hello,
>
> I have a dream that would simplify debugging of forwarding/dispatching
> code. Imagen that we use a dispatching method like
>
> MyDispatchingClass>>dispatch: aString to: aValueHolder
> avalueHolder value perform: aString asSymbol
>
> When using this functionality, I don't want the debugger to step into
> this dispatching method but step immediatly into the following
> message. I.e. if I press "Step Into" within
>
> MyClass>>test
> (MyDispatchingClass new) dispatch: 'printString' to: 1 asValue
>
> I want the debugger to stop in
>
> Integer>>printString
>
> Is there a way to achieve this currently? Or does anybody can give me
> a hint how to implement those behavior? I would like something like
> tagging the method with a pragma to mark where stepInto should occur,
> e.g.
>
> MyDispatchingClass>>dispatch: aString to: aValueHolder
> <stepInto: #perform>
> avalueHolder value perform: aString asSymbol
>
> Of course, this should work also for nested methods!
>
> Thanks,
>
> Willi

Karl-Heinz Fandrey

2005-02-19, 3:58 am

Terry Raymond <traymond-nospam-at-craftedsmalltalk-dot-com> wrote:

> Willi
>
> Your best bet would be to create another step
> button. If you look at the debugger code that

creating a special button sound reasonable but in practice you must know
that you are running into a dispatching node. If this is done implicitely
by some kind of doesNotUnderstand: you have to know in advance. But
probably it would be a good choice to add a button the does not skip those
methods.

> does the step-into-block you will see that in some
> places it continues bytecode simulation until it
> finds the correct method. You want to do this

Btw. can you give me any hint how to debug the debugger? A pure breakpoint
is not very helpful at this. Maybe some kind of conditional probe?

> sort of thing. However, you are also creating
> a potential problem. What happens if you hit
> the button when it will never encounter your special
> method, will it keep running forever?

Right, I never thought about this because my approach was related to clear
sequential code. However, a typing mistake would cause the same. Primarely
I see two options. Either immediately return and behave like "step" or
detect this as an debugging/coding issue and break before return to
investigate the issue. I guess this depends on experiences about the most
common issue of this kind.

Thanks so far,

Willi

Terry Raymond

2005-02-19, 3:58 pm

Karl-Heinz Fandrey <auchWilli@t-online.de> wrote in
news:cv5jec$8tp$02$1@news.t-online.com:

> Terry Raymond <traymond-nospam-at-craftedsmalltalk-dot-com> wrote:
>
>
> creating a special button sound reasonable but in practice you must
> know that you are running into a dispatching node. If this is done
> implicitely by some kind of doesNotUnderstand: you have to know in
> advance. But probably it would be a good choice to add a button the
> does not skip those methods.
>
>
> Btw. can you give me any hint how to debug the debugger? A pure
> breakpoint is not very helpful at this. Maybe some kind of conditional
> probe?

You need to do 2 things.

You need to change the method Process>>debugDebugger to
debugDebugger
self privateDebug

In a conditional breakpoint use the following expression
| p |
p := Processor activeProcess.
[p debugDebugger] forkAt: p priority + 1.
false

When you get the debugger, select the #actOn: method
and do a simple method return.

>
> Right, I never thought about this because my approach was related to
> clear sequential code. However, a typing mistake would cause the same.
> Primarely I see two options. Either immediately return and behave like
> "step" or detect this as an debugging/coding issue and break before
> return to investigate the issue. I guess this depends on experiences
> about the most common issue of this kind.
>
> Thanks so far,
>
> Willi
>

Ian Upright

2005-02-24, 3:59 am

Terry Raymond <traymond-nospam-at-craftedsmalltalk-dot-com> wrote:

>Willi
>
>Your best bet would be to create another step
>button. If you look at the debugger code that
>does the step-into-block you will see that in some
>places it continues bytecode simulation until it
>finds the correct method. You want to do this
>sort of thing. However, you are also creating
>a potential problem. What happens if you hit
>the button when it will never encounter your special
>method, will it keep running forever?

I think I would take a different approach and use a policy of methods that
you want to ignore.. In this case, he wants to ignore:

#perform:
#dispatch:to:

So somewhere (a global?) is a list of methods to skip over. When he steps
into them, it skips over the ones that are set to ignore, and then it ends
up getting to the methods he's interested in, and this is much cleaner and
more dynamic than using something gross like pragmas.

Ian

---
http://www.upright.net/ian/

Karl-Heinz Fandrey

2005-03-02, 4:05 pm

Ian Upright wrote:
> I think I would take a different approach and use a policy of methods that
> you want to ignore.. In this case, he wants to ignore:
>
> #perform:
> #dispatch:to:
>
> So somewhere (a global?) is a list of methods to skip over. When he steps
> into them, it skips over the ones that are set to ignore, and then it ends
> up getting to the methods he's interested in, and this is much cleaner and
> more dynamic than using something gross like pragmas.
>

Hmmm, ... sounds reasonable but it is like Terrys "new button approach",
because it will not really do, what I'm looking for. Let's review the
example from the beginning of the thread:

MyDispatchingClass>>dispatch: aString to: aValueHolder
Â_Â_Â_Â_Â_Â_Â_Â_<stepInto:Â_#perform>
Â_Â_Â_Â_Â_Â_Â_Â_avalueHolderÂ_valueÂ_per
form:Â_aStringÂ_asSymbol

With your approach ... Where do you think will the debugger stop? It want
stop next in the dispatched method as intended, it will stop in
String>>asSymbol. This gets more worse for more complicated dispatching :-(

But anyway, thanks for the idea! Mostly one need more than only one to get
the right choice - probably a combination of all input.

Thanks,

Willi

Sponsored Links