Oh Stacktrace, My Stacktrace...

Do you remember the first time you wrote a Wizard for Eclipse? Do you still know what went wrong the first time (and maybe a few times more)? Let's assume you wrote a wizard page like the one below which just contains a simple text widget inside the page's composite:

 

It's not necessarily a fancy UI nor complete but it doesn't look obviously wrong, right?

However, when you run the wizard it just fails without any error message.

A look into the error log reveals that there is a problem with JFace - but not your code:

Now, you might guess that this exception is caused by you, but frankly: When I wrote my first wizard page I was quite sure I didn't make any mistakes... God, yes. How wrong I've been...

After googleing for an explanation for a while, I found out that I was missing just one simple method call. Namely, calling setControl(..) on my wizard page. I figured this out thirty minutes later - what a great waste of time...

But as I've learned from my talk at Eclipse Summit, I'm actually not the only jerk doing this wrong.  I asked the audience to raise their hands if they know that error - and after a while they started grinning and one-by-one raised the hand to show that they experienced the same problem just some time ago. How about you? Do you know it too?

Let's see what Google returned me when I pasted the first line of my exception into its search box: ("null argument: has no page control" is part of the query but was cut off in the screenshot):

 

Google obviously does not a good job here. It still doesn't know the answer - even after years this error (better: wrong usage) exists.

So what can we do to get rid of this? Bug trackers like Jira and Bugzilla (with Mylyn extension) have shown the way. These tools have duplicate stacktrace detectors that, whenever they observe a stacktrace in a new report, query the bug database for bugs that contain similar stacktraces.

And guess what: They work - and not too bad! To evaluate that, we replayed the bug reports from Eclipse Bugzilla from 2001 to 2008 one by one and for each new bug report containing a stacktrace we tried to find the corresponding bug id this new report was marked as duplicate of). The amazing result: In ~70% of all cases we found the right bug id under the top 3 positions! Goodbye duplicates - if you submit a stacktrace...

Just another example. Maven had a neat feature that whenever an exception occurs during a build, it printed out a message that directs you to some wiki page which may contain further help about this error. Unfortunately, these pages have been mostly empty (at least for the cases I looked at them). However, the idea is great!

What if there would be a place where you can send your stacktrace to and get a list of resources in the web that discuss exactly your problem? With such a help it should be quite easy to nail down and fix your problem in just a few minutes, right? You may think of it as being similar to  stackoverflow.com - but just for stacktraces. Something like stacktraces.org - or stacktraces.eclipse.org - a repository which contains stacktraces of the users, error descriptions and solutions including pointers to resources in the web that deal with these problems.

What we have in mind is something like this: An Eclipse client that listens for exceptions printed on the console or written into the log:

 

which are parsed automatically by the tool Whenever it observes an exception it may show a pop-up (3) which starts a search dialog that shows your most recent stacktraces:

If you know click on "search" it will search stacktraces.org for similar stacktraces and returns pointers to resources in the web that deal with similar stacktraces - it may even include a discussion on this stacktrace with some explanation of what caused this exception and how to fix it. This summary could be displayed in your browser or directly in Eclipse as shown below:

Additional tabs may provide additional information like similar stacktraces, related web-resources etc.:

That's just a thought about how we could get rid of it. Best of it: in its minimum version there is no additional effort of a user required. We may just give pointers to existing resources or we may integrate the results into a forum etc.

What do you think? 

Would you use such a stacktrace search engine that leverages the community knowledge about common pitfalls and usage errors of your favorite open source project? How much time you could have saved if someone had pointed you directly to the forum post telling you that you simply forgot to call setControl.

Just click on the like/dislike button below - and if you have a few minutes, feel invited to drop a comment below.

Thanks, 

Marcel

Update #1:

If you like the idea you may also consider commenting on it at/for stackoverflow.com.


Stay in touch: Follow me on Twitter.

A Subword Matching Completion Engine for Eclipse?

A few hours ago stumbled across a post at stackoverflow.com titled  "Eclipse: Fulltext autocompletion for Java?" where a programmer is essentially asking whether Eclipse' code completion supports partial proposal matching.

