One Soap Box

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)".

So I'm running Fedora 13 on my machine. I recently upgraded to X.org 1.8.0 and two bugs have appeared since updating from xorg-x11-server-Xorg-1.7.99.902-3.20100319.fc13.i686.

No working mouse buttons has created an interesting situation where I am forced to use the keyboard for everything. It hasn't really changed much. I really miss the X selection buffer and the ability to click links in urxvt. Bugzilla is also an interesting adventure to navigate without a mouse. Luckily uzbl has a plugin to tag links with letters (similar to Konqueror's "Access Keys"). Copy/paste is done using screen's copy buffer (^A{ to go into copy mode, space to set a start and end point for the copy (with Vim-like movement keys) and } to do the copy itself. The ^A} command then replays the copied keys into the current terminal (being in Insert mode in Vim is helpful).

Yesterday I got a patch upstreamed to Firmant that handles static pages that are written in reStructuredText. The "About" page in the first sidebar box on the right is managed this way. This will allow me to manage my project websites using Firmant as well. These should be coming up as I get to work on them. In addition I should be getting an actual homepage rather than the nginx default.

After this work, I worked on converting some of my old posts from the format in the database to reStructuredText. One of the more annoying things to convert are the links. After manually doing the first two of the posts, I recorded a macro within Vim to do this for me. For anyone else that's converting over to Firmant from an HTML-based blog format, this will be extremely helpful:

/<a<CR>v8ld"udt"2s`<ESC>/<\/a<CR>4s <>`_<ESC>2h"uP

Step by step, here is what is happening:

• /<a<CR> --- Search for the opening tag for an anchor.
• v8ld --- Visually select 8 characters to the right and delete them (this could be condensed to d8l). This requires that you have Vim set to be able to go to the next line when moving right or left. If you do not have this set, d8gl is what you need.
• "udt" --- Delete text until the next " character and place it in the u buffer.
• 2s`<ESC> --- Replace the next two characters (the "> of the anchor tag) with a single ` and return to normal mode.
• /<\/a<CR> --- Search for the end tag of the anchor.
• 4s <>`_<ESC> --- Replace the next four characters (the complete end tag) with <>`_ and return to normal mode.
• 2h"uP --- Move left two characters and paste the u buffer before the current position.

Once this is done to convert all of the links, I remove any escaping characters (usually single quotes from the database dump) and reflow all of the paragraphs with what is probably my favorite Vim command: vipgq. This means "visually select the paragraph I am in (vip) and reformat it to fit within my current textwidth setting (gq)". I use a textwidth of 78 personally. Hope this helps!

John Hawley of kernel.org has been gracious enough to accept CHASM as a project under the kernel.org mentor organization. CHASM stands for Cryptographic-Hash-Algorithm-Secured Mirroring solution. The CHASM website has a post by Rob describing it.

Instructions are on the GSoC mentor organization page for kernel.org. Other ideas for GSoC are on kernel.org's wiki.

So Rob Escriva released Firmant today and I'll be converting all of my old posts over to it in the coming weeks.

What makes Firmant really cool is that I can edit all of my posts locally, keep them in version control and then push them to my server via rsync. Firmant also uses static HTML which makes cledwyn (old Compaq from 2000) happy. It does not support comments at the moment, but it would support them by having submissions via email and then I would put them onto the post and publish the blog again. Until I can get my email configuration figured out, please send comments to this domain (minus any subdomains) and the user ben with "[one-soap-box] <title>" as the subject.

I've gotten the styling (which uses CSS3) to work with browsers down to 680 or so pixels wide. If anyone has more CSS-fu than I do and knows how to get the content div to be able to shrink, I'd be grateful to learn. Also, any comments on how I could improve the layout or color scheme would be wonderful.

Hopefully this will cause me to write here more often since I can just write things locally and publish then when I can.

Since my last update, I have changed my setup quite a bit. I now use xmonad and have migrated to using (mostly) terminal applications. Since I am a tinkerer, I've tweaked by configurations quite a bit. I've been asked by friends to go over my setup and explain how I get the applications I use to behave the way I like. I'll also post about short commands that I use to do complex things (sed and/or awk are usually involved) such as converting an entire collection from flac to ogg format.

I'll also be posting more about projects I work on. Lately there have been a few interesting ones, but I'll do a separate post for each of those.