debugger command integration

[banister]

Hey guy, great work on this gem btw,

I was wondering if you'd consider integrating commands like next and step and so on into pry itself, and having pry actually wrap the debugger (rather than the other way round) for more seamless use?

THat would be pretty damn awesome ;) I contact the ruby-debug maintainer asking him how to go about accessing the next and step functionality, but he hasnt responded to me yet :(

anyway, just a few thoughts!

keep up the good work!

[AndrewO]

I'd definitely like to integrate next and step as Pry commands and looking at the ruby-debug irb command, I think it should be possible. ruby-debug-pry was pretty much extracted from that code and IIRC a lot of the wackiness in that original code to support those commands was due to IRB's somewhat odd API. Thankfully, pry is cleaner. :)

I'm not sure if I'm onboard though with the idea of wrapping the debugger (rather than the debugger wrapping pry). Just for background, here's how I'm used to debugger:

1. require 'ruby-debug' somewhere in the development mode of the application
2. insert a debugger where I want to debug
3. run the program until the debug prompt comes up
4. use ruby-debug's other commands to set other breakpoints, list current code, get the current stack trace, eval one-liners, next, and step
5. if I want to do anything beyond a one-liner, pry into a REPL (previously irb, but we all know pry is better :)

(I know I could be using the rdebug command and setting breakpoints outside of code, but I've found this to be the easiest thing for my development style.)

If I understand what you're suggesting, that would look more like:

1. require 'pry' in dev mode
2. insert a binding.pry where I want to debug
3. run until the pry prompt comes up
4. run all of those commands in pry

What I like about the way I'm already doing it is that ruby-debug is good at moving through the running process, whereas I find pry is great for inspecting the code and a snapshot of the current state of the process. I like the idea of a different context for those two things. For me, pry is a supercharged IRB with great customizability and a beautiful interface. Whereas the ruby-debug prompt is good at what it does, albeit not as nice looking as pry.

Implementing next and step within pry would be good time saving shortcuts, but I'm not sure if I like the idea of getting rid of the debugger prompt entirely (if that is what you're suggesting). My mind isn't completely made up on the issue, but that's what I'm thinking right now.

[banister]

you do make good arguments :)

nonetheless i feel that a repl/debugger are so close in some ways that it
feels slightly anomalous not to merge them, as i think they are merged in
smalltalk and lisp (by way of SLIME). It would be interesting to actually
research smalltalk/slime to see how they accomplish this blend of
repl/debugger.

On a related note, you may be interested in this sister project to your own

• a pure ruby debugger for pry. I dont think it's really competing with your
  project as there are some serious limitations to a pure ruby debugger, but
  nonetheless you may find it interesting
  https://github.com/Mon-Ouie/pry_debug

On Fri, Jun 17, 2011 at 4:37 AM, AndrewO <
reply@reply.github.com>wrote:

I'd definitely like to integrate next and step as Pry commands and
looking at the ruby-debug irb command, I think it should be possible.
ruby-debug-pry was pretty much extracted from that code and IIRC a lot of
the wackiness in that original code to support those commands was due to
IRB's somewhat odd API. Thankfully, pry is cleaner. :)

I'm not sure if I'm onboard though with the idea of wrapping the debugger
(rather than the debugger wrapping pry). Just for background, here's how I'm
used to debugger:

1. require 'ruby-debug' somewhere in the development mode of the
   application
2. insert a debugger where I want to debug
3. run the program until the debug prompt comes up
4. use ruby-debug's other commands to set other breakpoints, list current
   code, get the current stack trace, eval one-liners, next, and step
5. if I want to do anything beyond a one-liner, pry into a REPL
   (previously irb, but we all know pry is better :)

(I know I could be using the rdebug command and setting breakpoints outside
of code, but I've found this to be the easiest thing for my development
style.)

If I understand what you're suggesting, that would look more like:

1. require 'pry' in dev mode
2. insert a binding.pry where I want to debug
3. run until the pry prompt comes up
4. run all of those commands in pry

What I like about the way I'm already doing it is that ruby-debug is good
at moving through the running process, whereas I find pry is great for
inspecting the code and a snapshot of the current state of the process. I
like the idea of a different context for those two things. For me, pry is a
supercharged IRB with great customizability and a beautiful interface.
Whereas the ruby-debug prompt is good at what it does, albeit not as nice
looking as pry.

Implementing next and step within pry would be good time saving
shortcuts, but I'm not sure if I like the idea of getting rid of the
debugger prompt entirely (if that is what you're suggesting). My mind isn't
completely made up on the issue, but that's what I'm thinking right now.

Reply to this email directly or view it on GitHub:
#1 (comment)

[AndrewO]

I've played with SLIME a few times, but the idea of mucking with the running system scared me off—probably because I was trying to learn Lisp and Emacs at the same time. :) Being more comfortable with Ruby, that shouldn't be a problem.

I'm really interested in the potential for interactive development that Pry enables. Like you said, this seems to be a road that's been pretty well trod by SLIME and Smalltalk's tools. Having not used those, I can't say exactly how I'd go about making a good environment, but I'm sure there's a lot of lessons to be learned there. (If there's a group already working on something like that based on Pry, I'd love to hear about it.)

The idea of a pure ruby debugger is pretty appealing, especially given that ruby-debug seems a bit complex in some places. Also, I would love to have a single debugging library that worked across rubies without native code. I'll take a look. You can probably tell, I'm not philosophically wed to ruby-debug, it's just the tool I'm used to.

So, I think the way I'm going to handle this ticket is keep it open until I add next and step. After that I'll take a closer look at pry_debug. If it's something I can get behind, it might render any need for further development moot.

[banister]

yo, any further progress on next and step ? i haven't been able to figure it out myself yet, wondered if you have:)

[AndrewO]

I haven't had a chance to look into it. I've actually been using PryDebug recently. :)

I'm not 100% it's what I prefer, but suffice it to say, it's been keeping me from looking into this. I'll see if I can take a look sometime within the next week or so.

[ndbroadbent]

Hi, just reading this article, which mentioned the pry-nav gem, which provides the step, next, and continue commands.

But I just looked at PryDebug, which also has step and next. So I'm quite confused. I'd like to use pry as my debugger, but the opinions seem to be very scattered...

Should I just use PryDebug?

[banister]

@ndbroadbent it depends what you want, pry_debug is a standalone project that just uses Pry internally, whereas pry-nav is a plugin for Pry and integrates better into ordinary Pry usage. It's up to you. :)

[ndbroadbent]

Thanks for your reply. Ok, so they're just the same feature, packaged in different ways.

Alright, well, I think I will follow the Setting up Rails to use Pry guide, and use the pry-nav plugin.

Thanks for your help!

[MSch]

Any updates on this? Now that someone forked & fixed ruby-debug I'd like to use pry with it :)

https://github.com/cldwalker/debugger

[AndrewO]

I, personally haven't had a chance to look at this in awhile. Most of my work now has either been on my own projects (where I tend to use pry exclusively) or with a client who hasn't approved pry for internal use (yet--there's been some encouraging movement though!).

I hate to be one of those people that releases something open source and lets it rot, but here I am. If anyone is willing to step up, let me know.

[Xylakant]

The fix to get the current functionality in debugger is simple and straightforward - it's mainly changing the requires. Since this gem does not depend on ruby-debug, it should be possible to use this gem with debugger without changes. See Asquera@d9e1720

[banister]

ported to debugger here: https://github.com/pry/debugger-pry

Also a gem is pushed: gem install debugger-pry

:)