Homebrew now has an improved sbt launcher script

In my latest adventures with Scala, I've gone all in, and have been using sbt as my build tool of choice. And, given that I hate installing things myself, I installed using the world most awesome package manager for Mac, Homebrew.

Lately, though, I've been having trouble with sbt running out of permgen space. Rather than just making some local mods to my launcher script, I patched Homebrew's launcher script, which adamv quickly accepted. (Thanks!)

If you used Homebrew to install sbt on your Mac, the next time you update you'll find the launcher more configurable.

Create a file in your home directory named .sbtconfig. In that file, you can define the environment variable SBT_OPTS to be to extra options passed to Java when launching sbt. You can set -Xmx, -XX:MaxPermSize, or any other tuning you might find necessary, (such as -XX:+CMSClassUnloadingEnabled). My file looks like this:

SBT_OPTS="-XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=256m"

I hope running out of permgen is now a thing of the past. We'll see!

Enjoy!

Scala 2.8.0

Anyone else who's a language enthusiast would be glad to know that Scala 2.8.0 is stabilized and officially released.

For those who don't know, Scala (stands for scalable-language) is a hybrid functions/OO language. It runs on the JVM and is fully compatible with existing Java code.

Now we just need Lift 2.1, and some really exciting things can begin!

Maven Versioning

Managing version numbers in Maven has always been an extreme hassle. Especially when it comes time to upgrade components.

I don't know why I've never found it before, but the Maven Versions Plugin can deal with much of that for you. Check it out!

Type Coercion failed no more

We recently upgrade from Flex 3.2 to Flex 3.5, and ran into a slew of mysterious type coercion errors.

Type Coercion failed: cannot convert Object@... to com.mycompany.myapp.MyDto

Executive summary: if you have a loadable module that gets loaded, unloaded, reloaded, and you use RemoteClass for annotating DTO's for BlazeDS or LDS, then you're going to have some Type Coercion issues after the reload. In the preinitialize method of your module, you need to manually register your classes using registerClassAlias.

A bit of context about our application. First we load a generalized shell of a console, which can then loads within it one of many Modules that runs different applications. Depending on what the user does, different modules get loaded and unloaded at run-time.

Our module makes heavy use of BlazeDS for communication with the back-end Java server. The objects we were getting the type conversion errors on were always our DTO objects, which were marked with the RemoteClass metadata tag for serializing to/from the server with BlazeDS. And the error always seemed to happen during de-serialization.

Things always worked fine the first time the module was loaded. But if it got unloaded and re-loaded, then the Type Coercion errors would start happening.

Googling about the problem usually led us down the path of people having problems with multi-version applications, and the solutions were usually to put the definitions of your remote classes into the main .swf. We don't have a multi-version application (we load, unload, reload the same .swf), and we can't modify the main .swf (it's owned by another team. Anyways, it runs lots of apps and can't reasonably pull in our app specific classes).

So I got to thinking about the problem. We knew that when the module gets reloaded, it gets loaded into a new ApplicationDomain. For whatever reason, when messages get returned from the server back to the client, our best guess was that it was still building objects using the classes from the ApplicationDomain from the first load. The profile confirmed that the old classes were still loaded, and weren't being garbage collected, in spite of our best efforts.

RemoteClass was a bit mystical and magical, but StackOverflow has deeper magic. Discovering that all RemoteClass does is invoke registerClassAlias for you, it was reasonable to think that it wasn't working properly on the subsequent loads.

So a quick trial using registerClassAlias instead of RemoteClass, and the Type Coercion errors go away. Voila!

Collatz

After seeing the xkcd on the Collatz Conjecture, I had to write an example in Scala.

def collatz(n:BigInt):Stream[BigInt] =
if (n == 1) {
   Stream(1);
} else {
   def next(n:BigInt):BigInt = if ((n % 2) == 0) (n / 2) else (n * 3 + 1);
   Stream.cons(n, collatz(next(n)));
}

That was a fun little diversion!

A little less noise, please.

If you work in big corporate America, like I somehow find myself these days, then the server hosting your Git depot has a really annoying /etc/issue file, which you see every time you clone/push/pull/fetch. In my case, it's 20+ lines of noise.

Finally found the magic to suppress the issue. Put the following lines in your ~/ssh/config file.

Host git-depot-server
LogLevel ERROR

Enjoy :-)

IDEA + git, without the passwords

Git is my new favorite in source control. IntelliJ IDEA has long been my favorite IDE.

