Shame on Me

I’ve been avoiding posting to the blog, because that would tell me exactly when the last time was that I’ve really done any work on my research project. It’s been 10 weeks. I really didn’t think it was that much… My estimate would have been six. I guess the whole month around the SIGCSE conference kind of disappeared from my memory — the 212 exam, the conference, catching up afterwards. I was very busy — I did a tremendous amound of work on DrJava — but that’s still no excuse.

On DrJava, I’ve been rewriting the “Create Jar” dialog to work when both class and source files were supposed to be archived, to save its state, and to clean up the interface. After that, I added a “Go to File” dialog that narrows the list of file names down as you type. I also use this dialog for some primitive code completion that can auto-complete all file and class names. It completely ignores the context, but it can be helpful anyway.

After that, I realized that recent changes rendered the debugger pretty much unusable: Because the interactions pane is now being reset before the main document is run — which involves turning off the debugger — and because traditionally all breakpoints were lost when the debugger was turned off, you couldn’t really do any debugging. I made breakpoints and watches persistent, they’re actually saved in the project. Breakpoints can even be disabled without removing them. And if a breakpoint is on a non-executable line, it will be disabled with a warning message. Unfortunately, because the code to detect that is very slow, I only do that if the document is shorter than 500 lines.

In the last few days, I fixed a lot of bugs since we’re gearing up to make a new beta release. I changed find/replace from a recursive implementation to an iterative one — when searching within the DrJava codebase, we were actually running out of stack or heap space.

I’ve been insanely productive. Unfortunately, in the grand scheme of things, I’m just working on the wrong project. For about two weeks now I’ve been saying “I’m going to do this one thing, and then I’m done with DrJava”. But there are always more things to do, and quite frankly I enjoy working on DrJava a lot. This is the first time in a while that I just get to code away. Development work is so much easier than research.

That “one thing” that I still have on my list now is a change of the way DrJava handles exceptions. The exceptions dialog is too obtrusive — quite often, the program can gracefully continue, so it’s not necessary to thrust the exception in the user’s face. Sometimes, the dialog can even completely lock down the program. I intend to turn the exceptions dialog into a log that the user can browse if so desired.

After that, I really need to focus on my research again. Otherwise I will have constructively wasted a whole semester. If I remember correctly, I was trying to implement the algorithm I proved correct using SPIN in Java, and I was running into a problem with setting a boolean flag to true… it just wouldn’t stick, and I have no idea why.

Share

About Mathias

Software development engineer. Principal developer of DrJava. Recent Ph.D. graduate from the Department of Computer Science at Rice University.
This entry was posted in DrJava, Research. Bookmark the permalink.

Leave a Reply