From: Jonathan Tran Date: 2012-09-12T05:22:26+09:00 Subject: Re: Using binding + set_trace_func to capture execution state 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? -- Posted via http://www.ruby-forum.com/.