A nuisance lately has been IDEA prompting me for my SSH key password every time I Commit and Push. Since forever, Ubuntu has added my key to ssh-agent every time I login, giving me both good security and password-less pushing from the command line.

I finally found the config tweak to push from IntelliJ without the prompt.

Settings-->Version Control-->VCSs-->Git
SSH Executable: Native

By using the native SSH client, you take advantage of native key management, like ssh-agent.

Agreement

Yes! I mean No! I mean I Agree!

in reference to:

"Any statics whatsoever Implementation inheritance (subclassing) Primitives Unnecessary boilerplate"
- noop - Project Hosting on Google Code (view on Google Sidewiki)

Mouse broke in Fedora 9? Here's a fix!

Last Friday, I was greeted by the unfortunately behaviour that my mouse stopped working. I checked my yum logs, and the culprit looked to be some recent updates to Xorg.

Looks like I guessed correctly. Someone was nice enough to post details about the problem, and how to fix it.

Thank you twilightomni!

Changing the gnome-keyring-password on Fedora 9

Fedora 9 improved its integration with the Gnome Keyring Manager over Fedora 8, in that your login password is used to automatically unlock the login keyring.

Which works great... until you change your login password. Changing the keyring password is similar to what one would do on Ubuntu, but a bit different.

1. Install seamonkey
   sudo yum -y install seamonkey
2. Run it
   seamonkey
3. Edit->Preferences->Password Keyrings
4. Select the 'login' keyring, and click 'Change Unlock Password'
   

Living in a virtual world

I have been extremely happy running Fedroa 8 on my ThinkPad T61. Dual screen works when I'm docked; wireless works around the house; all Linux, all the time. There are, unfortunately, a couple of minor hiccups.

The IT department at work is very Windows centric. The wireless is WPA2, using MSCHAP/PEAP for authentication. This should work with F8, but I can't quite get the config right. Then there's the VPN - it's this Windows only CheckPoint client. I think this is standard IPSec/IKE, so I should be able to divine out the config necessary to setup OpenSWAN. But I've yet to be successful figuring it out.

I've kept the Windows partition around for those few apps that I use that are Windows only. When I need wifi at the office, or VPN on the road, I just boot into Windows and I get it. But there's all of this Linux-y goodness on my laptop that's inaccessible; potential waiting to be tapped. And since I used LVM, not even tools that allow reading ext3 partitions work.

So what's a guy to do? I finally decided to try booting my Linux partition within VMWare, with Windows as the host OS. Things worked out much better than I expected.

For those adventurous enough to try this themselves, let me cover a few of the highlights.

Take ample backups before you begin. It's entirely possible that you could trash your Windows partition, your Linux partition, or even both. A small USB/Firewire drive and an hour or two to run the backups are all you'll need for the peace of mind that you can recover from such a dangerous undertaking.

Be sure your system boots into Linux by default. Windows is the VMware host, and with this setup, you could boot the very same partition under the VMware guest. This would wreak untold havoc, and is best avoided. Even if you configure the bootloader to prompt forever asking you to make a choice, make sure that the default choice is not the VMWare host. Besides, you only run Windows when you have to; right :-)

