In the Key of E

NetBeans 6.8 is well on its way, so it's a good time to have a look at what's new in the NB Ruby support. While 6.8 is mostly a bug fixing release for NB Ruby, there are still several new features and enhancements.[Read More]

The following stack trace might be a bit too familiar for those of you who have tried the latest RSpec (1.2.4) with NB 6.5.1:

 from /usr/lib/ruby/gems/1.8/gems/rspec-1.2.4/lib/spec/runner/options.rb:119:in `run_examples'
 from /usr/lib/ruby/gems/1.8/gems/rspec-1.2.4/lib/spec/runner/command_line.rb:9:in `run'
 from /usr/lib/ruby/gems/1.8/gems/rspec-1.2.4/bin/spec:4
 ...

The good news is that the issue is fixed in 6.7 builds and for 6.5.1 you can fix it by downloading this file and copying it to the netbeans_install_dir/ruby2 directory. You may want to make a backup of the existing nb_rspec_mediator.rb file in that directory first.

Update: There was still an issue with running focused tests as reported by Asfand Yar Qazi. I've now changed the link to point to a newer version that should fix that problem.

Martin implemented several type inference improvements for 6.7, but since he hasn't blogged about any of those and I've now continued his work in this area I thought I'd mention some of them in this blog. Basically credit me for everything that works smoothly, for bugs please blame Martin.

There's quite a lot of stuff and I have just so much time and patience to write one blog entry, so this will be more like a series. For the uninitiated, type inference (hereinafter just TI) means that the IDE tries to infer the types of values, which, thanks to the dynamic nature of Ruby, can be a bit tricky at times.

Let's first take a look at TI for constants. Top-level constants:

(ARGV is an Array, hence the code completion dialog shows just the appropriate methods for it.)

(STDOUT is an instance of IO.)

Constants from other modules/classes:

(Date::ITALY is a number.)

And finally, local constants:

That's it for constants, in the next installment of the series I'll talk about TI for methods.

Over the past few weeks I've been working on a couple of editing infrastucture related tasks, one of them being switching our parser to use Tom Enebo's jruby-parser project instead of the patched JRuby we used previously. This brings us, among other things, support for Ruby 1.9. Of course, it has been possible to use 1.9 with NB even before, but it wasn't possible to use any new 1.9 syntax without having syntax errors in the editor.

The steps for enabling 1.9 support in NB depends on whether you use JRuby or MRI.

For JRuby, you need a recent enough version that supports 1.9 -- best to get the latest release, 1.2.0 (note that we already bundle 1.2.0 in 6.7 dev builds). Second, you need to switch JRuby to 1.9 mode, which you can do by using the

-Djruby.compat.version=RUBY1_9

switch. If you have a plain Ruby project, you can add it to the JVM Arguments field in Project Properties -> Run. For a Rails project, you need to add

jvm.args=-Djruby.compat.version=RUBY1_9

to

path_to_your_project dir/nbproject/project.properties.

(Obviously, there needs to be a more user friendly way to do this). Note that if you want to run JRuby in 1.9 mode from the command line, it is as easy as

jruby --1.9 ...

If you use MRI, it is enough to point the project to use a MRI 1.9 platform and the parser will be switched to the 1.9 mode automatically.

Now, time for a screenshot of the 1.9 parser in action (see e.g. this document for changes in 1.9):

The notable thing in the above screenshot is of course the lack of error stripes in the editor.

As always, please give it a try and let me know how it works for you (see here for instructions on how to get a dev build). Also, please note the debugging support for 1.9 is still not there.

If you're using NetBeans 6.5 (or 6.5.1) and Rails 2.3.2 you've probably noticed that the Run action in Rails projects doesn't launch the browser like it should. It has been fixed in dev builds for some time already, but using a dev build is not an option for everyone. Since it is unclear when/if there will be another patch for 6.5.1, I made the patched Rails module available in this issue. Please follow the intructions in the issue for updating your IDE and as always, please report if you encounter any problems.

Note: the patch is for 6.5.1; I make no guarantees that it will work with 6.5, though it may.

Thanks to Tomas Holy who provided an API for embedding the output window component, we now have clickable links and all the other goodies that the OW component provides in the Ruby test runner:

Another enhancement which you can see above is the result bar for showing the percentage of passed tests (thanks to Tor for that component). Both of these improvements are actually also in the JUnit, PHP and Python test runners since they are all using the same common test runner API.

Rails has had dynamic finders for ages (from the very beginning if my memory serves me right) and we've also had support for them in the IDE. However, we've only supported simple finders, such as "find_by_foo" or "find_all_by_bar", and not the newer "find_by_foo_and_bar_and_baz" kind of finders. After seeing how Petr Hejl implemented support for the Grails equivalents, I finally got around to add support for them in Rails too. So here's a couple of screenshots of the feature in action:

The first code completion invocation will offer you the "first level" finders and "..." variants for continuing further:

And this is what you get after choosing "find_by_price_and..." in the above (and invoking CC again):

