Question

I am now trying to learn ruby-debug gem, but there are many jargons I am unable to catch up. Wondering if anyone could help with the explanations?

I couldn’t find them in http://bashdb.sourceforge.net/ruby-debug.html either. The author assumed we already understand them (where can I learn about them anyway?).

For example here is a result of calling help frame in rdb. I helplessly don’t understand all the items I bolded.

Move the current frame to the
specified frame number.

A negative number indicates position
from the other end. So ‘frame -1’
moves to the oldest frame, and ‘frame
0’ moves to the newest frame.

Without an argument, the command
prints the current stack frame. Since
the current position is redisplayed,
it may trigger a resyncronization if
there is a front end also watching
over things.

If a thread number is given then we
set the context for evaluating
expressions to that frame of that
thread.

Answer 1

It’s not Ruby-specific jargon; it’s common to most all debugging.

Regarding stack frames

You’ve likely seen stack traces:

/usr/local/rvm/gems/ree-1.8.7-2010.02/gems/redgreen-1.2.2/lib/redgreen.rb:28:in `write': Broken pipe (Errno::EPIPE)
from /usr/local/rvm/gems/ree-1.8.7-2010.02/gems/redgreen-1.2.2/lib/redgreen.rb:28:in `output_single'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:72:in `add_fault'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/ui/console/testrunner.rb:70:in `to_proc'
from /usr/local/rvm/rubies/ree-1.8.7-2010.02/lib/ruby/1.8/test/unit/util/observable.rb:78:in `call'

The full trace shows you the “call stack”. The line at the top is where the exception was thrown, and the lines under it show the path through your code that the program took to get to that point. Each of those lines is a level in the stack, called a “stack frame”. So, when an exception is thrown, the current stack frame is the top of the stack. If you move to frame -1 then you’re moving to the bottom of the call stack. Think of the call stack like a stack of plates. When you call a function, you add a plate to the stack, and when you return out of that function, you remove a plate from the stack. Each plate is a frame. Since you usually end up calling functions within functions within functions, you end up with fairly deep call stacks, and walking up and down them can be useful in debugging, to evaluate local variables and state at each point in the call stack.

If you’d like to read up more on call stacks, Wikipedia has a nice article.

Regarding threads

Most all modern programming languages are multi-threaded, meaning that they can execute multiple code paths (almost) concurrently. So, imagine for example that you have a visual app, and you perform some expensive computation. Your GUI won’t be able to react to any user input while that computation is running, which makes the application appear to be frozen to the user. You would solve this by running two threads: One thread would be responsible for accepting and handling user input and painting the GUI, and the other thread would be responsible for doing your heavy computation. Your compute thread could be stuck in an expensive loop and your GUI thread would keep running and painting the GUI.

If you are running a multi-threaded application, then you you have to select which thread you want to evaluate your debug commands (expressions) in, since each thread will be in different points of your code, and will have different call stacks and different local variables and state and such. This is the evaluation context.

However, I noticed that this is a Rails question, and Rails is (by default) single-threaded, so you shouldn’t need to worry about threads.