Vi: properly format XML on one line

During testing, I sometimes dump XML responses straight to a file for investigation. Rather than writing test code to format it properly, and then get rid of it when I don't need it anymore, I wrote me a vim macro. Keep in mind this will only work if everything is on one line.

This in my .vimrc:

nnoremap :set ft=xml:%s/\(<[^\/].\{-}>\)/\r\1/g:%s/\(<\/.\{-}>\)\(<\/\)/>\1\r\2/g:g/^$/dvG=


Et voila - F10 gets me a nicely formatted file.

Interactive JavaScript console

I found an interesting tutorial which explains how to set up an interactive JavaScript console using Rhino.

Jivedude pointed out that there's a problem with it: putting jar files in lib/ext is a bad idea, since every single Java app will then embed these libraries, even if they don't need them.
In addition to the obvious bloat problem, this can also cause version and incompatibility issues. His suggestion: use java -cp (classpath).

Assuming I put the jar files in /home/erik/lib/, the command then becomes:
java -cp '/home/erik/lib/*' org.mozilla.javascript.tools.shell.Main"

Conky with Awesome3

I've managed to get Conky configured as a bar at the bottom of my screen in Awesome3, while keeping windows from overlapping with it. In Awesome2 it was possible to pipe Conky's output into awesome-wm, in Awesome3 this isn't the case any more.

The solution is to create a very horizontal Conky configuration and combine that with a one-pixel-wide wibox at the place where you place your Conky bar. The wibox will prevent windows from hiding your conky, and with the right colour configurations it will look like part of your AwesomeWM.

The Awesome configuration ( ~/.config/awesome/rc.lua ) looks like this:

mystatusbar = awful.wibox({ position = "bottom", screen = 1, ontop = false, width = 1, height = 16 })


  • position = "bottom" puts the wibox at the bottom of the screen
  • screen = 1 places the wibox on screen 1
  • ontop = false means it doesn't have to be on top of other windows (it'll be empty anyway)
  • width = 1: one pixel wide is enough
  • height = 16: in my case, this is exactly the height of my Conky, so windows will touch it without overlapping


And the Conky configuration( ~/.conkyrc ).

In the TEXT block, notice the \ at the end of every line - this is equivalent to putting the whole thing on one line, only it's easier to read and maintain. There should be no blank lines after the last configuration line, because Conky will draw them.

Of course, if you want {n} lines, you can. Just make sure to adjust the height of your wibox accordingly.

alignment bottom_middle
background yes
border_width 1
cpu_avg_samples 2
default_color 222222
default_outline_color 222222
draw_borders no
draw_graph_borders yes
draw_outline no
draw_shades no
use_xft yes
#xftfont DejaVu Sans Mono:size=12
xftfont Sans Mono:size=8
gap_x 5
gap_y 0
minimum_size 1260 6
maximum_width 1260
net_avg_samples 2
no_buffers yes
out_to_console no
out_to_stderr no
extra_newline no
own_window no
own_window_class Conky
own_window_type desktop
own_window_transparent yes
stippled_borders 0
update_interval 1.0
uppercase no
use_spacer left
show_graph_scale no
show_graph_range no
format_human_readable yes

color1 666666
color2 888888
color3 444444

mpd_host 127.0.0.1

TEXT
${if_mpd_playing} [${mpd_status} - ${mpd_elapsed}/${mpd_length}] ${scroll 35 5 ${mpd_smart}} ${else} \
${color1}Activity on /dev/sda:${color} ${diskiograph 10,50 000000 ff0000 -t}${endif} \
${alignr}${color1}br0 [${color3}${addr br0}${color}]: ${color1}Up:${color} ${upspeed br0} ${color1} - Down:${color} ${downspeed br0} \
${alignr}${color1}Battery: [${color3}${acpiacadapter}${color1}] ${color}${battery_percent BAT1}% ${battery_bar 5,50 BAT1} | \
${color1}CPU: ${color} ${cpu}% ${cpubar cpu0 5,50} ${color2}CPU1: ${cpubar cpu1 5,50} CPU2: ${cpubar cpu2 5,50} ${color}| \
${color1}RAM:${color} ${memperc}% ${membar 5,50}

SNMP trap forwarding to multiple destinations

It's quite simple, really... I'm not sure why it didn't work sooner. All that's needed in /etc/snmp/snmptrapd.conf is this:

disableAuthorization yes

forward default :162
forward default :2162


WebOS development in vim

