Debug from irb

Things are simpler in rbdbgr. To debug a loaded function inside irb:

Debugger.debug{ Columnize.columnize(%w(1 2 2) }

Compare this with ruby-debug, to debug a loaded you might use:

Debugger.start{  debugger; Columnize.columnize(%w(1 2 2)) }

The start method causes extra overhead in stack tracking to start inside the block and this is turned off when the block finishes. In rbdbgr there is no start or stop. To cause a block to be debugged use the Debugger::debug singleton method. An initial call to debugger is not needed, so the above becomes:

An entire session:

$ irb
>> require 'rbdbgr'
=> true
>> Debugger.debug{Columnize.columnize(%w(1 2 3))}
-> (/usr/local/lib/ruby/gems/1.9.1/gems/columnize-0.3.1/lib/columnize.rb:56)
def columnize(list, displaywidth=80, colsep = '  ', 
(rbdbgr): finish
<- (/usr/local/lib/ruby/gems/1.9.1/gems/columnize-0.3.1/lib/columnize.rb:213)
end
(rbdbgr): info return
Return value: "1  2  3\n"
(rbdbgr): c
=> "1  2  3\n"

If you are in irb from the debugger and then want to issue a debugger command, use dbgr. For example

  dbgr %w(info program)
  dbgr('info', 'program') # Same as above
  dbgr 'info program'     # Single quoted string also works

But arguments have to be quoted because irb will evaluate them:

  dbgr info program     # wrong!
  dbgr info, program    # wrong!
  dbgr(info, program)   # What I say 3 times is wrong!

Here is an entire session:

  $ rbdbgr /tmp/foo.rb

  — (/tmp/foo.rb:1)

  x = 1

  (rbdbgr): irb

  You are in a rbdbgr session. You should have access to program scope.

  ‘dbgr’, ‘step’, ‘n’, ‘q’, ‘cont’ commands have been added.

  You should have access to debugger state via global variable $rbdbgr

  rbdbgr >> dbgr ‘info program’

  Program stop event: line; PC offset 2 of instruction sequence: <top /tmp/foo.rb>

  => false

  rbdbgr >>