Show HN: pry-rescue — workflow-optimized debugging for ruby(cirw.in)
cirw.in
Show HN: pry-rescue — workflow-optimized debugging for ruby
http://cirw.in/blog/pry-to-the-rescue
10 comments
Same story as the Lisp folks. Good ideas need to be wrapped up in easy-to-understand, small packages for them to be picked up by the more mainstream languages.
Ruby is pretty much an unholy mix of Perl + Smalltalk + a sprinkling of Lisp with an extreme syntactic sugar-bomb on top to start with. At least in terms of inspirations.
And I say that mostly as a compliment (though I still find the Ruby grammar atrocious from an implementation point of view).
And I say that mostly as a compliment (though I still find the Ruby grammar atrocious from an implementation point of view).
> And I say that mostly as a compliment (though I still find the Ruby grammar atrocious from an implementation point of view).
I think there is something deep embodied here. Syntactic sugar items for languages are like features for libraries. It's been said that if everyone is completely happy with a library's features, the library maintainers haven't been doing their job.
I think there is something deep embodied here. Syntactic sugar items for languages are like features for libraries. It's been said that if everyone is completely happy with a library's features, the library maintainers haven't been doing their job.
This is awesome work, thanks!
Just throwing this out there, I know a bit about the difficulties this would entail, but: Is it plausible to have something like this running in production mode?
I mean, if I had a production Rack app running and could have pry-rescue (somehow) save its state and bubble the exception up normally, and later connect to the process and inspect what went wrong. Would something like this be feasible?
Just throwing this out there, I know a bit about the difficulties this would entail, but: Is it plausible to have something like this running in production mode?
I mean, if I had a production Rack app running and could have pry-rescue (somehow) save its state and bubble the exception up normally, and later connect to the process and inspect what went wrong. Would something like this be feasible?
Yes :). I'm not exactly sure of the details, but I certainly want to try! See https://github.com/mrbrdo/rack-webconsole: there's already a rack-webconsole-pry, so it should be an easy step to hook it up to past exceptions.
Thanks for this. How would I use it in Rails? Any tips for integration?
In rails you can just do:
class ApplicationController < ActionController::Base
around_filter :pry_rescue if Rails.env == 'development'
def pry_rescue
Pry::rescue{ yield }
end
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
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?
Are there any difference to https://github.com/pry/pry-exception_explorer ?
pry-rescue is a modernization thereof (banisterfiend helped me build it).
The only technical difference is that pry-rescue can catch exceptions raised at the C level (like NoMethodError, or ZeroDivisionError); but pry-rescue also has a much easier-to-learn API/UI. (Particularly, by only supporting catching unhandled exceptions, pry-rescue can avoid the need to predicate on which exceptions should be handled).
The only technical difference is that pry-rescue can catch exceptions raised at the C level (like NoMethodError, or ZeroDivisionError); but pry-rescue also has a much easier-to-learn API/UI. (Particularly, by only supporting catching unhandled exceptions, pry-rescue can avoid the need to predicate on which exceptions should be handled).
Yes. Actually, pry-rescue not only imbibes pry-exception_explorer's power, but also provides its own possibilities. pry-rescue catches everything (even syntax errors).
Why does anyone think that multiple columns for a single story are a good idea on the web?
Exclusively for you, my friend :)
Fix for Chrome (Stylebot): http://goo.gl/9qoeF
Fix for Firefox (Stylish): http://goo.gl/6tkpz
Fix for Chrome (Stylebot): http://goo.gl/9qoeF
Fix for Firefox (Stylish): http://goo.gl/6tkpz
If you resize your browser to make it smaller it renders as one column.
No need to be snarky. Just calmly state that you find the column layout to be difficult to read.
Wow, pry and its plugins universe gets better each day.
If you're new to pry I recommend you check pry-remote & pry-debugger.
If you're new to pry I recommend you check pry-remote & pry-debugger.
For python, ipython --pdb <derp.py> 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.
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?
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?
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.
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.
Possibly :) tab-completion will be substantially improved in an upcoming release :)
Great! looking forward to it. :)
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.
This is really cool. Looking forward to a rails version of the gem!
The pry console gives you access to the method that raised the exception, you can use it to inspect the values of variables (no more print statements!), the source code of methods (no more flapping around with a text editor!), and even move up and down the call stack (like a real debugger!).
Basically what we were doing in Smalltalk for decades and trying to tell people about. (To a remarkable degree of push-back and vitriol.) Many years ago, one of our community pointed out that while it lost out as a mainstream platform, Smalltalk actually won the war of ideas. (It's taking quite a long time for everyone else to catch up, however. People keep thinking they've gotten there when they're still a good 1/3rd short.)