Arrdino

I’ve been updating our ant build scripts to compile all our third party library’s from source for two reasons:

1. So we don’t keep binary blobs under CVS, and
2. So it is easy to distribute the source of the libraries we use.

Ant is a very powerful build system, and everything was moving along swimmingly until I was working on calling the JavaHelp build script, which is nice and smart, but it’ll seem too smart for it’s own good! It automatically downloads its dependencies for you, the only problem is at work we are stuck behind a very annoying web proxy.

But never fear ant came to the rescue! Ant allows you to put a <setproxy .. /> tag into your build script to set a proxy, yay!!

BUT…

Can anyone see a problem here? When we are working on build scripts for some open source apps we write here at work, then adding the proxy to the script is good and fine here, but it WILL break for all users out in the big wide world who use our software… if only there was an easier way.

I talked to Chris and he came solution… one that I should have thought of myself, environment variables!

Ant checks an evironment variable called ANT_OPTS for, strangely enough, ant options. To set the proxy settings:

export ANT_OPTS="-Dhttp.proxyHost=localhost -Dhttp.proxyPort=5865 -Dhttps.proxyHost=localhost -Dhttps.proxyPort=5865"

NOTE: Change localhost and the port to the port of your proxy server.

Isn’t it great when you find a command line gem in Linux!

I’ve been using the ‘time’ command for years, and it was only up recently that I was told that the time command I’ve been using was the time command built into bash. There is a GNU time command, which has always been installed but I’d never used!

Chris was the one who stumbled across this while attempting to use some time options specified in the time man page which wasn’t working. That’s when he realised the man page was for GNU time not bash’s implementation.

GNU time is awesome!! You can grab a whole heap of useful stats about the process your timing, not just the time. To quote the GNU time website:

The `time’ command runs another program, then displays information about the resources used by that program, collected by the system while the program was running.

I had a play with GNU Time and set up some format strings I find kinda cool, I’m not using all information from the file, check the man page if you wanna add extra goodies but here is what I’ve got:
A formatted time display:

/usr/bin/time -f "Exit Status: %x\nCPU %%: %P\nMemory:\n Unshared: %D\t\t\tAvg Total Mem: %K\n Major Page Faults: %F\t\tMinor Page Faults: %R\n No. Swaps Out of Mem: %W\tNo. Invol Context Swiches: %c\tNo. Vol Context Switches: %w\nTime:\n Realtime: %E\t\tSystem Time: %S\t\tUser Time: %U"


In which the time output looks like:

Exit Status: 0
CPU %: 98%
Memory:
Unshared: 0 Avg Total Mem: 0
Major Page Faults: 0 Minor Page Faults: 3241
No. Swaps Out of Mem: 0 No. Invol Context Swiches: 35 No. Vol Context Switches: 2
Time:
Realtime: 0:00.29 System Time: 0.01 User Time: 0.27


And a simple tab seperated version easy for parsing:

/usr/bin/time -f "%x\t%P\t%D\t%K\t%F\t%R\t%W\t%c\t%w\t%E\t%S\t%U"

NOTE: The parse time command doesn’t have any labels, the columns are the same as the detailed format string.

Which looks like:

0 100% 0 0 0 3240 0 153 2 0:00.30 0.03 0.26


Unfortunately, the memory usage stats don’t seem to work… I’ll have to look in to why, is it a bug? am I doing something wrong? … not sure but if I figure it out I’ll let y’all know!.

UPDATE

Well as it turns out GNU Date is a little outdated…I had a quick look at the source code to see what was happening as to why the memory stats would only ever be 0. As it turns out to calculate memory usage they are using an algorithm that requires the number of kernel ticks. And for those of you who are unaware the Linux kernel has been tick-less since version ~2.6.21.

So no ticks equals no memory calculations.. hopefully GNU will rectify this problem cause as I stated earlier, GNU Date is a gem.

This has been around for a while, but I’ve only just stumbled across this as I have been looking at into the licensing of some 3rd party jars we use at work.

GNU have a free implementation of the Sun JavaMail API specification, which means we now have some more GPL’d jars we can use.

So lets build em!
First we need to download all the source:

wget http://ftp.gnu.org/gnu/classpathx/activation-1.1.1.tar.gz
wget http://ftp.gnu.org/gnu/classpath/inetlib-1.1.1.tar.gz
wget http://ftp.gnu.org/gnu/classpathx/mail-1.1.2.tar.gz
NOTE: The above links are on the javamail link above, so you can just download it from there!

Extract and start building.. as an example I’ll just use the ‘/tmp’ directory, remember to change this to your desired location.

tar -xvf activation-1.1.1.tar.gz
tar -xvf inetlib-1.1.1.tar.gz
tar -xvf mail-1.1.2.tar.gz


We need to build activation.jar and inetlib.jar first as they are dependancies of the GNU mail api.

First build activation.jar:

cd activation-1.1.1/
./configure
make
cd ..


Then build inetlib.jar:

cd inetlib-1.1.1/
./configure
make
cd ..

Now with those jars built we need to build the gnumail jars:

cd mail-1.1.2/
./configure --with-activation-jar=/tmp/activation-1.1.1/ --with-inetlib-jar=/tmp/inetlib-1.1.1/
make
cd ..


Lets move all the Jar files into /tmp so I can show you them all:

cp activation-1.1.1/*.jar .
cp inetlib-1.1.1/*.jar .
cp mail-1.1.2/*.jar .

ws -l *.jar
-rw-r–r– 1 matt matt 44375 2009-06-12 15:53 activation.jar
-rw-r–r– 1 matt matt 163942 2009-06-12 15:54 gnumail.jar
-rw-r–r– 1 matt matt 95250 2009-06-12 15:54 gnumail-providers.jar
-rw-r–r– 1 matt matt 182002 2009-06-12 15:53 inetlib.jar

Now just put them in your Java path and away you go!

Happy GNU Java’n

Yes it’s back and I’ll even attempt to use it this time… for those who may not be aware there was once a blog on this site which had an amazing total of 2 posts!

I’m not a very chatty person, but will do my best to actually post interesting stuff I find.. mainly linux or programming based posts would be my guess, and we all know there aren’t many blogs based on that.