After getting frustrated with Aptana + Eclipse I decided to start using vim for my WebOS development needs. One of the more interesting features of the WebOS Eclipse plugin is the ability to generate a new scene without having to manually call palm-generate.

So I made a vim command (put this in your ~/.vimrc):
let basedir = "/DATA/projects"

function GenerateScene(basedir, project, name)
exe '!palm-generate -t new_scene -p "name=' . a:name . '" ' . basedir . '/' . a:project
endfunction

command -nargs=+ Newscene call GenerateScene(basedir, )


Now whenever I call :Newscene a new scene called scene-name will be created in /DATA/projects/project

Switching projects?
:let basedir="/path/to/new/project"


Of course, after doing some development I want to do a testrun as well. You'll need to make sure both novacomd and the emulator are running.

The command for packaging, installing and launching the app on the emulator:
:Testrun


And for cleaning up (uninstall and remove the ipk file):
:Cleanup


Here's the code for your ~/.vimrc file:

let domain = "be.venefyxatu.palm."
let appversion = "1.0.0"

function GenerateScene(basedir, project, name)
exe '!palm-generate -t new_scene -p "name=' . a:name . '" ' . a:basedir . '/' . a:project
endfunction

command -nargs=+ Newscene call GenerateScene(basedir, )

function Testrun(basedir, domain, appversion, project)
call PackageApp(a:basedir, a:project)
call InstallApp(a:domain, a:project, a:appversion)
call LaunchApp(a:domain, a:project)
endfunction

function PackageApp(basedir, project)
silent exe '!palm-package ' . a:basedir . '/' . a:project
endfunction

function InstallApp(domain, project, appversion)
silent exe '!palm-install ' . a:domain . a:project . '_' . a:appversion . '_all.ipk'
endfunction

function LaunchApp(domain, project)
silent exe '!palm-launch ' . a:domain . a:project
endfunction

function RemoveApp(basedir, domain, appversion, project)
silent exe '!palm-install -r ' . a:domain . a:project
silent exe '!rm -f ' . a:basedir . '/' . a:project . '/' . a:domain . a:project . '_' . a:appversion . '_all.ipk'
endfunction

command -nargs=1 Testrun call Testrun(basedir, domain, appversion, )
command -nargs=1 Cleanup call RemoveApp(basedir, domain, appversion, )


Yes, there is probably a way to get the domain and version from the appinfo.json file, but I can't really be bothered :-)

This might be interesting as a vim extension as well ... but once again I can't really be bothered :-)

Palm Pre in Belgium with Mobile Vikings

First of all: all credit for this trick goes to Andreas at TreoCentral. Here is the exact thread where I found it.

I've bought an unlocked Palm Pre in the Netherlands. Unfortunately, before it becomes usable, it needs to activate itself through your provider's data network. As it happens, I just switched to Mobile Vikings, a provider which the Pre doesn't know.

Oops.

Internet to the rescue!

