Reputation: 6649
When, during a pry debug session, I want to inspect step-by-step execution of FooClass.new.foo
I'd do this in pry console
$ FooClass.new.foo #this gives me path and line of the method
break /path/to/foo_class.rb:LINE_WHERE_FOO_IS_DEFINED
FooClass.new.foo
This works but I need to look for the path, line and it leaves a breakpoint I sometimes have to remove.
There's a faster way:
break FooClass#foo
FooClass.new.foo
but it's still two steps, and the breakpoint stays.
Is there a way to do it in one command, like
step-into FooClass.new.foo
which would start a Pry subsession, enter the method execution and after it exits/finishes I'm back in the original session with no extra breakpoints left?
In other words: I'm in the middle of debugging, and see a method called few lines before (I can't step into it immediately). I don't want to put a binding.pry
in the source (it may take a lot of time to start the debugging session again).
Upvotes: 7
Views: 1422
Reputation: 99
The problem has hidden complexity. For instance, one thing you can do is:
pry Foo.new.foo
or
Foo.new.foo.pry
This puts you into a binding on the return value of the function foo
, but that is not what you want. It also shows there is complexity when your line of code Foo.new.foo
runs, for a function to know what exactly to put a binding on.
So that's really the problem I feel; it would take understanding of the expression on the line to understand where to put a breakpoint. If you imagine it was working like the step
function.
If your code Foo.new.foo
was already a break point (e.g. you had a function with that code in and you put a breakpoint on a line like that) then you typed step
, you would go into Foo.new
Foo.initialize
instance of foo
foo.foo
and so on. So, any code trying to do what you would like it to do would have a very hard time understanding where in the expression tree to stop and put your into pry
.
This is why you have to tell pry
where to stop using break
in this context.
Upvotes: 1