David Singleton
Using xargs like I mean it, a bash example.

Using xargs like I mean it. svn st * | grep “^ C” | cut -c 8- | xargs svn revert

A couple of people asked me to explain what this did, so here’s a quick 2 minute explanation (I’ll assume you’re familiar with unix pipes)

First, what was I trying to do? I’d just merged a large branch back down to trunk and for some reason it had a huge number of SVN property conflicts. I wanted to resolve or revert all of these before committing the reset of my changes.

I could have fixed them individually, but that’s a lot of repetition and there are more elegant ways to do it programmatically.

So how does this resolve only my property conflicts?

First get a list of all modified files in our SVN respiratory (in my case, this was actually multiple repositories)

svn st *

I’m only interested in the property conflicts though. Property status codes are differentiated from regular status changes by a space prefix. The grep filters our list of SVN changes to just these.

grep "^ C"

The output at this stage looks something like ” C path/to/file” (for each matched file). I want just the file name and need to strip the preceding information. Luckily the length of this prefixed information is a constant 7 characters. Cut lets you chop lines based on delimiters (like tabs, or commas), or by character, here I use it to get the 8th character and onwards

cut -c 8-

At this point we have a list of file paths, one per line. xargs is a command that can take another command (and it’s options, flags, etc) and run it for a large list of files. The files are passed via standard input, one file per line. So this is telling xargs to run svn revert for each of the files passed from the previous commands.

xargs svn revert

The end result is that all my property change conflicted files have been reverted, though I could have equally resolved, or told SVN to use my version.

I hope this is a nice little example of the power of the unix command line philosophy, lots of small commands - that do one thing very well - chained together with pipes.

Installing Playdar on OS X 10.4

Congrutulations, you’re on an outdated verison of OS X, but you still want to play with cool things like Playdar. Here’s a hassle filled guide to compiling it from source.

To do this you’ll need XCode (2.4 for Tiger), Macports and Git to start.

XCode 2.4: https://connect.apple.com/cgi-bin/WebObjects/MemberSite.woa/wa/getSoftware?bundleID=20262

MacPorts: http://www.macports.org/install.php

Git: http://metastatic.org/source/git-osx.html

Once you’ve got those tools installed you can focus on Playdar itself. First, we need to load Playdar specific dependecies via mac ports. This is easy, but takes a little while.

$ sudo port install cmake boost ossp-uuid uriparser taglib git-core sqlite3

Next grab playdar from Git;

$ git clone git://github.com/RJ/playdar.git
$ cd playdar

Now to build it from source.

$ cd build
$ cmake ..

I’m not 100% sure this is a 10.4 specific issue, but i’ve had the same thing happen on two machines. CMake will find an old version of sqlite that won’t compile with Playdar. The quickest hack is to move/backup the “incorrect”, sym-link the correct version in it’s place and then make as normal.

$ sudo mv /usr/lib/libsqlite3.dylib{,.bk}
$ sudo ln -s /opt/local/lib/libsqlite3.dylib /usr/lib/libsqlite3.dylib

Finally we can compile the playdar bin itself. $ make

Undo our sqlite path hack (if you had to do it)

$ sudo mv -f /usr/lib/libsqlite3.dylib{.bk,} 

Make it!

$ make

You should now have a playdar file in bin/. Hurrah, the hard bit is over now to do our DB setup and config.

$ cd playdar 

I had this on one machine but not the other, use the normal instructions in INSTALL.txt unless you get an SQLite error about “NOT, in which case use this.

$ sed 's/IF NOT EXISTS //' etc/schema.sql | sqlite3 ../collection.db

Load your music collection. Depending on the size this can take a while.

$ ./bin/scanner ./collection.db ~/Music/MP3/

Run it.

$ ./bin/playdar -c ./etc/playdar.conf
A last.fm tag-cloud generated from XSL

19/07/2009: The script in this post is currently broken, it’ll be fixed soon

If you use last.fm the you can get some pretty interesting statistical data about your musical habits.

Being a web and music geek I’ve put together a simple tag-cloud to show what i’ve listened to that week. Everyone loves a nice tag-cloud.

You can take a look at the finished version on my Music page.

How it was made

I’ve had a rough version of this for a while, but it had quite a few issues, was generally a little broken and not very semantic. So I took a few hours to re-write it and make then make it public.

First of it all it uses my last.fm Weekly Artists XML, which gets turned in to HTML through a simple XSL transformation then styled with CSS.

The glue that holds it together is the extremely useful inlineRSS plugin for Wordpress. this handled the fetching of the XML and the XSL transformation, with a little caching too.

XSL Transformation

Take a look at the full XSL file.

The XSL that converts the last.fm feed into the tag-cloud HMTL is fairly simple, grabbing a bunch of artists and looping through them to build an ordered list. The tricky bit is defining the differing sizes between artists based on the playcount. There are a couple of other bits might benefit from further explanation:

<xsl:variable name="max_artists" select="20"/>
<xsl:variable name="min_playcount" select="2" />

These specify a maximum number of artists and a minimum number of plays to be included in the cloud. This solves two problems, a large number of artists being played making the tag-cloud huge and playing just one or two tracks for an artist (Like with compilations) which just swamps the tag cloud with lots of low played artists.