It is said that WebOS 1.3 offers the possibility to enter custom data settings in the activation wizard. Let's upgrade this baby!


  • First of all: my device is originally German (the QWERTZ keyboard is a dead giveaway ;-) ), so I've downloaded the German WebOS Doctor.
  • To put the Pre in WebOS Doctor mode:

    • Turn it off completely
    • Put the wall charger into an outlet and connect the mini USB connector to the Pre. Do not connect the USB port to the wall charger yet!
    • While connecting the USB port to the wall charger, keep the "volume up" key pressed. You'll see a USB logo appear on the Pre.
    • Disconnect the USB port on the wall charger and plug the Pre into your computer.
    • Launch WebOS Doctor and follow the instructions in the wizard (I chose German just to make sure - don't know how important it is). It will recognize your Pre and start upgrading.

  • When the upgrade is done, your Pre will restart and relaunch the setup wizard. When it gets to the point where account creation fails, you will be given the option to enter custom data profile settings. Enter your provider's settings et voila, one working Palm Pre.

GPGMail on OS X Snow Leopard

With the upgrade from Leopard to Snow Leopard, and the included update for AppleMail, GPGMail was broken due to it using an undocumented API which has, of course, changed.

Fortunately, people more knowledgeable than I have fixed this by now, making it relatively easy to get things going again.

First of all, close AppleMail.

The next thing to do is to get gpg up and running again. There is an excellent explanation right here (http://macgpg.sourceforge.net/docs/howto-build-gpg-osx.txt.asc), which will allow you to copy/paste your way through the whole thing. It's your basic ./configure; make; make install; except that on Snow Leopard, you need to specify that you want to compile it for 32bit mode, like so :

./configure CC="gcc -arch i386"

Next, download this GPGMail.bundle: http://dl.getdropbox.com/u/20215/GPGMail-1.2.1.mailbundle.zip (see the discussion thread, there is probably a newer one by now), unzip it and place the result in ~/Library/Mail/Bundles/

In my case, I had to open the bundle (Ctrl-click, "Show Package Contents") and edit Contents -> Info.plist (using Property List Editor). It was missing two GUIDs, which I found like so:

venefyxatu@Succubus$ grep -A 1 UUID /Applications/Mail.app/Contents/Info.plist 
PluginCompatibilityUUID
2F0CF6F9-35BA-4812-9CB2-155C0FDB9B0F

venefyxatu@Succubus$ grep -A1 UUID /System/Library/Frameworks/\
Message.framework/Resources/Info.plist
PluginCompatibilityUUID
0CB5F2A0-A173-4809-86E3-9317261F1745


For each of those, copy the GUID (the bit in the tag) and add it as a child to SupportedPluginCompatibilityUUID.

That's it. Start AppleMail and it should load the plugin, once again giving you access to the GPG settings.

TweetDeck on Gentoo with Awesome

After seeing it in action I wanted to give TweetDeck a try so, optimist that I am, I tried their installer. It didn't work, complaining about a corrupt .air file. So I figured I'd install the AIR framework first and then see where that would get me. All the way to this error message :
Adobe AIR could not be installed because this is not a supported Linux distribution. Only RPM- and Debian-based Linux distributions are supported.
Gentoo? Source-based distros? Get lost! Fortunately, flashman already ran into the problem and figured out a way to get AIR applications running on his distro and documented it.
One more problem: I don't use Gnome. I don't use KDE. I'm an Awesome fan. AIR doesn't like it when people don't use Gnome or KDE on linux. It requires gnome-keyring or KWallet and it gets confused rather easily. According to the Adobe troubleshooting page, you can set it straight by exporting a variable.
For gnome-keyring:
$ export GNOME_DESKTOP_SESSION_ID=1

For KWallet:
$ export KDE_FULL_SESSION=1

If you've got a KDE4 based KWallet, you also want to do:
$ export KDE_SESSION_VERSION=4

Ka-boom! TweetDeck on Awesome on Gentoo. And I can start it with Winkey-F10 as well, like so:
awful.key({ modkey }, "F10",
function ()
awful.util.spawn_with_shell("export GNOME_DESKTOP_SESSION_ID=1;
/opt/air-sdk/bin/adl -nodebug \
/opt/air-apps/TweetDeck/META-INF/AIR/application.xml \
/opt/air-apps/TweetDeck")
end),

Mojo SDK getting up and running

Palm finally released their WebOS SDK to the public (to be found on http://developer.palm.com ). Here's what I did to get things up and running on my Gentoo laptop:


  • Download the .deb file
  • Convert the .deb file to a tarball ( deb2targz )
  • Extract the thing to /
  • Try `palm-emulator` and swear some because "Palm Emulator requires that VirtualBox 2.2.0 or greater is installed." 2.2.4 > 2.2.0, right?
  • Some decompiling of the jar files reveals that on Linux, the virtualbox classes simply search for /usr/bin/VBoxManage. If it's installed somewhere else, tough luck, you don't have virtualbox. A symlink fixes this.
    Note: on Windows, `reg query HKLM\SOFTWARE\Sun\xVM VirtualBox /v InstallDir` is used to determine the installation directory. On my Vista x64 box I can execute this query in a DOS prompt and get the correct result, even though the emulator complains.
  • Ignore the novacom warning for now and presto, one booting WebOS VBox machine.


The novacom warning :

In order to install or debug applications in the Palm Emulator, the novacom
service must be running on your desktop.

Please verify that you have the latest Palm SDK installed correctly.

`sudo /opt/Palm/novacom/novacomd` fixes this. There's a /etc/event.d/palm-novacomd script which makes the novacom service start on rulevels 2, 3, 4 and 5. This is probably a very debian-ish way to do things, but won't quite work for me ;-)
Anyway, I have a running virtual machine and I should be able to install and debug applications from Eclipse. I'm happy. For now :-)

Mutt configuration

I've commented and cleaned up my Mutt configuration files. While I feel you can get the most out of Mutt by writing your own config, these might be helpful in getting someone started. They should also be a pretty good example for usage of the account_hook and folder_hook.

They can be found, along with some other config, on Github: https://github.com/Venefyxatu/Configurations