Friday, October 26, 2007

Ruby Screenshot of the Week #22: Go To Specific Location

WARNING: This blog entry was imported from my old blog on (which used different blogging software), so formatting and links may not be correct.

It's bugfixing all the way these days - I apologize for being behind on my e-mail. We're freezing 6.0 pretty soon (in eight days), so I'd really like to get some help testing the last minute fixes. More about that shortly. But first, some screenshots.

One longstanding bug we've had is that our "Go To Declaration" (holding the Ctrl or Command key down while clicking on classes or methods) would jump to a different place than you were intending. With Ruby's open classes, there are many definitions for a class, so if you want to jump to say the File class, did you want the one in ftools.rb? Or perhaps in pp.rb? We have some heuristics which pick which reference is "best" - it involves looking at things like whether each declaration has documentation, whether it's directly loaded by your file using require statements, and so on. But this can never be perfect. So, to solve this problem, Go To Declaration clicks (or Ctrl/Command-B) will now pop up a dialog when there are multiple possibilities. As before, one item is NetBeans' best guess - and it's shown first and in bold. All you have to do is press Enter or click on it to jump as before. But other matches are shown too, in a sorted order. First are the documented entries, and at the very end, :nodoc: entries (shown with
a strikethrough font effect).

Here's how this look if you for example try to jump to TestCase:

If you don't like this behavior, you can always turn it off by running NetBeans with


This was added just this week. Something related which has been there for a while is documentation
tooltips. If you're holding the hyperlink-modifier key (Ctrl/Command) and hover over methods and
classes, it will display a tooltip with the type of the symbol and its documentation. For example,
in a Rails controller test, here's what I got:

I just (a few hours ago) checked in a bunch of changes to clean up how NetBeans handles the gem load
path. It should now finally handle $GEM_HOME properly, as well as vendor gems and in particular, vendor/rails. Thus, the active record completion I showed last week
should now work with Rails 2 and edgerails. NetBeans should properly pick gems both from the current project as well as the current gem root (based on which gem version is higher). However, all of these changes were a bit involved... So I would really appreciate if people could grab the current bits (build 4866 or later from and take it for a quick spin. Make sure that code completion etc. picks up your gems as before. You may have to wipe out the cached indices (userdir/var/cache/) if you have any problems. Don't worry, it's always safe to wipe out stuff inside var/cache.) If there any problems, please let me know now since we're about to freeze for 6.0.

P.S. Beta 2 was released this week - download,
New And Noteworthy

Tuesday, October 16, 2007

Ruby Screenshot of the Week #21: ActiveRecord Completion

WARNING: This blog entry was imported from my old blog on (which used different blogging software), so formatting and links may not be correct.

Let's jump to the good stuff right away:

Okay, now let's motivate it. Let's say you're writing a migration:

Hmm, what's the second parameter to the column method again?

Ah yes, the column type. Notice how the RDoc for the method call surrounding
the completion point is shown above - and perhaps more importantly, the symbol alternatives for
the current parameter are also
proposed below. Let's choose one.

