Diver in linux

Some people may be having difficulty with Diver in various distributions of linux. You may be getting the following message when trying to launch a trace.

And you may see this in the console:


Error occurred during initialization of VM
Could not find agent library in absolute path: /[path-to-plugin]/libsketch_linux32.so


Now, you may be surprised to find out that these errors may have nothing to do with open ports or whether or not the file listed exists. This is not Diver's fault. The client can't find an open port because the Java virtual machine couldn't start and open one. The Virtual machine couldn't start not because the listed library is missing but because you might not have some of the dependencies installed on your system. Unfortunately, the Java VM sometimes gives some pretty uninformative error messages.

Diver depends on the C++ boost libraries to do socket communication and multi-threading. It also uses boost to do multi-platform file system manipulation. Many distributions of linux come with boost installed. Some do not. If you have a debian-based version of linux, installing the required boost libraries is easy:

$ sudo apt-get install libboost-iostreams1.40.0 libboost-date-time1.40.0 libboost-filesystem1.40.0 libboost-system1.40.0 libboost-thread1.40.0

If you are running a redhat distro, you should be able to use a similar yum command. I hope that this all works for everyone.

Awesomeness in Helios

There was a recent post by Wayne about how Eclipse is an IDE Platform. For all practical purposes, that is the way that I use it. But what is really awesome about Eclipse as an IDE platform is that it is an IDE platform that just keeps improving.

I have to admit that I honestly don't keep up with the latest improvements to the Eclipse IDE. The reason is simply practical. I work on making tools for doing research on IDEs. I would like my current project, Diver to be as compatible as is reasonable so that I can decrease the barrier to adoption. If I work with the "latest and greatest" version of Eclipse, I am just too tempted to use the "latest and greatest" features of Eclipse in my own tools, which means that people running the current release may not be able to work with what I am building. It's really just a matter of discipline.

But now that Helios is about to be released I've started to use it and I find it totally awesome. Ian Bull has been faithful to his top ten list of the newest and greatest features of Eclipse. I don't know if I will do the same, but I think I might report on the great things about Eclipse as I discover them.

So far, the number 1 through 10 greatest feature of Helios for me has been its new integration with the Eclipse Marketplace (and the Yoxos Marketplace catalog). I just recently had to change computers which meant that I also had to reinstall Eclipse. Normally, I would use Yoxos to create my own custom distribution of Eclipse, but I wanted to try Helios and all its cool new features. I use a number of 3rd party tools that aren't available in the standard Eclipse p2 repositories. For example, I work in academia which means that I write papers. I use LaTeX for writing papers, which is a surprisingly process to writing software. So, I use Eclipse to write text as well as software. It used to be total pain to search for my LaTeX plug-in, add its p2 repository to my list of "Available Software Sites", and install. That is no longer the case. Now, I can just load up my Eclipse Marketplace client and do a quick search for "LaTeX":

And there you go. No hassle, no fuss, I just install and that's it. It's beautiful.

As an aside (and a shameless plug), you can do the same thing with my project "Diver". Just load your Eclipse Marketplace client. A quick search for "reverse engineering" will point you straight to my favorite Eclipse tool ;-) :

Eclipse Labs: To Migrate or Not to Migrate?

I'm really happy about the recent creation of the new Eclipse Labs. While I would absolutely love to have my Diver project as an official Eclipse project in incubation, I'm afraid that the process is too heavy-weight. I work in research which often requires a very malleable programming schedule... I don't think that I would be able to hit the release targets of Eclipse. Plus the IP process can be a little long. My friend and colleague Ian Bull was able to make his Zest project an official Eclipse project (it is now part of GMF/draw2D) while he was doing his Ph.D... he did have a little programing help from some of the other members of our lab ;-). I'm a Masters student, though: the program is too short to wait for my project to be approved by the committers.

So, Eclipse Labs is exactly perfect for what I need. It has the benefit of the Eclipse brand, but it doesn't carry the baggage of official Eclipse projects. It's too bad that it wasn't available six months ago when I was making Diver a tool open to the public. The best option I had at the time was SourceForge, which has been quite good, really.

So, now I'm left with the question of whether or not to migrate Diver to the Eclipse Labs hosting. I would really like Diver to have a closer tie to the Eclipse brand. But, I would lose a lot of work that was put into creating the project content for Diver over at SourceForge. Most specifically, I would lose are the hard work that I put into creating the web site. Google code has its wiki, which is OK, but it isn't as rich as what I've been able to make with my web page.

So: to migrate, or not to migrate? I don't know. Is there any real benefit?