Question

Since there may be a lot of Ghost Methods inside a ruby gem, I don’t think it is a good idea to study the inner mechanism of a ruby gem just by reading its source code statically. Is there a way to attach the source file of a third-part gem to a running ruby process for debugging so that I can set break point and see how things work dynamically ?
BTW,I’ve tried to navigate to the source file of a third-part gem in RubyMine by clicking on the context menu “Go To->Implementations” of the ‘require’ statement or other symbol of an third-part gem( require 'watir' for example ), without success. Is it normal for an IDE of a dynamic typing language such as Ruby to fail a symbol navigation?

Answer 1

I would love to know if there’s a better way to do this, but how I usually do it is:

1. Add the ruby-debug gem to your Gemfile (or ruby-debug19 if you’re on Ruby 1.9.2)
2. Find the Gem by doing bundle show gemname. I’m on a Mac so I usually pipe this to pbcopy so it gets copied to my clipboard. bundle show rails | pbcopy
3. Open the gem directory in your favorite editor. mvim /path/to/gem/directory
4. Navigate to the file and line where you want to put the breakpoint* and insert debugger above the line in question.
5. Reload page, run test, or do whatever you would to get the Gem file to execute
6. When execution stops at debugger, you can inspect variables (p variable_name), and move line by line with the ruby debugger commands.

*Knowing where to put the breakpoint can take some understanding of the code, but you should start in lib/gemname.rb