Sami Wagiaalla's Blog

I was able to successfully build Eclipse 3.8 M1 on ARM on Fedora 15.

Special thanks to Andrew Haley for all the fixes to the java compiler, and Xerxes Ranby who had built Eclipse on Debian for the helpful pointers.

The work involved ensuring that eclipse depedencies are built and available on my Fedora installation, creating arch specific Eclipse fragments for ARM based on the x86 fragments, a few tweaks here and there and lots of debugging of reading of ant scripts. The next step is to get the eclipse rpm building on ARM Koji.

I have been working with the Eclipse build a lot lately. It takes about 18 minutes to build eclipse on my laptop so every time I made a change to the rpm or the build scripts I had to wait 18 minutes to see the results.

So I wanted to speed the build up. I was under the impression that the eclipse build was IO bound so to speed that up I decided to use . I created a virtual machine with tons of memory and allocated a 4GB folder:

mkdir /tmp/build
mount -t ramfs -o size=8g ramfs /tmp/build

There was no speed up. And I had made sure that there was no swapping.

So after digging around a little bit I found a way to analyse the build better. At first I had wanted to use

iostat

but I discovered dstat.

dstat has an output which is easier to parse for graphic tools:

$ dstat -tc
----system---- ----total-cpu-usage----
     time     |usr sys idl wai hiq siq
29-11 09:34:12|  4   2  92   1   0   0
29-11 09:34:13|  4   2  91   2   1   0

The each line in the output tells it what percentage of the time since the last sample your cpu spent running user process, system process, idling, waiting for io respectively. I don’t really know what the last two values are .

So I ran:

dstat -tc >& dstat.raw

In retrospect I really did not need to sample ever second and should have run

dstat -tc 5 >& dstat.raw

to sample every 5 seconds.
So I imported dstat.raw into gnumeric and ta-da!:

The important colours above graph are the yellow (idling cpu) the blue (cpu executing eclipse build) and the turquoise (cpu waiting for io). The first thing you will notice is that there is not a lot of io blockage. Of note are the big peak in the beginning which I assume is the extraction of the sources tar ball and at the end which I assume is the writing of the rpms. The second thing you’ll notice is that there is a lot of high yellow which is evidence to the fact that my cpu’s spend most of the time idling during the build. Finally you’ll note that the blue never goes above 25% and is usually around 20%. This is because I have 4 cpu’s and the eclipse build is not parallelized.

So in conclusion eclipse build is cpu bound, and the most obvious solution to this is to make the build parallel where possible.

This is a screen cast of Devhelp support in eclipse through Libhover. The devhelp information is used to provide you with auto completion choices and function documentation.

After over two years in the GDB team, I am now joining the eclipse team in Red Hat.

I have had fun working on GDB on expression evaluation and most recently python scripting support. GDB Python scripting deserves a series of blog posts and tutorials. It enables you do do such cool things as: writing custom type printers (pretty printers), adding custom commands, and most recently (in HEAD) listening for GDB events such as a breakpoint being hit. For now, if you are interested in this I will point you to the very well written GDB Manual section 23.2.

I am excited about moving to Eclipse, and have looked forward to this move for a while. Until recently I was undecided about what to work on in eclipse. That is until I read this blog post. There is no denying that what Autotools enable us to do is awesome; configuring and building source code easily and cross-platfomly by automating the near impossible writing of makefiles to do so (… or so I have read ). The problem with Autotools is the learning curve. There is a lot that one must learn before accessing this awesomeness.

This brings me to what I would like to do with Eclipse. The problem is the learning curve, and the solution is to create an eclipse plugin which makes it ridiculously easy to write and edit Autotools scripts.

I don’t know how I’ll do it, I don’t really know if it is possible, and, to be honest, I don’t know much about Autotools. I have started by reading this book. Autotools Mythbuster was also recommended. I’ll read it next.

If you have any thoughts on this, think it is impossible, think it is possible, have recommended readings or suggestions please let me know.

One of my favourite eclipse features when reading and trying to understand it is Ctrl+Shift+G (Open References to). This creates a list in the ‘Search’ view of all references to the highlighted element.

Another thing that I discovered recently is that you can click on the little arrow next to the little pen symbol on the right hand side and open up the history what previous searches. These are of course important to your understanding of the current new code.

This is one of my favourite features. I had to retrofit some error checking into a function in a patch I am working on.
The function is

evpy_add_attribute

. I wanted to know the functions that call this function and the functions that call them. Once I figured that out. I went through and made sure that the return values where checked for errors and appropriate action was taken.