Live data from Hacker News

Show HN: pry-rescue — workflow-optimized debugging for ruby

cirw.in

21–30 of 31 posts

Re: Show HN: pry-rescue — workflow-optimized debugging for ruby

#21

is there any way to make this compatible with ruby 1.8.7? Seems like just what I need, but haven't upgraded my current app with a newer version of ruby.

It is :). The "up" and "down" command won't work, and there are a few bugs with NoMethodError's, but the core functionality is very much there.

Re: Show HN: pry-rescue — workflow-optimized debugging for ruby

#23

For python, ipython --pdb does the trick. Don't forget to install ipdb too, much nicer than plain pdb.

Not sure it's quite the same. My understanding is that `ipython --pdb` would run the entire program in debugging mode, causing a dramatic slow-down in performance of the app. The approach taken by pry-rescue in contrast is to check for exceptions in a bounded portion of code (as many bounded portions as you want), so the slow-down is constrained to hot spots. This potentially makes pry-rescue OK for production use, something perhaps not suitable for ipython --pdb afaict.

Re: Show HN: pry-rescue — workflow-optimized debugging for ruby

#26
post #4
post #3

Earlier quoted context omitted.

In rails you can just do: class ApplicationController I'm hoping to get a Rack middleware out at some point; which will make this even easier.

Here's a basic middleware... pry_rescue.rb require 'pry/rescue' class PryRescue def initialize(app) @app = app end def call(env) Pry::rescue{ @app.call(env) } end end For rails you need to require the file and use the middleware... application.rb config.middleware.use "PryRescue"

I know this is short and simple, but it still might be nice to wrap up in a gem. Or maybe work into the pry-rails gem?

Re: Show HN: pry-rescue — workflow-optimized debugging for ruby

#27

For python, ipython --pdb does the trick. Don't forget to install ipdb too, much nicer than plain pdb.

Not sure it's quite the same. My understanding is that `ipython --pdb` would run the entire program in debugging mode, causing a dramatic slow-down in performance of the app. The approach taken by pry-rescue in contrast is to check for exceptions in a bounded portion of code (as many bounded portions as you want), so the slow-down is constrained to hot spots. This potentially makes pry-rescue OK for production use, s…

you're probably right, and it sounds like a nice idea to create an exception wrapper that on exception does `import ipdb; ipdb.set_trace()`.

However, having worked with both pry and ipython / ipdb, the difference in responsiveness and performance is quite significant and very noticeable between the two. ipython / ipdb feels faster by an order of magnitude. The most obvious difference is tab-completion. Perhaps this is enhanced even more comparing rails to django (the stacks I used pry and ipdb with, respectively)...

I guess at least tab-completion slowness is down to the fact that by its nature ruby has far many more functions that can run on any object than python, and hence more options to tab-complete?

Re: Show HN: pry-rescue — workflow-optimized debugging for ruby

#28

Earlier quoted context omitted.

Not sure it's quite the same. My understanding is that `ipython --pdb` would run the entire program in debugging mode, causing a dramatic slow-down in performance of the app. The approach taken by pry-rescue in contrast is to check for exceptions in a bounded portion of code (as many bounded portions as you want), so the slow-down is constrained to hot spots. This potentially makes pry-rescue OK for production use, s…

you're probably right, and it sounds like a nice idea to create an exception wrapper that on exception does `import ipdb; ipdb.set_trace()`. However, having worked with both pry and ipython / ipdb, the difference in responsiveness and performance is quite significant and very noticeable between the two. ipython / ipdb feels faster by an order of magnitude. The most obvious difference is tab-completion. Perhaps this i…

hmm, weird. Aside from tab-completion what else is slow? I've never had responsiveness issues with Pry, even tab completion is snappy.

Re: Show HN: pry-rescue — workflow-optimized debugging for ruby

#29

Earlier quoted context omitted.

you're probably right, and it sounds like a nice idea to create an exception wrapper that on exception does `import ipdb; ipdb.set_trace()`. However, having worked with both pry and ipython / ipdb, the difference in responsiveness and performance is quite significant and very noticeable between the two. ipython / ipdb feels faster by an order of magnitude. The most obvious difference is tab-completion. Perhaps this i…

hmm, weird. Aside from tab-completion what else is slow? I've never had responsiveness issues with Pry, even tab completion is snappy.

I actually think it's mostly rails, not pry. I'm still new to rails and ruby, but somehow it feels much slower than django. Just loading the console feels like forever compared to the django shell.

However, regarding tab completion. I just did a quick test and noticed a small but important difference. Clicking tab in ipython instantly shows you the available completions. in pry, most of the time I have to click twice to see them! maybe that's what makes it feel slow to me.

Re: Show HN: pry-rescue — workflow-optimized debugging for ruby

#30

Earlier quoted context omitted.

hmm, weird. Aside from tab-completion what else is slow? I've never had responsiveness issues with Pry, even tab completion is snappy.

I actually think it's mostly rails, not pry. I'm still new to rails and ruby, but somehow it feels much slower than django. Just loading the console feels like forever compared to the django shell. However, regarding tab completion. I just did a quick test and noticed a small but important difference. Clicking tab in ipython instantly shows you the available completions. in pry, most of the time I have to click twice…

Possibly :) tab-completion will be substantially improved in an upcoming release :)
Post reply on HN