the blog
Back to -Blog

Ruby Debugging In Steel - Now Watch The Movie!

by Huw Collingbourne
Monday 15 May 2006.

Just a couple of weeks away now from the next public beta (0.6) of Ruby In Steel. We thought you might like to see a preview of the debugging features in this version so I just recorded a short Flash movie illustrating a few of its capabilities. The movie is about 6 minutes long and is around 2.5Mb in size. It gives you a quick tour of breakpoints, locals, the auto window, step-into, step-over, evaluating expressions in the interactive console and the call stack.

Watch the Movie

Bookmark and Share   Keywords:  ide
  • Ruby Debugging In Steel - Now Watch The Movie!
    11 June 2006

    Hi, I havent used steel, but from the video, looks very impressive. Its just great to know we have great minds who can make nice software. Thanks Ruby Learner

  • Finally, someone understands!
    20 May 2006, by joe

    Hi Huw —

    Finally someone gets it! After years of Java development with real tools (VisualAge, Eclipse, IntelliJ IDEA) I find myself working as a professional Ruby on Rails developer with stone-age tools. RDT and RadRails have good test running support (green-bar/red-bar) but 99% of the functionality I use is built-in Eclipse navigation. The thing I miss more than anything (even refactoring support and control-click navigation) is the debugger, since I have traditionally learned the most about how a system works by stepping through it in the debugger and seeing all of the objects in action (am I crazy?). It’s true that RDT has debugger support, but it’s painfully slow in Rails and is preconfigured to halt on all errors, which Rails throws constantly.

    Thank you thank you thank you for building a REAL Ruby IDE!!!!

    • Finally, someone understands!
      21 May 2006, by Dermot

      I agree with you 100% about the debugger. I’ve never been able to understand how people can code efficiently without a good one. In my view, you can only code at the speed you can debug (I’m not taking about design, btw - that’s a totally different thing).

      I had a first look at Eclipse the other day and it really does look nice - cool and clean and very easy to work with. However, the one think I did see was missing (I couldn’t see it anyway) was the ’Edit-and-Continue’ feature of VS. This really does make for fast development, fixing all those annoying and timeconsuming ’out-by-one’ indexing errors.

      I’m going to figure out a way of doing that in Ruby - even if I have to hook the evaluator itself.


      • Finally, someone understands!
        21 May 2006, by lel4866

        A question about the debugger -

        I’ve tried ruby - r debug, Actibve State Komodo, RDT, Arachno Ruby, Freeride. The only one that isn’t painfully slow in debug mode is Arachno - and they use a modified version of Ruby.

        Is the debugging speed reasonable? That is, if it takes 5 seconds when not running a Ruby program through a debugger to get to a print statement, will it also take about 5 seconds to get to the breakpoint on the print statement when the program is run in debug mode?

        • Finally, someone understands!
          21 May 2006, by Dermot

          No, its slow. It’s the basic system used by Ruby itself and Komodo, etc, so its of the same order of magnitude.

          Arachno does have a faster one, but he has had to modify the interpreter, which is bad news. The latest one on his site was 1.8.3 (when I last looked). If you modify the interpreter, you end up having to support it and the end-user ends up depending on your support. I really don’t want to do that if I can avoid it - I’d rather leave it to Matz. It’s not a good idea, and to be avoided if at all possible.

          We will be producing a much faster debugger - and I think I’ve figured out a way of doing it without having to silo the Ruby interpreter. But that’s after we’ve done Rails support and other nice bits for Visual Studio.


© SapphireSteel Software 2014