Ah yes, the third parameter - the options. Again the documentation is
shown above (I've cropped it in this image) where you can read the details -
but many of the alternatives are listed here. Let's choose the :null hash key.

The parameter completion support I've shown here isn't specific to ActiveRecord. Let's say you're in
an ERB file and calling into say the NumberHelpers:

Anyway, we're done editing the migration. Now let's jump over to a controller file and reference the Product model that is using the database table for this migration. Let's ask for completion on the @product field that was just populated with a Product object:

The icon should make it really clear that these attributes are coming from the database as opposed to some dedicated attribute code in the Product implementation. Notice how NetBeans also shows the type for each of the columns. Completion also works for the dynamic finders that Rails generates. Let's ask for completion on find_by (this also works for find_all_by):

NetBeans offers code completion for models by examining the migration files. Let's go create another one. Here's
completion again, this time completing on the table name argument to rename_column:

Let's say we rename the description column to desc:

If we now invoke code completion in the controller again, notice how the Product attributes correctly
reflect the result of combining the migrations:

NetBeans will also use the schema.rb file that Rails will automatically generate if you run the db:schema:dump Rake target. This is useful if your migrations are doing creative things that NetBeans can't figure out, or if you're renaming tables (which NetBeans doesn't model right in this release.) With a schema dump file, not only does NetBeans have to do less work to figure out your migrations, its format is predictable such that the code completion should be completely accurate.

P.S. This doesn't work right if you freeze Rails into your project; you need to be using Rails via Rubygems. I'll fix that soonish.

Monday, October 8, 2007

Ruby Screenshot of the Week #20: Purdy Colors!

WARNING: This blog entry was imported from my old blog on (which used different blogging software), so formatting and links may not be correct.

A lot of people have asked for a "dark color theme" for NetBeans, possibly because there are several attractive dark color schemes for TextMate, a favorite editor among many Ruby developers. Jerrett Taylor has designed and contributed a great dark color theme for NetBeans, "Dark Pastels". I've wrapped it up as a plugin. As of today, it's prebundled with the continuous builds on, but for other versions such as beta1 and the upcoming beta2, you can download the plugin from here and install via Tools | Plugins (go to the Downloaded tab). It should hopefully also appear on the Auto Update center pretty soon.

To switch to this color theme after installing the plugin, open the options dialog, go to "Fonts and Colors" and choose the "Dark Pastels" color theme.

Let's get on to the screenshots! Here's a Ruby file:

...and here's an RHTML file:

Note that the plugin only replaces the editor colors. Other windows such as the navigator and project views keep the general look and feel of the whole application, so you can either slide these off to the side, or install a custom look and feel with colors more to your liking.

Here's what the plugin looks like in the Plugin Manager. As you can see I've named it "Extra Themes" such that it can hold several optional themes, so if you've got a color scheme to share, please do!

A huge thanks to Jerrett!

P.S. The theme the font to "Monaco", which is available on the Mac. If you're on a different platform you may want to go a tweak the default font to one that looks good on your system.

Tuesday, October 2, 2007

Disable Crashing...

WARNING: This blog entry was imported from my old blog on (which used different blogging software), so formatting and links may not be correct.

If you're on OSX, and you've experienced NetBeans 6.0 beta crashing on you, read on...

Right before beta1, we tweaked some of the Java VM startup flags NetBeans uses. In particular, we switched to the "Concurrent Mark Sweep" (CMS) garbage collector, which has a nice performance profile for IDE usage, since collection happens mostly in parallel so you don't get noticeable pauses.

Unfortunately, it turns out that these flags cause a lot of problems on OSX. In particular, they cause frequent virtual machine crashes!

Knowing this, for beta2 we've turned off those flags when running NetBeans on OSX. But that doesn't help you if you're trying to run beta1... Luckily, it's easy to fix it yourself, since the VM parameters are specified in a text configuration file.

First, open the netbeans.conf file. On my Mac, I installed NetBeans in Applications under NetBeans, so the file is

/Applications/NetBeans/NetBeans\ 6.0\ Beta\

The file contains this:

# Options used by NetBeans launcher by default, can be overridden by explicit
# command line switches:
netbeans_default_options="-J-client -J-Xms32m -J-XX:PermSize=32m -J-XX:MaxPermSize=200m
-J-Dapple.laf.useScreenMenuBar=true -J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled
# (Note that a default -Xmx is selected for you automatically.)

# For JVMs which does not support Concurrent Mark & Sweep garbage collection
# algorithm remove "-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled
# -J-XX:+CMSPermGenSweepingEnabled" part of options
# (see

Remove the bold section above; in other words, remove these 3 flags:

-J-XX:+UseConcMarkSweepGC -J-XX:+CMSClassUnloadingEnabled -J-XX:+CMSPermGenSweepingEnabled

Now when you restart the IDE should behave better.