From: Gavin Sinclair <gsinclair@...>
Date: 2002-10-21T02:08:56+09:00
Subject: Re: Is the debugger broken?

From: "Gavin Sinclair" <gsinclair@soyabean.com.au> [snipped]

> ... that is no way to run a debugger.  Using iterators is very common in Ruby
> programming.  While defining breakpoints to step through iterator code in a
> logical fashion may (and it's a stretch) be acceptable once or twice, it is
too
> painful when you have nested iterators.
>
> i.e. we have a C-like debugger for a non-C-like language.

I'd like to follow up my own post with a constructive suggestion.  How about
adding these commands to the debugger:

1  nl: goes to next physical line of file, no matter what

2  step method: steps into given method

The first one would be useful for stepping through code containing iterators
that, according to [ruby-talk:53622], is not adequately debuggable with the
current command set.  This could be implemented by setting a breakpoint for the
next line, continuing, and discarding the breakpoint.

The second one is an unrelated suggestion that would ease the debugging of
lines containing several methods.  For example:

    arr.map { |x| f(x) }.reject { |x| predicate?(x) }.sort { |a,b| order(a) <=>
order(b) }

There are three user-defined methods in that one line: f, predicate?, and
order.  If you wanted to step into :order, then you would have to step through
:f and :predicate? first, or set a breakpoint at the beginning of the
definition of :order.  It would be nicer to be able to say "step order" - "s o"
for short - to achieve this instead.  This would be easy to implement as well:
the "step" command clearly must know what it's stepping into.

Gavin