Now I still need to add similar support for dynamic scopes that are coming in Rails 2.3.

It's been a while since I blogged about new features in the Ruby area, so here's a couple of screenshots of some enhancements that have made it to M2 (should be out on Feb 18th if the plan doesn't change).

In the project logical view, under the platform node, you can now see the gems installed for that platform:

At least I find myself often wanting to look at sources for gems, so this should make it a bit more convenient to open gem source files in the IDE.

The Rake Runner dialog now maintains a list of previously entered task parameters (instead of just the last one entered):

For db:migrate tasks it also prepopulates the combo box with the migrations found in the project:

It'd be nice if the combo box had autocomplete, something I'll need to look at that still.

There are also a couple of testing related enhancements, one is Run Focused test and Run again/Debug support for Shoulda and another one a visual diff viewer for assert_equals failures.

There's a View Differences action on the test method node for assert_equals failures:

(And as you can see the test runner's got a new set of icons too).

When you invoke it, you get the following viewer:

There is more of course, but I'll leave something for the next entry too. Comments / ideas for improvements / bug reports are welcomed as always!

Chris Kutler and Brian Leonard have finished their NetBeans Ruby book. I had the pleasure to be the book's technical reviewer. I think Chris and Brian did a great job, the book should be a good resource for anyone using (or thinking about using) NetBeans for Ruby development. Congrats Chris and Brian!

NetBeans 6.5 RC1 was just released, meaning that the final release is well on its way. Although not all work is done for 6.5, we've had some time to work on the next release already. We haven't gotten to any major features yet, but some little enhancements here and there. I'll list here are a couple of things implemented so far, starting with one that is not really going to directly help our users in their daily work, but should make reporting bugs a bit more convenient:

Ruby IDE Logging options:

In the past, when somebody reported an issue, we often had to ask the reporter to turn on detailed logging in order to be able to track down the problem. To do this, he/she had to edit the netbeans.conf file and restart the IDE, as described here. We always felt that this is a bit stupid and might frustrate the reporter (for a reason), so I finally got around to implement an option for this in the IDE. So the next time you report an issue and we ask for a log file with detailed logging turned on, it is enough to check the check boxes above, no restart is needed. For normal use it is however best to keep detailed logging off (for performance reasons).

Folks using Shoulda should be happy to hear that NetBeans now has at least some rudimentary support for it:

I didn't know the plugin myself, learned about it thanks to the user who reported an issue about it. It seems interesting and since it builds on top of Test/Unit, basic support for it was straightforward to add (in fact some things worked already before fixing the issue). Some things are still missing, such as jump to source for Shoulda test methods, and I'm sure there are things that I haven't yet discovered.

Another testing related enhancement are the new context menu actions in the test runner:

For individual methods:

And for suites:

I think this is kinda nice, but unfortunately it didn't make it into 6.5. Of course, you can still run individual test methods in 6.5 (as in 6.1 already) by hitting Alt-Shift-F6 (or Alt-Shift-F5 for debugging) when you're within a test method in the editor. Also, some may have noticed from the above screenshots that failed test methods node in the test runner display now have the error message inlined, thanks to Tor's patch.

I think that's about it for now -- Martin has also been working on new things; I'm sure he will blog about those at some point. As mentioned, these enhancements are only available in trunk (i.e. the next release) nightly builds, downloadable here, and of course in continous builds.

Since the initial introduction of the new test runner in the NetBeans Ruby IDE it has gone through some changes and improvements that I thought I should document somewhere. Eventually I'll turn this into a wiki page. I'll explain here a bit what it does under the hoods; it might not be that interesting for all users as it should just work, but I'm sure many users like to understand what exactly it runs.

Test actions in the project context menu

There are at most three test related actions in the menu: Test, RSpec Test and AutoTest:

What actions are displayed depends on what gems you have installed; if the target platform of the project has the RSpec gem installed, the RSpec Test action is visible. Similarly for AutoTest, just that it requires the ZenTest gem.

By default, the Test and RSpec Test actions try to invoke the corresponding Rake task and run that. So if your project has a 'test' Rake task, that will be run by the Test action. For RSpec Test action the respective Rake task is 'spec'. So in effect these actions are just shortcuts for rake 'test' and 'spec' tasks, if the project has such tasks. If not, they will run all tests found in the test folders of the project; the RSpec Test actions runs all *spec.rb files in those folders and the Test action in turn all *test.rb and test*.rb files.

The AutoTest action basically just runs the autotest command on the project. It was integrated with the new test runner just recently, in 6.5 Beta AutoTest results are displayed just in the output window.

Rake tasks

By default the test runner is associated with the following tasks:

• Test/Unit: 'test' and all tasks starting with 'test:'
• RSpec: 'spec'

I haven't found a (feasible) way to load our hooks to Rake tasks without knowing the task names that run tests, so we need to have the task names specified somewhere. To allow users to run test tasks that don't follow these naming conventions, the test runner checks for the [your project dir]/nbproject/project.properties (and/or [your project dir]/nbproject/private/private.properties -- where you should define these properties depends on whether you want to check that configuration into a VCS repo or not, typically (and by default) project.properties is shared and private.properties is not) file where you can specify 'custom' tasks. I'm copying here what I wrote to issue 141199:

The test runner now checks for project.properties (and/or private.properties) for the following properties:

• 'test.tasks' for test/unit tests
• 'spec.tasks' for rspec tests

If those properties are not defined, the test runner will run by default the following tasks:

• 'test' and all tasks starting with 'test:' for test/unit
• 'spec' for rspec

So to define additional tasks for the test runner, put something like the following either to project.properties or private.properties:

test.tasks=test,my_tests,yet_another_test_task
spec.tasks=spec,my_test_specs

If you define the property but leave the value empty, no tasks will be associated with the test runner. So if you for some reason don't want to run any tasks through the test runner, you can do:

test.tasks=
spec.tasks=

RailsConf Europe is taking place next week in Berlin and we'll be present there too. I have a session with Petr Jiricka on developing Ruby and Rails applications with the NetBeans IDE on Thursday. Those interested in NetBeans and/or JRuby might find also the following sessions of interest:

• Rails Powered by GlassFish
• Take the JRuby Challenge: Deploy Your Rails Application with JRuby
• JRuby: The Other Red Meat

If you have any particular things that you'd like to see covered in our session, let me know and we'll try to fit it in the presentation.

The conference seems to be full of interesting sessions, I'm looking forward to learning what's happening in the Rails world and speaking to people there. We'll have a NetBeans booth there somewhere, so if you'll be there and want to have a chat about NetBeans or anything just come by the booth, or let me know and we can arrange a meetup somewhere.

Based on a couple of postings I've seen on the various Ruby and Rails forums on the internet, there seems to be some confusion about how exactly NetBeans and JRuby are integrated. One source of confusion is probably the term we use for the JRuby version bundled with the IDE, i.e. "built-in". It does not mean that the bundled version is modified in any way to work with the IDE; in fact it is just the standard JRuby distribution and the IDE works fine without it. We do bundle some additional gems, e.g. Rails and activerecord-jdbc-adapter for a better out-of-the-box experience, but the JRuby bits themselves are untouched. You can (and generally should) upgrade to a newer version of JRuby whenever one is available; if you add the new version to your PATH environment variable it will be even autodetected by the IDE -- if not, just add it manually using the Platform manager by pointing it to /bin/jruby.

Adding a new platform, Tools -> Ruby Platforms

In addition to JRuby we naturally support Matz's Ruby (MRI) too, and thanks to Martin in the upcoming 6.5 also Rubinius is supported. Managing them is equally straightforward as for JRuby, and the same goes for autodetection. If you run into an issue you don't seem to figure out what could be causing it and suspect it must be the IDE, it is a good idea to try out running the problematic piece of code on another platform to make sure you're not seeing an issue specific to MRI/JRuby/Rubinius -- if that's the case, best to file an issue directly into the issue tracker of that Ruby platform. If unsure, it is perfectly fine to file such issues to our IZ too, eventually they'll be dispatched to the right place.

That said, the IDE does still in fact need a JRuby version that is specific to the IDE, namely the internal one that is used for providing editor features. However, this is not the same JRuby as the user visible one (i.e. the "built-in" version visible in the menus), instead it is completely hidden from the user.

PS. In related news, JRuby 1.1.3 was just released -- so go get it!

Lately I've been working on a new UI for displaying test results in the NetBeans Ruby IDE. This is now available in the latest daily builds, so please give it a try and let me know whatever issues you encounter. And of course, any ideas for improving it further are welcome too. I've already filed a couple issues myself that I haven't yet had time to address. Below are some screenshots, should look pretty familiar for those of who you have run JUnit tests in the IDE - the UI is pretty much the same with some Ruby specific modifications.

Here's a screenshot of the new UI, Test::Unit test run:

Another screenshot using a different layout. You're free to drag the results window anywhere in the IDE, the iconless button on the left side of the runner switches the layout from vertical to horizontal and vice versa (note that this will be done automatically once I get to fix this issue).

And finally a screenshot of an RSpec test run:

For those of you who are not familiar the JUnit results window, it might be worth noting a couple things. The results window can be found in Window -> Output -> Ruby Test Results. You can display only failures by using the filter button on the left side of the statistics panel. Double clicking the failed method nodes jump to the failure line in the test file, and you can of course double click the stack trace lines as well for the same effect.

Currently the new UI is invoked only if you specifically select 'Test' or 'RSpec Test' from the project context menu or run a single test file, meaning that running the test or spec rake tasks using the Rake runner in the IDE don't display the results using this UI. This will change of course, just a matter of time - see the link to the issue list in the beginning of this entry.

So, please go grab a fresh build and let me know whatever issues you encounter or how would you enhance it further!