Eclipse on ARM

February 21, 2012

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.

Analysing Eclipse Build

November 29, 2011

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.

Devhelp support in eclipse through Libhover

May 17, 2011

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.

F15 spell checking problem

May 17, 2011

I installed Fedora 15 from live disk and had a problem spell checking. It was not working in firefox gedit etc. To fix it I did:

yum install hunspell-en

fpaste

April 4, 2011

I just discovered the command line utility fpaste. As in “git diff | fpaste”.
Thanks creater(s)

Great User Interface

April 1, 2011

20110401-105808.jpg

I was worried about fumbling with oddly shaped box on the subway. The cashier asked me which way I would like to carry it and stuck those handles on for me. Loved it.

Bad user interface

March 8, 2011

I can’t prove this but I think this would work much better if the sign was on the other door saying: “Pleas use this door”

Eclipse and The Autotools

March 1, 2011

So after a few days of reading I came to the conclusion that getting eclipse to manage Autotools build is very possible if not easy. Then I started reading some configure.ac’s and makefiles.am’s and realized that real life is a lot more complicated.

The problem still remains of course that the autotools have a high learning curve. I discussing things with Jeff Johnston (author of the current Autotools plugin in eclipse) and he had some neat ideas. His suggestion was that we create a set of wizards that will enable users to create an Autotools setup for new projects to build an executable, a static library or a shared library. This will not help people who are editing an existing makefile but will make life easier for people who are getting started. The question is are more people setting up new build systems or editing existing ones. WDYT ? And, if it is the latter how can we lower the learning curve for those developers ?

Git Feature Request

February 26, 2011

I looked for a git bugzilla but could not find one.

The feature I want is for ‘git status’ to show you if you are in the middle if a rebase.

New beginings: From GDB to Eclipse (to Autotools ?)

February 22, 2011

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.


Follow

Get every new post delivered to your Inbox.