The Green Bar

Today I have nothing exciting to report. Still, things happened behind the scenes.

The code used to give 156 compilation warnings, mostly about the long-deprecated Eclipse preferences API. I reworked all preferences-related code to use the new API instead. Now only 9 warnings remain. All of these are quite valid indications of possible problems, but mostly of dead code, so I left these for the time being.

Also, some refactorings in the way the GHC compiler was being called caused the JUnit unit tests to fail. I had so far ignored the existence of these tests, but no longer. I fiddled around with the tests and the code until the bar was green again. Unfortunately, it was mostly spinning my wheels: no real bugs were uncovered by the tests.

These kinds of things are not the most exciting parts of software development. But they are necessary.

Although, looking back through the commit logs, I can also report one small new feature. It is now possible to create a new project in an existing source directory. This makes it much easier to import an existing Haskell source tree into EclipseFP. It’s not perfect yet (for example, it simply assumes that the source is in a directory named src), but I’ll improve it in the upcoming days.

More robust Scion client code

New post, new theme! With this wider theme, the screenshots will no longer fall off the edge.

Although I did not plan to “build one to throw away”, this largely became reality nonetheless. By now I’ve done so many refactorings on the Scion client code that hardly a single line of the original remains. But I’m finally happy with the result.

The Scion client previously used its own command queue, which ensured that commands were sent to the server one after another. After some investigation, I replaced that by Eclipse’s job scheduling mechanism. With proper scheduling rules, we can keep the scheduler from running two commands simultaneously, so it is as powerful as the home-brew command queue. If one command depends on the result of another, we can make the second job fall asleep and have the first wake the second up when it’s done. And it has several advantages over the old system:

  • We can now set priorities on commands, so that interactive commands (such as computing the text of a tool tip) take precedence over longer-running commands (such as builds).
  • Commands will automatically be shown in the progress report windows.
  • The sender of a command can either run it asynchronously, or wait for the command to complete before continuing.
  • Of course, it’s simply less code to maintain and have bugs in!

Secondly, I introduced a Scion “manager” class that ensures that there is always one Scion server running per project. If the server crashes, it is restarted automatically and brought back to the same state as its previous incarnation.

Thirdly, all significant errors are now logged to the Error Log window in Eclipse. There should no longer be a need to turn on error tracing to troubleshoot problems in the Scion client/server system.

Finally, if the server fails to start in the first place, this is probably because its executable program could not be found. Most likely this is because the plugin is used for the first time. Therefore, we pop up a helpful dialog:

server-startup-error

Little things like this go a long way, making it easier to get up to speed with EclipseFP. In the same vein, I will start working on a “new project from existing source” feature that is well known from Java development in Eclipse. (EclipseFP is already able to import Cabal packages from a .tar.gz, but strangely not from a directory on disk!)

Little rant on modularity

And now, a little rant. Eclipse is, first and foremost, a Java IDE. It tries very hard to be extensible and flexible, so the Java functionality itself, like everything else, is a plug-in, or rather a set of plug-ins called the JDT (Java Development Tools). Very good.

But unfortunately, there is a lot of code in the JDT that does quite generic things, like showing the error markers in the Project Explorer, or on the editor tabs. I often find myself digging through the JDT sources to figure out how the big guys do things, only to find out that they implemented quite common functionality in the JDT that would also benefit many other language-specific plug-ins. Other plug-in writers who want to use this functionality have a choice: either have their plug-in depend on the Java Development Tools, or reproduce all the code in their own plug-in.

Depending on the JDT plug-ins would be a shame, because we’re trying to build a Haskell IDE here. Even though most Eclipse users will have the JDT already installed, we do not want to have to package it with an eventual “Hasklipse” (I hope that name doesn’t stick…) distribution containing an Eclipse platform for Haskell development. Moreover, it is not even always possible to use the classes from the JDT directly: often, they subtly depend on some Java-specific treat.

The alternative, copying and pasting to your own plug-in, is therefore often the best option. It is not pretty, but it works, and it allows you to customize the code to fit your own plug-in better. But I sure wish it wasn’t necessary. For a poor Haskell plug-in developer, even more modularity would be very welcome.

Posted in EclipseFP. Tags: . 10 Comments »
Follow

Get every new post delivered to your Inbox.