RFC: debugger command to eval the current line

[Rocky Bernstein]

I often find that what I want to do inside a debugger is eval the statement that is about to be run to check it. 

Two things occur to me. 

First, I can add a command to do just that. The name "eval" comes to mind, using that name would mean when "auto eval" is on that you wouldn't be able to use an unadorned "eval" to get Kerne#eval on the debugger command line. (Recall however that one can always force an evaluation prefacing the command with !, e.g. 

   ! eval "This is what I want to eval". 

So perhaps one might select for this new debugger command a name other than "eval". 

Second, often I want to modify that command slightly and then run that. If Readline is in effect, I supposed I can define a key that tells the debugger to place in the input'able area the current source code line. Hey, I can even add the leading '!' to make it unambiguous. 

[Roger Pack]

So perhaps one might select for this new debugger command a name other than "eval". 

If you let users drop into irb then they can run the original eval.

One thing I wish is that you can eval with semicolons, with current ruby-debug doesn't allow :)

a = 3; a * 3; a ** 4
 

[Rocky Bernstein]

Semicolons are allowed in the trepan debuggers. It is for that reason that if you want to run two debugger comands on one line you use a double semicolon. See "help syntax" for details of debugger command syntax.

Dropping into irb has been in the treppanning debuggers a while as well.

$ trepan irb

-- (/usr/local/bin/irb:9 @2)

require "irb"

(trepan): @a=1; @b=2; @c=3

D=> 3

(trepan): [@a,@b,@c]

D=> [1, 2, 3]

(trepan): info program ;; show autoeval

Program stop event: line; PC offset 2 of instruction sequence: <top /usr/local/bin/irb>

Evaluation of unrecognized debugger commands is on.

(trepan): irb

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

'dbgr', 'step', 'ne', 'q', 'cont' commands have been added.

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

trepan >> 

[Rocky Bernstein]

The trepanning debugger command "eval" without any args is now (in git) used to mean evaluate the current source line. 

[Rocky Bernstein]

A little follow up on adding an eval command without arguments to mean eval the current source line. 

It's now in the trepanning debuggers. I like it so much that I'll may add it to some of the other debuggers I work on as well. 

After trying a bit, I see that many times I am at the beginning of an "if", "until", "elsif" or "while" block and want to test the condition. So what I would like to do here is to strip off the leading "if" or "elsif" and run the rest. 

For this I added a feature that if you alias a command ending in ? to "eval", then those reserved words are strip off the current source line. By default "eval?" and "ev?" are aliased to eval.

More generally, I think of these things as a work-around for a more general desire that one would like  be able to handle reverse execution. This is a harder and adding it would add much more overhead. 

So I should also here one mention related command in the trepanning debuggers which look backwards: "set trace buffer" and "show trace buffer *n*". 

On Tue, Feb 8, 2011 at 1:08 PM, Rocky Bernstein <roc...@rubyforge.org> wrote:

[Roger Pack]

> A little follow up on adding an eval command without arguments to mean eval the current source line.

One command I've always wished for is "step into the method that is at the current line, without actually moving the PC to that line [pre-evalling it, but stepping into it, if that makes sense]. Maybe that would be possible with the new stuff...
-r

[Rocky Bernstein]

In Python's stock debugger it is called "nested debugging". That's in trepanning for patched YARV 1.9.2 using the "debug" command.  I don't think it is possible yet or don't know how to do it yet in Rubinius. 

[Rocky Bernstein]

On Mon, May 30, 2011 at 4:27 PM, rogerdpack <rogerp...@gmail.com> wrote:

> In Python's stock debugger it is called "nested debugging". That's in
> trepanning for patched YARV 1.9.2 using the "debug" command.  I don't think
> it is possible yet or don't know how to do it yet in Rubinius.

What about with ruby-debug19 et al?  Man I sorely miss this :)

 

I don't know how to do this without adding some sort of API or run-time support to MRI.