Be prepared to tweak your X settings. X configuration is probably the last bit of voodoo/black magic/unholy art within the usual operation of a Linux server that I know almost nothing about. (Well, that and Sendmail. Oh, yeah, and Bind. Maybe I'm not as smart as I thought...) But, as soon as you boot into VMware, X will fail to startup and you'll be staring at X's debug messages, thinking that a world of 80x24 really couldn't be all that bad. I was able to get to a not-quite-miserable place, where I can get displays to work for both native and VMware boots, with only a single line change to a config file when needed. (And a special thanks to the Gentoo guys who already did this sort of thing).

• move /etc/X11/xorg.conf to xorg.conf.bak
• restart X (init 4; init 5)
• login; run system-config-display
• configure the display as you like it, this will generate a new xorg.conf

How you proceed from here is up to you. You can have xorg.conf.vmware and xorg.conf.normal, and copy files and restart X when you switch between native boot and VMware boot. I decided to merge the files into one xorg.conf, and use a DefaultServerLayout option that I uncomment for those rare days that I boot under VMware.

Use a NAT network interface instead of a bridge. Normally, in VMware, you want your guest NIC to be bridged. However, on a laptop this is less than ideal. I'm not sure the virtual NIC will adjust as the real network adjusts. And I'm certain that it would not have access to the VPN, which is the main point of this exercise. So go with a NAT interface. You won't be able to access the virtual guest from anywhere but the VMware host, and you will have trouble with non-NAT friendly protocols. But I'm willing to bet that's less trouble than the alternative.

Disable snapshots. While the VMware snapshot facility sounds nice, it doesn't work so well when you boot directly into the virtual guest. Go ahead and turn it off in the virtual machine settings; you won't miss it.

Add a sound device. With this and fullscreen mode, you'll be asking yourself "Is it live, or is it VMware?"

I was surprise that I didn't have any more trouble than I did. I have the Windows partition mounted within Linux, but it recognized that it wasn't cleanly unmounted and refused to mount. The VMWare NIC shows up as eth1. I didn't even have to install VMware Tools for the mouse to auto-transition to and from the VMware console.

Subversion+Kerberos, without the realm!

We're using Subversion with Kerberos authentication here at work. I love having one-password-to-rule-them-all, but having the @REALM show up in the Subversion log is a bit of a pain. Today I came up with a solution.

It's very simple. I use a post-commit script to change the author revprop. The change in post-commit is quite trivial:

#
# strip Kerberos realm from svn:author
#
OLD_AUTHOR=$(svn pget svn:author file://$REPOS --revprop -r $REV)
NEW_AUTHOR=$(echo "$OLD_AUTHOR" | sed "s/$REALM//")

svn pset svn:author "$NEW_AUTHOR" file://$REPOS --revprop -r $REV

What's not so trivial is the change to pre-revprop-change. I wanted to ensure that only the change from user@REALM to just plain user was allowed.

NEW_VALUE=$(cat)

# ...

#
# Stripping Kerberos realm is allowed
#
if test "$ACTION" = M -a "$PROPNAME" = svn:author; then 
  OLD_AUTHOR=$(svnlook pget "$REPOS" svn:author --revprop -r $REV)
  echo "NEW: $NEW_VALUE"
  echo "OLD: $OLD_AUTHOR"
  ALLOWED_NEW_AUTHOR=$(echo "$OLD_AUTHOR" | sed "s/$REALM//")
  if test "$NEW_VALUE" = "$ALLOWED_NEW_AUTHOR"; then
    # allowed author change
    exit 0
  fi
  echo "svn:author $OLD_AUTHOR may only be changed to $ALLOWED_NEW_AUTHOR" >&2
  exit 1
fi

Making peace with NetworkManager

Being new to the Linux laptop scene, I've struggled with getting the network settings just right. I've always been more comfortable with text config files, but switching wireless networking settings is something that's best handled in a UI.

I've finally tweaked the network config and NetworkManager settings to behave properly.

I enabled the NetworkManager service: chkconfig NetworkManager on. Now whenever Gnome starts there's a little networking icon in the Notification Area. From there I can left-click to switch networks, config wireless, etc.

Next I took care of the delayed boot time when disconnected from the network (waiting for dhclient to time out). I disabled 'Activate device when computer starts' on both eth0 and wlan0. This can be done by system-config-network, or by editing /etc/sysconfig/networking/devices/ifcfg-{eth0,wlan0}. If I ever need network access from a non-GUI login, I simply ifup eth0.

The biggest difference that annoyed me was NetworkManager ignoring the Fedora init script's DHCP client config /etc/dhclient-eth0.conf. We have Win2k3 DNS/DHCP servers, so I need send fqdn.server-update and send host-name clauses in the dhclient config. The short story is, whenever NetworkManager started the interface, no one could resolve my laptop's name.

I finally discovered that NetworkManager uses /etc/dhclient.conf. I add the two magic lines to that file, point, click, I'm good to go.

Networking, finally, 'just works'.

Dual Head on ThinkPad T61

I've been running Fedora 8 on my ThinkPad T61 since November, and I've been reasonably happy with it.

The most irksome thing about the setup is that I had the hardest time getting both the DVI and VGA displays running as an extended desktop. Until now!

I still haven't worked out the vagaries of getting X configured, but once I'm at the desktop, it's a simple matter of

xrandr --output VGA --auto
xrandr --output VGA --right-of TMDS-1

Special thanks to the folks at intellinuxgraphics.org who led me down the path of multi-monitor bliss!

Update: In tweaking xorg.conf, I realized that it's necessary to add the clause Virtual 3200 1200 to Section "Screen", SubSection "Display". Without it, xrandr gives errors about max screen size.

Welcome, fellow monkeys!

I've had a personal blog for quite some time now. Lately I've felt the need to write about technology related stuff, but it didn't seem quite appropriate for The Way. So, here's my new blog. This will focus pretty much on software and technology related items I come across during my day.

Your feedback is appreciated :-)