<xsl:variable name="weight" select="playcount div $max_playcount" />
<xsl:variable name="size" select="($weight * $size_range) + $size_min" />

To calculate the weighting, how big the font-size should be, it takes the highest played artists playcount as a baseline and treats every other artist as a fraction of that. This fraction, the weight, is then used to the size using the min and max sizes as boundaries.

The rest of the XSL just builds the list, link and span tags/content.

<xsl:variable name="artists" select="/weeklyartistchart/artist[playcount >= $min_playcount and position() <= $max_artists]" />

This is the XPATH query used to get the set of valid artists than have the minimum playcount and caped at the maximum number of artists

Semantics

Tag-clouds have a reputation as being pretty unsemantic when it comes to HTML. Often just being an alphabetised list when viewed without styling. Norm had a go at marking up tag-clouds semantically, which i’ve followed with one exception.

Rather than using a set of class names I opted for inline styles declaring the font-size. Heresy! Well, yes and no. I want the cloud items to be properly scaled and the scale easy to modify, this just isn’t possible using a set combination of classes mapped to sizes.

This doesn’t really bother me much, especially with the extra semantic information added. So the final markup looks like so:

<li style="font-size: 4.000em;">     <span><span class="weighting">26</span> listens to</span>     <a xhref="http://www.last.fm/music/Stars" mce_href="http://www.last.fm/music/Stars" title="Stars (26 listens)">         Stars     </a> </li> <li style="font-size: 3.077em;">     <span><span class="weighting">18</span> listens to</span>     <a xhref="http://www.last.fm/music/The+Microphones" mce_href="http://www.last.fm/music/The+Microphones" title="The Microphones (18 listens)">         The Microphones     </a> </li>

If you’re paying attention you’ll have spotted another span in there, inside the one used to hide the non-artist-name information. Why add it? It gives a semantic hook to get the actual weighting value of the cloud, in this case listens.

With this you could create a very simple piece of javascript to turn the tag cloud back in to a chart, ordered by listens rather than alphabetically.

Styling

There’s only some very simple styling on the list itself. Mostly just visual formating, but importantly a rule to hide the span of contextual information leaving just the artist name.

ol {
width: 700px;
margin: 0 auto;

list-style: none;
text-align: center;

font-size: .6em;
}

li {
display: inline;
margin: 0 .2em;
padding: 0 .3em;

line-height: 1.5;
vertical-align: middle;
}

li span {
position: absolute;
left: -999px;
width: 990px;
}

Known Issues

There are still a few things I’m unhappy about with this, when using artist names rather than tags you’re far more likely to get spaces and end up with an artist name split across two lines. This can often end up looking like two separate artists if you’re not familiar with the name.

And, the obvious problem – it’s all reliant on data from another site, last.fm. I can’t be sure it’ll always be up, or that formats wont change. This is the price you pay for relying on external service, in this case it’s nothing critical or even important, but it’s something people seem to forget a lot of the time.

Demo

I built a little demo page where you can enter your last.fm username (or a friends) and see a tag cloud of your recently weekly artists. Check out a few examples;

Give it a try.

Code Golf: Whats your handicap?

Over the holidays I came discovered Code Golf and got quite addicted to one of the challenges, for those unfamiiar with it:

Based on the original perl golf, Code Golf allows you to show off your code-fu by trying to solve coding problems using the least number of keystrokes.

You’re not just limited to Perl either - PHP, Python and Ruby are all available too.

Challenges are always open, and your entries are automatically scored so you can start playing right away!

I spent most of the holidays tweeking and tuning my enrty for the 99 bottles and managed to get my entry down to 209 bytes. Far from a winning score, but for my first attempt - and using PHP - i’m quite pleased.

The resulting code is pretty much unreadable, no line breaks, single character variable names - and yes, that kind of code should never rear it’ ugly head in serious project, but its a work out for some of the coding muscles you may not use very often or even at all.

So have a go, try one of the challenges stretch your brain a bit, or if you’re learning a new language try one of those and get to know some of the dusty corners of the lanuage you’d other wise miss.

More importantly, have a go at 99 Bottles of Beer and tell me how you did.

Google Code Search

Yesterday Google launched a new search for source code, this is such a great idea that I can’t believe its not happened before. You can search by a variety of languages, licence types and best of all by regular expressions.

There’s already been a lot of interesting, funny, and downright scary things turned up, best summed up By Jason Kottke. Some of the highlights include profanity, frustration and and of course losing all hope.

So far I’ve used this twice in the last two days for actual work, not just fucking around, which I found pretty impressive. I’ve already added a quick search in Firefox for PHP code, so I can just ‘grep function name‘.

I can imagine it being similar to the recent AOL search data being made public, we’ll be able to proverbally peek through other developer’s curtains and make snide comments on thier choice of upholstery (or naming convention).

I wouldn’t be suprised if stats from this end up used in a “Well the average perl function for this is 4 lines, it’s 8 for PHP, so it sucks!!!” way, but the statistics you could generate would be very interesting.

Of course over the next few weeks and months bad code will be probably be publicly mocked, exploits will be found people will panic and people will repeatedly search for swear words. But i’m sure that people are already working on tools to make this new search even better and more useful, and I can’t wait to see what else will come out of this.