Tim Hardy

If there’s an error in your java code, Eclipse sticks a marker in the gutter with a light-bulb icon. Clicking on the marker or pressing Ctl+1 with the cursor in the offending line brings up a helpful pop-up of suggested fixes for the problem.

I’ve always assumed that this was called Quick Fix. If you right click on the marker, the option is labelled Quick Fix. However, after struggling for a long while to understand why some Quick Fix code I wrote wasn’t showing up in this menu, I’ve come to the conclusion that this is actually Quick Assist and that the label is wrong (I’ve flagged this as a bug).

To launch Quick Fix you need instead to right click on a Warning/Error in the Problems View. Quick Fix and Quick Assist are in fact two different things with confusingly similar names and functionality.

Internally appropriate Quick Fixes are calculated by a class implementing IMarkerResolutionGenerator that extends org.eclipse.ui.ide.markerResolution. The fixes themselves are contained in classes implementing either IMarkerResolution or IMarkerResolution2. By contrast, Quick Assists are calculated by a class extending org.eclipse.jdt.ui.quickAssistProcessors and implement IQuickAssistProcessor. The classes containing the assists implement IJavaCompletionProposal.

So, if you’re developing a plug-in and cannot work out why your Quick Fixes are not showing up, take a closer look. Maybe like me you’re checking in the wrong place and what you meant to write was actually a Quick Assist.

I’ve been coding exclusively in Java for the last few weeks. However, when I needed to write a quick program to crunch some numbers the other day, I decided to write it in C++ for the change. Since I’ve also been working exclusively within Eclipse, I decided to use a simple text editor for this and gcc from the command line.

The experience made me reflect a little on the importance of good tools.

In Contributing to Eclipse, Kent Beck and Erich Gamma speak of the compiler moving from being a separate tool to “air - something vital that’s always around”. While using the JDT, the compiler is constantly running in the background, warning you of potential errors as you type each line of code. The IDE also makes suggestions for fixes that save much typing. In this collaborative model, the compiler/editor is like a helpful colleague looking over your shoulder and making gentle suggestions from time to time. By contrast, the model of finishing the code, trying to compile it and working through the often opaque error warnings thrown by a c++ compiler is more like facing a difficult interview. The rhythm of work is completely different.

Doug Schaefer, project lead for the Eclipse CDT, explains in this Callisto podcast (direct link to mp3) that the simplicity of Java makes the JDT experience possible but that it would be prohibitively expensive to do the same with CDT.

Another thing I missed was JUnit. At the moment, I frequently work outside my comfort zone, learning through discovery and error and unit testing gives me the confidence to do this and to refactor. The task at hand was so brief it wasn’t worth investing the time to explore the xUnit variants for C++ but I intend to do so the moment I need to write more substantial code in that language.

I’ve just deleted a relatively innocuous comment on a recent post because, although it was not in itself spam, the poster gave his url as a site that stinks like a link-farm.

The IP address of the poster was from an Indian ISP which makes me wonder if some comment spammers frustrated with the efficiency of blocking tools are now abandoning automated scripts and outsourcing their work to low-waged workers. Of course, once a comment has been approved from a certain IP, it increases the chances that further comments will be approved so perhaps they are merely using people to get a foot in the door before launching an automated assault.

Either way, if your comment was genuine and I deleted it over-zealously I apologise. Somehow however, I doubt this was the case.

Scientists at the Georgia Institute of Technology figured they could learn more from neuron clumps that acted more like real brains, so they’ve developed “neurally controlled animats” — a few thousand rat neurons grown atop a grid of electrodes and connected to a robot body or computer-simulated virtual environment.

It’s Alive (ish) | Wired

A fascinating - but frustratingly brief - look at a something that blurs the boundary between animate life and machines. I, for one, welcome our animat overlords.