Google SoC Series: Web-based Rails Debugger

Posted by Werner Schuster on Apr 25, 2007 11:00 AM

Community

Ruby

Topics

Debugging ,

Ruby on Rails

Tags

Seaside ,

Google Summer of Code

Rails has had tools for debugging for a long time. The simplest way is to put

breakpoint

in your code; when this line is executed, Rails allows to attach irb (Ruby's interactive shell) to the Rails process to have a look around the system. Other tools and IDEs are also starting to feature Ruby and Rails debugging support and GUI front ends for Ruby debuggers. A Google Summer of Code (SoC) project by Eugen Minciu aims to improve the workflow involved in debugging Rails. InfoQ caught up with Eugen to get the details of his plans. Asked for an overview of the project, Eugen explains

As the summary suggests, this project aims to enhance the debugging capabilities for Rails apps. I'm not interested in developing a full Ruby debugger, since some projects have already addressed this issue. Instead I intend to enable debugging sessions over a browser. It is also one of my goals to find a solution for the breakpoint problem Rails debugging is currently experiencing. So, what I'd like is to have a web-based debugging session that lets you inspect the variables in the event of any error. Furthermore, you should automatically get such a session (or at least a link to such a session) whenever you encounter an exception in your Rails application, or a breakpoint you have set up. This is inspired by my playing with LISP which always lets you inspect an error as soon as it is encountered in your code. That creates a nice workflow, and I want the same type of workflow when working with Rails applications.

When asked how the tools would be deployed, Eugen explains:

The "backend" (the part that enables the Binding.of_caller) should be provided as a gem, as it can be widely usable even if you don't want this kind of integration in your application. I'd prefer to have the whole thing packaged as a gem, since, a developer would only need to download the code once (and upgrade it once) for a machine, and not once for each application on that machine. If that isn't possible, however, I'm willing to make the "frontend" part of this project a plugin.

As explanation, objects of the Ruby Binding class encapsulate the context of Ruby code. "Binding" is a computer science term for a mapping from symbols/names to concrete objects. Capturing and keeping these bindings around or simply getting the bindings of arbitrary method invocations is necessary for tools like debuggers. For instance, debuggers use this to show the call stack of a suspended program, and allow to inspect the variables of the methods stack frames.

When it comes to web based Rails debugging, there already is a project called Gyre. Gyre is an an IDE implemented as web application. It allows to view the Rails application's source in the browser, and to set breakpoints easily in this source view. It ist still at an alpha stage. Eugen:

I must admit I have not, until now, heard of Gyre, so I've looked it up, watched the screencasts and it all appears to be pretty impressive. However, the workflow of keeping a separate web app running just for debugging doesn't sound all that nice, and placing breakpoints through a browser doesn't really strike me as an incredibly cool thing to do. The Gyre console, however, looks really nice, I'll be sure to look at how that's implemented, and I would love to interact with more people while doing this project, so I might get in touch.

The first steps in the project will be to work on something like "Try Ruby", a web based version of the Ruby's irb that allows to quickly try out some Ruby code. Eugen:

It would be nice to provide some web-based GUI to control the flow of the application (stepping, watches, etc.) , as well as seeing the source code in a separate region on screen. I've thought about these possibilities but I'm going to wait until I have a fully working IRB-like console and work from there on.

Some ideas might come from the Smalltalk Seaside web framework. Seaside allows to have program with HTML GUI components, and allows for components at debug time to have special context menus ("Halos") to inspect the state of the component. While this might not be possible in Rails, Eugen is open for ideas:

As for something like Seaside halos ... I don't know, I can't really imagine how it would be done. Seaside follows a completely different path for a web-application framework. Rails doesn't have anything like those "components", so I don't know how I could provide special context menus for various parts of the view. It would be nice to have a context menu on a per-view level, but I don't really have that much imagination as to what I'd put in them. I am however, very willing to experiment with any ideas that might come from anyone else.

One way to watch the progress of the project is Eugen's weblog.

• Older >