I copied the question here to make this post a bit more self-contained:

================================================

Hi, can I have fulltext autocompletion for Java @ Eclipse? Let's demonstrate:

Final piece of code:

getVariants().add(new Variant(MediaType.TEXT_XML));

How do I code now:

getv[ctrl+space].a[Enter]new V[ctrl+space, down arrow, Enter]M[Ctrl+Space, Enter].text_x

Basically, Eclipse completes word "TEXT_XML" when I provide letters "TEXT_X".

How would I like to code:

getv[ctrl+space].a[Enter]new V[ctrl+space, down arrow, Enter]M[Ctrl+Space, Enter].xml

and Eclipse should realise I meant "TEXT_XML" (fulltext autocompletion).

================================================

Well, thanks to JDT's quite comprehensive APIs this is not too complex to implement, and I wrote down a simple version of this completion engine (10 locs).

This is how it looks like in action now:

But now I wonder:

1. How often do you just remember a few letters but don't know the complete name of a method or member?
2. Would you like to see such a completion engine in Eclipse?
3. What else would be missing?

I would be glad if you could send your thoughts to the code recommenders forum.


Best,
Marcel

Stay in touch. Follow me on Twitter.


Update #1: Neat research on this topic.



I just found a paper (almost) exactly on this topic. Could you check out these screencasts?

• http://vimeo.com/11664433
• http://vimeo.com/19369928

Maybe it's even more than you/we would like to see :-) But I think that's pretty cool stuff and having a similar completion engine for Eclipse could be very, very cool. Internally it's based on Hidden Markov Models which learn how people abbreviated certain identifiers (like  stx --> 'setText') in the past. The nice thing about it is that we don't have to come up with our own matching algorithm but just use what the programmers used before... I like the Han's work :)

Update #2: Prototype available.


After a quick and dirty monday afternoon hack a first prototype is ready. In a nutshell, it takes your prefix entered and creates a regular expression from it. For example, when entering button.stx|<^Space> the engine only presents those proposals that match this regular expression .*s.*t.*x.* which finally may match "setText(text)". This is roughly what Maxime proposed in his comment below. 

In addition it now respects upper case letters as suggested by Deepak. For example button.sT<^Space> now evaluates to  '.*s.*T.*' whereas button.st would evaluate to .*s.*[tT].*.

Currently, it does not reduce the proposal score as recommended by another comment nor does is give precedence to those words that match the prefix - but we may do that if you find this more useful. Just drop a comment in the forum mentioned below.


Please find the installation instructions here:
    http://www.eclipse.org/forums/index.php/mv/msg/209269/671088/#msg_671088

Please send your comments to the forum here:
    http://www.eclipse.org/forums/index.php/f/211/

Stay in touch. Follow me on Twitter.

Google Summer of Code 2011 - Extended Documentation Platform Get's Going

IDEs do a great job when it comes to searching and presenting documentation on how to use an API. However, one recurring problem with open source software is that it is frequently outdated, misleading or even missing. In these cases, example code that used an API successfully before become an interesting source of information.

However, extracting patterns from reading source code is a tedious and time-consuming process and the question arises whether we couldn't support developers better by, for example, automatically extracting frequent patterns from example code and provide them as additional documentation. There is quite a large body of research on how useful information can be extracted from code and put into documentation but means to present such mined documentation inside Eclipse are missing, however.

I'm happy to announce that Stefan Henß will fix this during this year's Google Summer of Code. He will implement an "extended documentation platform" for Eclipse - an extensible documentation platform that enriches existing documentation with various information contributed from various documentation providers (not necessarily just mined information).

Stefan already started to outline his thoughts on his blog. If you like the idea just visit his post, drop a comment, and keep in touch to get the latest news about this GSOC project either by following us on Twitter (Stefan, me)  or by subscribing to Stefan's news feed (a request to add Stefan's blog to planet-eclipse is currently on the way).

Good Luck Stefan! I'm looking forward to your first prototype screenshots!