One Soap Box

So I figure I'd throw my desktop onto the planet like others have done already. Here's what I see when I do startx (well, close):

After I start urxvt with tmux:

Opening a browser, uzbl

The status bar at the top is xmobar and shows things that are nice to know such as memory and CPU usage, weather, the current song that's being played, the date and time, and workspace information.

• GTK theme: whatever the default is
• Icon theme: ditto
• Cursor: bluecurve (I'm not a fan of dmz)
• Wallpaper: Chosen at random every time I log in (the one shown is one of my favorites); though I have the same problem Adam has and never really get to see it.
• Launcher: dmenu with a color scheme I'm really fond of
• Workspaces: Nine; mostly used as gatherers for various tasks

and this happened. So, as this table shows, Fedora's Haskell packages aren't all that expansive at the moment. This is a list of 50 packages that I filed review requests for within the last 18 hours or so (cabal2spec and various scripts I've made make a world of difference) plus some others which have been lingering for a while (xmobar and ghc-text, for instance). If anyone would like to trade reviews, I'd be happy to do some. Also, comaintainers are welcome. Come join #fedora-haskell and we'll trade off.

Basically the result so far is that yesod is packaged as well as some other dependencies of hledger. The yesod framework which is type-safe and has a RESTful interface. No broken links, no templates throwing tracebacks, and more. The author's blog explains it better than I can if you want details. hledger on the other hand is a financial book-keeping tool which uses the same format as ledger. It has a command line and a web interface (through yesod). It can also generate charts, but if I understand correctly this is going away. Unfortunately since the current release either gets the web or doesn't it can't be properly packaged so that it can be used on the terminal without dragging yesod around. Hopefully the next version will help with that. In the mean time, there are a lot of dependencies to review.

The tools I used as two functions that I wrote to help with these large dependency chains locally. The first is lintmock which runs rpmlint over the all of the resulting RPMs from a build. This is on each of the review requests I posted (ignore the strange permissions warnings; my umask of 027 isn't liked). The second one is uprepo which takes all of the RPMs from a build and stuffs them into a local repository and runs createrepo over it to prepare it for the next build. It also splits out debuginfo and source RPMs from the others and puts each in a separate repository. You can find the source for these and some other useful functions in my .zshrc (lines 303--367 at the time of this posting).

A while ago, Rob asked me to hack something together to grab some statistics from git. Being the kind of guy who likes reusing tools to make more complicated beasts, I used awk to do this. He recently asked me to document it better for future reference and so it's not just an email floating out there with obscure awk incantations in it.

git whatchanged --stat --format="%H %at %an" |
grep -v '|' |
awk '
    /^[a-f0-9]+ / {
        commit = $1
        time = $2
        sub(/^[a-f0-9]+ [0-9]+ /, "")
        name = $0
    }
    /changed/ {
        files = $1
        inserts = $4
        deletes = $6
        print commit "+" time " " files " " inserts " " deletes " " name
    }
    '

We first ask git for what has changed in the repository (whatchanged) and to get a diffstat instead of the actual diff of each commit. We ask for the commit format to have the hash (%H) followed by the authored time (%at) and the author's name (%an). The author can be different from the one who committed the code, so we ask who actually wrote the commit rather than the one with commit access. We then filter out all of the actual diffstat per-file data since git also sums it up nicely at the bottom.

When awk gets the data, it looks like:

122673a68a95a6f3a27c46624b5dd6d98fcbbab7 1281053627 Ben Boeckel

 1 files changed, 13 insertions(+), 0 deletions(-)

The first awk block:

/^[a-f0-9]+ / {
    commit = $1
    time = $2
    sub(/^[a-f0-9]+ [0-9]+ /, "")
    name = $0
}

Applies to the commit line (which matches the regex for hexcharacters at the beginning of a line followed by a space). It takes the commit hash, the timestamp and store it to variables. It then strips off those parts and uses the rest as the name.

The second awk block:

/changed/ {
    files = $1
    inserts = $4
    deletes = $6
    print commit "+" time " " files " " inserts " " deletes " " name
}

Parses the line that matches 'changed' and counts the number of files changed, lines inserted and lines deleted. It then makes a line composed of the information parsed from git. One weird thing about awk is that the blank character (space) is the concatenation operator on strings. It's a little weird since the spaces I want to insert then must be put in quotes and then surrounded by spaces making the line hard to parse without proper highlighting (which pygments lacks for awk it seems). This line can be put into a database and queried later.

There are a few shortcomings of the script in that if anyone authors a commit by the name 'changed', the second block will also match and screw things up. This is also the reason the per-file diffstat lines are grepped out. This can be fixed with a better match pattern on the second block (/^ / maybe), but it decreases the readability for those who don't know that there just happens to be a space on that line.

So it's been over two months since I last posted here. Since then, some things have changed. In no particular order, I've graduated from RPI with a bachelor's in Computer Science, started employment at Kitware, improved my Vim-fu (for later posts), migrated from using screen to tmux, turned 21, and got myself a Droid Incredible.

This post will focus on the Droid part, I have a list of things I'd like to write about here for later as well.

I've been happy with the phone since I got it at the end of June. It came with Android 2.1 and should get Froyo by the end of the year if all goes well. It has its pros and cons, as with any device. I wish I could find a case for it like my friend has for her Nexus One that is made of neoprene to hold it. Unfortunately the only case I found that I liked is a rubber-like material which is nice, but it leaves the screen exposed all the time which can be annoying. Other than that, the hardware is great. My previous phone was a baseline Nokia flip phone so I don't really have the experience to compare it to other smartphones.

Some of the workings of the phone are a little wonky to me. I wish that apps that require GPS to locate my location had an option to turn it on long enough to get it and then turn the GPS back off once the location was attained. It's a huge power drain and usually I care just enough to find my location on the Maps application and then navigate myself from there with directions instead of using the Navigation application. When switching between 3G and wireless, if I have it set that I don't care about unencrypted networks and I leave connectivity with my home router, the wireless can be turned off. Even if it did stay on, it doesn't automatically reconnect when I get back home (turning it off then back on is the quickest way to get it back when it disconnects, I've found), so that's more wasted power there.

With software, it's a mixed bag. I've yet to find a suitable MPD client to act as a remote control at home. I'm using BitMPC now, but it's still pretty slow, sometimes fails to display the current song, the controls don't come up, and other issues. I tried two others I found but they were even slower with the amount of songs in the playlist and library and I don't even have what is considered a large collection these days.

The games are alright. Enough to keep me interested when waiting around, but nothing I'd cry over if I didn't have access to them.

The built-in Gmail application is crap. I have it sync (manually since I'd like to keep activity down when I don't care, such as when I have mutt available) and it tells me I have new messages and fails to actually display them. The only way to get them, I found, is to hope the next sync gets new messages or clear out all data for it. I don't think I'd ever end up using an email client on the phone seriously anyways. All the ones I've seen top post by default and don't have options which makes it useless to me since that's not something I should have to fix by clicking under the text to reply.

For identi.ca, mustard is fine. Nothing spectacular, but also not a Twitter client which happens to be a status.net client which gives it points in my book.

For a browser, I use xScope Lite. I find that zooming with a double tap and slide is much better than a pinch gesture. I wish it were universal on the phone. I like it more than the built-in Browser, but it handles Flash miserably (which is fine as far as ads go, but for things like YouTube (I use youtube-dl on the desktop since they lack Flash as well) it's annoying. Speaking of YouTube, the app loves to not pause a video and instead restart it from the beginning if you leave to do something else. So while the video is loading, you're stuck there waiting. This seems, to me, like something that can be backgrounded and send out a notification when it's ready.

The bloatware that came with the phone really needs to go. There are some free trials that came with it that I can't remove even though I could care less about them. The CityID tool is one of them. It has a per-month usage fee and it's really not worth it for me.

Overall, I'm happy to have a smartphone. It's not something that I'd put in my "must have" category of gadgets though. Something in the always-on category is nice, but something a little lighter on the gimmicky stuff would do a lot better in my book. We'll see what's available when I can upgrade this in a little over a year.

Jesus Rodriguez recently posted about putting git information into his shell prompt with the mention that bash is the one and only shell ("In bash (is there really any other shell?)…"). I'd like to present my prompt as proof that bash is not the end-all-be-all shell. I have been using zsh for a while now and have had information on the VCS for the repository I'm currently browsing for a while. For git it usually looks like this:

while for Mercurial it looks like this:

and for Subversion:

This is all possible due to the awesome vcs_info plug-in that zsh has available. It includes support for all of the version control systems I use (git, cvs, svn) as well as those I encounter in other projects (hg, darcs) that I have checkouts of laying around.

I also like to have my prompt start at a consistent spot in the shell, so I put the date and current directory on the line before the actual prompt. Currently the vcs_info is set as RPROMPT since I've tried and failed to get it to right align on the first line (I wish zsh had %= as a filler space similar to screen).

Recently I had the joy of using git bisect to find a bug that I had introduced in a repository. Honestly, the beauty of it almost makes me want to make more mistakes when coding. I first tell git that some thing is broken and that it used to work:

git bisect start
git bisect bad
git bisect good <some revision from yesterday>

After this, git will then start walking me through the history to determine where the code went wrong. I tell git whether the current commit is good (git bisect good) or bad (git bisect bad). Some of the commits are untestable (due to a failure to compile with commits that dealt with an API change being propagated through the code base) which I tell git to skip (git bisect skip).

Unfortunately the code base was not as uniform as I usually like it to be so I missed an opportunity to have git do everything for me. Build failures destroy this since they have to be skipped and are neither good nor bad (though reading the documentation, using 125 as the exit code has git skip that revision). With a script that tested each revision, git could have done the testing for me (git bisect run ./my_script arg1 arg2).

I'm glad git bisect exists. Anyone else ever used it?

So I'm finally done with schoolwork. Woo! I had my last final yesterday and the irony of it is that the final class I have here is an introductory course in a field with little to no relation to my major (at the very least my concentration). The Introduction to Biology course here is required of all those who are in the School of Science and that includes computer science majors.

I am currently taking a course called "Advanced Computer Graphics" where we play around with various techniques such as cloth simulation, fluid simulation, ray tracing, and other things. Our most recent homework involved working with stencil buffers (which I don't really understand that well) and working with vertex and fragment shaders.

For the hardware in the class, most have the laptops that the school offers which are Thinkpads with either nVidia or ATi hardware. I have a desktop and two eeePCs with Intel hardware and a school laptop with nVidia hardware (as well as two other boxes, but they don't run X).

Pretty much everyone got the shaders to work except for one part (noise3) which wasn't supported by anybody's machine except my desktop in hardware on on one Mac and my Thinkpad in software. After doing a little digging, it turns out that nVidia (which many people have in the class) will never have noise*() in hardware. Apparently performance matters more than correctness.

All this means is that I'll stick with Nouveau even harder now for the machines I have nVidia hardware in already and Intel hardware for new machines where possible.

I use git for projects I maintain and I try to use it where possible in group projects. I love how I can do work offline, branching is extremely cheap and easy, it's fast and I can make sure that my history is clean. I'd like to write about how I use git so that others can learn from it and that I may also get feedback on how to improve my workflow.

Today I'd like to go over what are known as "feature" or "topic" branches. These are especially useful when you are working with multiple remote repositories, but are also useful for your solo projects. I'll be going over it through an example I hit recently with the two remote repository situation. This usually happens when you have read-only access to the upstream repository and you create your own fork of it so that you have write access to a public repository. Your repository is so that patches you write can be pulled by upstream to merge changes you make into upstream more easily.

For Firmant, I have my own repository that I publish my changes to configured as the cledwyn whereas the official upstream is configured as origin. This is so that Rob may pull from my server and merge my changes from there rather than emailing sets of patches around.

One issue that arises from this is when you push to your repository on master while upstream pushes different code to their master. Since these are public repositories, a force push should not be used, but in this situation, one of the repositories has to be force pushed or merge commits (which I like to avoid when just updating code from a remote repository) would need to be made. Upstream is the worse choice here since it is the official repository. How should one avoid this issue altogether? Since git makes branching easy and fast, this is easy to avoid.

Say that I were to work on the LaTeX feature targeted of Firmant 0.4. If I were to develop on my master branch, I would have to keep rebasing and force-pushing to my repository if I wanted to keep it public somewhere and up-to-date with the latest changes upstream is making without those pesky merge commits. The other possibility is to use a branch to develop the LaTeX functionality. To create this branch, I would issue the following git command:

% git checkout -b dev/latex

This creates a branch named dev/latex and makes it the current HEAD. From here, I can work on the LaTeX code without worrying about clashing branches with upstream. When I am done with the feature (properly documented and tested of course), I can ask Rob to merge my branch into his master.

In order to keep the topic branch up-to-date with master, I merge the master branch into the dev/latex branch:

% git merge --no-ff master # (1)
% # Edit merge conflicts   # (2)
% git add file1 file2      # (3)
% git commit               # (4)

Here's a description of what is happening:

1. Merge the changes that have occurred upstream into the dev/latex branch. If all goes well, steps 2 and 3 will be taken care of by git. The --no-ff option ensures that a merge commit is made (this is one instance where they are convenient to have, but I'll post about that later).
2. Fix any merge conflicts.
3. Add files that conflicted.
4. Commit the changes.

This keeps my feature branch up-to-date and also allows my master branch to track upstream's master. When I request that Rob merge my commits, I would mention that the dev/latex branch should be merged into master.

Since branches are cheap, I can keep many different topic branches around for various features so that the history for each feature is easily visible and not intermixed with things like commits fixing typos or bugs. This allows a cleaner history to be made so that you can follow the development of a feature instead of having to sift it out from the entire changeset since the feature was started.

In other version control systems, every feature branch would be a complete copy of master which, for large code bases, can become unwieldy and a mess.

I have a weird sense of humor. Hence the (now) old slogan of "Things I thought people might like to know". This was meant to poke fun at blogs in general since that's what they are in essence. I had originally thought of putting "(but probably don't need to)" on there, but thought better of it since I actually wanted readers for my own.

So to go along with the new layout (I've gotten rid of the old thick borders in favor of slimmer borders), I'm going to change the slogan as well. In going with the new style of posts I would like to do, I'm changing the slogan to "Helping software suck less since time_t(0)".