RadRails goes 1.0 - adds Profiler, CallGraph Analyzer, Rails Shell, etc.

RadRails, part of the Aptana IDE, is now available in version 1.0. The popular Rails development tool has been around for some time, but this latest version adds some useful new features for Ruby, as well as Ruby on Rails developers. A full comparison of features between RadRails, Netbeans and CodeGear's 3rdRail is available as well, and shows RadRails with more support for refactoring and profiling. Another RadRails feature is the Rails Shell, which allow to issue Rails commands from inside the Eclipse IDE - this is complete with AutoComplete for arguments for the commands and more. (A screencast showing the features of the Rails Shell is available.).

We talked to Christopher Williams of Aptana about the new release. Christopher was hired by Aptana 2007 to continue his work on the Ruby Development Tools (RDT) which are the base for RadRails. 

RadRails 1.0 supports profiling Ruby code, complete with a GUI showing of the runtimes of methods and a call graph. Christopher explains how this is implemented:

The Profiler is basically a wrapper around the ruby-prof gem. We wrap execution of ruby scripts through the ruby-prof bin script and direct it's output to a temporary file. Then when execution is finished we grab the output, parse it and generate the Call Graph and Hot Spots views. This is not yet available for JRuby as there is not yet an equivalent ruby-prof gem with Java in place of the native C code. If that were created, we'd support that right away.

In terms of what's ahead for that functionality: We may work on a modified ruby-prof gem that would act in a manner similar to the ruby-debug-ide gem for ruby-debug - basically allowing a remote connection to the profiler and sending profiling related commands in real-time over a socket (so we could take snapshots, instead of just grabbing output when the app finishes). Or maybe creating that JRuby compatible ruby-prof. It really depends on what our users are looking for. It's a brand new feature so we're just starting to get requests for enhancements.

RDT has long supported debugging Ruby code in the Eclipse debugger GUI, complete with the faster ruby-debug support. RadRails also ships with jruby-debug, a faster implementation of the JRuby debugging support:

Yes, with RadRails 1.0 we now support the JRuby version of the ruby-debug gem - so there's a fast JRuby debugging option now. We actually pre-install it into the JRuby we ship.

The RadRails 1.0 feature list includes the name "Rubinius" as supported Ruby interpreter. Christopher explains the state of the support right now:

At this point it's pretty much limited to using Rubinius as the interpreter for launching Ruby processes. As Rubinius grows more powerful it'll be more useful to try out gems and eventually Rails with it. There's no real Rubinius specific features at this point (though really there aren't any JRuby or Std Ruby specific features either. We try to support each interpreter as fully as the next. With JRuby and Rubinius it's usually a matter of waiting for a new gem or updated code to be able to enable more functionality).

If a large number of users start trying out Rubinius and start telling us they miss the debugger, we could certainly work to integrate with their debugger. When we created the debugger for Ruby using ruby-debug we worked with Kent Sibilev and Martin Krauskopf (of Sun, for Netbeans) to share our code - which resulted in a set of common libraries for IDEs to integrate with ruby-debug. So there's already a sort of de-facto standard for integrating RDT/RadRails and Netbeans with a debugging backend. It'd be a matter of hooking up Rubinius's debugger to open a socket and read these XML commands in. (If anyone wanted to work on that, please contact me and/or Martin. It'd effectively make the Rubinius debugger work on both Netbeans and RDT/RadRails in one fell swoop).

The common debugging protocol implementation is available at RubyForge in the debug-commons project. InfoQ reported about Rubinius' Full Speed Debugger - this is currently not supported by the common debugging protocols, as it needs a different protocol backend to make use of the Full Speed Debugger's API.

Despite RadRails's obvious connection to Ruby on Rails development, it might support other frameworks in the future as well:

At this point we haven't had any major requests for other frameworks. Obviously we're focused on Rails, but under the hood we have a fully functional Ruby IDE (built with RDT). If a framework become very popular and users voiced their requests for support of it, then we'd certainly investigate.

On a related note, a number of users have been using Brad Wilson's HAML and SASS editors. Unfortunately recent releases have broken it's integration with RDT, and Brad hasn't had time to keep it up to date. We're working with him to fold his editors into RadRails itself so that we can maintain them (and possibly improve upon them).

RadRails and Aptana are scriptable with Ruby using EclipseMonkey - Christopher discusses the idea behind this feature:

 When I created the integration between EclipseMonkey and JRuby I was hoping that we'd get a lot of people who took a look and say "Hey wow, I can script the IDE in Ruby now!". But so far the community hasn't really embraced it to the degree I'd expected. [..] [I saw] that for an end-user they could now iteratively develop new features without a compile step and no need to really download the Eclipse SDK and check out all our source code and then go puzzle over it forever. You just write Ruby/JRuby code, run the script, edit it, re-run and so on. And with the DOMs we can provide a smaller simpler API to play with, that will look and feel like a Ruby API.

To get started with Aptana and RadRails 1.0 or simply see the features in action, screencasts are available for a large part of the feature set.