I’m trying to avoid stepping through the code line by line. I’d like to
get a big-picture view if possible. Also, similar to the OP, I don’t
want to modify the code being inspected either.
Trying to boil it down to my main “feature” I’m trying to implement, I
think it’s removing all intermediate steps between writing code and
seeing its output. But not just its output – also how it got there.
Also, I personally find it tedious to navigate with the keyboard and
type the variable names I want to inspect in the exact spot I want to
inspect them. So I want to be able to avoid that. I’d much rather have
some kind of overlay on top of my source that I can just glance at or
maybe mouse-over.
With current tools, my co-workers and I end up using things like
autotest or guard to detect when a file is saved and then re-run the
tests. The test output is displayed in a terminal, optionally reported
to Growl. When it gets slow loading all those gem dependencies, we use
spork.
This is all fine. I can edit files. I can point my Gemfile to a dir with
:path and add debugger/pry breakpoints or prints, or even edit the
installed gem if needed. I can inspect any value. I just feel it’s
inconvenient. For one, I have to be sure to remove all the breakpoints
b/c they should never make it to production, but there are other issues.
So I thought I’d try to experiment with something else.
This may not be for everyone, but I feel that my ideal development
workflow needs continual evaluation and to reflect the source code back
to me with test values filled in. It doesn’t need to capture all the
data of all the execution flow. As someone pointed out, that would be a
lot of data, and not very useful.
Also, a test (unit, functional, etc.) will print out a bad value that is
asserted. However, I specifically avoid assertions on intermediate
values which are implementation-dependent, because they make tests
brittle. But these intermediate values are often very useful in fixing
the final result. So I’d like to be able to easily see the
intermediate values without having to manually add and remove inspects
or step through the debugger every time.
Anyway, I know it helps to understand a person’s context and motivation
when helping them. So that’s mine. It’s more of a hunch of what I think
might be useful. And I’m trying to make it to find out for sure.
I obviously don’t want to re-implement the Ruby interpreter, and I’d
like to avoid patching it. So when I found set_trace_func, it seemed to
be a good match. However, it calls your proc with file and line number.
This may be fine for a traditional debugger that simply echoes back your
source as a string. But I want to actually parse the code so that I can
do interesting things with it. set_trace_func’s “line” event doesn’t map
perfectly to the parsed AST. The most recent case I’ve run into is an
if-else-end statement that spans multiple lines but is used as an
expression to assign to a variable.
1: result = if some_true_val
2: ‘yes’
3: else
4: ‘no’
5: end
6: puts result
I think set_trace_func is giving me one “line” event for line 1, then
line 2, then line 6. However, according to the actual AST, the
assignment is on line 1, and necessarily must occur after executing
line 2. This is what I mean by saying that they don’t map perfectly. For
my experiment, this mapping is what the majority of the code deals with.
As for the actual UI, I’ve considered using MacRuby. But I’ve found that
MacRuby doesn’t support set_trace_func. So maybe this is the wrong route
to head down.
Anyway, if the OP isn’t listening, I don’t really have a specific
question for the mailing list. …Except maybe this:
Is anyone working on a “Light Table” for Ruby?
