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.
Show HN: pry-rescue — workflow-optimized debugging for ruby
21–30 of 31 posts
Re: Show HN: pry-rescue — workflow-optimized debugging for ruby
#22If you're new to pry I recommend you check pry-remote & pry-debugger.
Re: Show HN: pry-rescue — workflow-optimized debugging for ruby
#23For python, ipython --pdb does the trick. Don't forget to install ipdb too, much nicer than plain pdb.
Re: Show HN: pry-rescue — workflow-optimized debugging for ruby
#24Re: Show HN: pry-rescue — workflow-optimized debugging for ruby
#25I assume this won't work with Pow as it would require binding.remote_pry?
Re: Show HN: pry-rescue — workflow-optimized debugging for ruby
#26Earlier 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"
Re: Show HN: pry-rescue — workflow-optimized debugging for ruby
#27For 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…
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
#28Earlier 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…
Re: Show HN: pry-rescue — workflow-optimized debugging for ruby
#29Earlier 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.
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
#30Earlier 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…