Monday, April 30, 2007

Pedometers

I’ve never mentioned it, but my sister gave me a pedometer for Christmas, and it has been a fun toy. I discovered that I travel about 47 inches per step when jogging and about 28 inches per step when walking. I also learned that I walk/jog/sprint about 4 miles when I play Ultimate Frisbee at lunch time, and that if I walk to work, I take about 2664 steps from my front door to my desk. That’s about 1.18 miles if you are following along and doing the math. Cool stuff to know (and I didn’t have to carry around an expensive battery-devouring GPS to find it all out).

This week my 6 year-old got a pedometer from a box of cereal. He loves wearing it around. He puts it on and starts running around the house and then checking how many steps he’s taken. It’s amazing how quickly he can get up into the hundreds just bouncing from couch to couch. I wonder how accurate his free pedometer is, but if the idea was to get kids to exercise more, it’s working for him. Not that he had much trouble with that before.

This evening we hiked the Camas Lily Loop at Lacamas Park as a family. The Lilies were in bloom and the fields of purple were beautiful (forgot the camera, sorry). My wife and I carried the baby and the three year-old, respectively, in our mei tais. That’s the longest I’ve worn one with a heavier kiddo and it was surprisingly comfortable. Our 6 year-old walked the whole way without too much complaining.

When we got home we compared pedometers. Mine said 7338 steps, and his 7863. That’s about 3 and a quarter miles going by my stride length. Not a bad hike! One of our step counts must be off though, otherwise his stride length is only two inches shorter than mine. Carrying a 40 pound load probably affected my stride, but I don’t know if it shortened it that much. Hmm, maybe we should have brought that GPS along.

Thursday, April 26, 2007

Mozilla's Version Control Research

I stumbled upon a really interesting blog entry about the Mozilla Project's research into version control. I actually remembered reading the first part a while back, and now part two is out. They have done some good research, and considered things like importing from CVS, performance, and how well the different systems work on windoze (hitting different areas than I did). Follow the links in the entries to see the nitty gritty details, and, if for no other reason, go read both parts to see the awesome Mortal Kombat screenshots. I won't spoil the end and tell you which one they are going with (though the news is two weeks old and you probably knew all of this already. Where have I been? Sheesh).

Tuesday, April 24, 2007

Edgy to Feisty

I upgraded my Edgy Eft box to Feisty Fawn today at work (my home machine is more, um, sensitive and will come later). Had a few problems. When Gnome first loaded up and I started firefox and thunderbird, everything froze. I did the magic reboot and started searching google on my other machine. Nobody has a good answer, but I have only seen it one more time, and it passed without me having to reboot.

Another issue is that apache wouldn't start because of the PythonPath directive in my MoinMoin wiki setup. I did some aptituding and it got fixed. I think I did: aptitude update, aptitude upgrade, aptitude dist-upgrade, aptitude install python-moinmoin, and aptitude install libapache2-mod-python. I think a missing mod-python was the final culprit. Don't know why that was removed during the upgrade.

Then I had problems getting the ever important Beryl to run. First I tried the new System->Preferences->Desktop Effects, but that started Compiz with none of my keyboard shortcuts and stuff that I'd set up with Beryl before. I undid that and ran beryl-manager from a command-line like I've been doing and it started, but I had no window borders (or decorations or whatever they're called). I found an Ubuntu forum thread that helped, but I went with the recommendation in this blog entry in the end.

Not only did I get window borders back, but everything is a whole lot snappier than it was with Beryl before. I'll take it.

Friday, April 20, 2007

A Better Shell

The product I'm helping to develop at work has a TCP service that you can telnet to and get a simple command-line shell for development purposes. In our firmware we have a simple framework for writing commands that can then be called from this shell. You can do all sorts of handy things like check sensors, run calibrations, query ASIC registers, read and write memory locations, and so forth. We also use this to play with different configurations and new features before making them permanent. The big downside to this shell is that, well, let's just say that for anyone used to a modern shell like bash, this one is stone-age. There is no command history, no command-line editing except to backspace and retype, and no scripting. This can get very frustrating when you have a command or set of commands that you need to run over and over. Especially when you start using fairly complicated ones with hexadecimal memory addresses, bit masks, and other esoteric parameters. Sure, somebody on our firmware team could add these features to our shell, but who has time for that (when we could be blogging instead, right?)?

I have been bringing up some new hardware for the past few weeks and using this shell heavily for that task. After the EEs I'm working with and I lamented for about the 100th time the lack of at least a history feature, the solution finally came to me. It was like Obi-Wan Kenobi whispered to me, "Bryan, use the emacs." I turned off my targeting computer my gnome-terminal that was running telnet and moused over to emacs (it's always running).

"Bryan, what's wrong?" my EE partner worriedly inquired. I typed M-x shell and then telneted to the appropriate port. I typed a command. It worked. I hit M-p and the command I'd just used magically appeared at the prompt, ready for action a second time. A chorus of angels sang. I edited the parameters of the command before sending it, using all the familiar emacs shortcuts. The angels' song rose in pitch. My partner's mouth hung open. After typing a few different commands, multiple M-p's scrolled through all the past commands. A C-r began a search through the buffer history so I could quickly get to a past command I wanted, and macros and elisp were now at our disposal for scripting it. Our simple shell just got a whole lot more features.

There is really only one problem with this that I've discovered. Most of the commands we use echo any output to our serial console, but some echo back to the shell. Some of the output that goes back to the shell doesn't show up in emacs for some reason. If anyone has any tips on that one, please let me know.

Oh, and, uh, sorry for getting a little over dramatic there. I'll try to tone it down next time emacs causes me to weep with joy (dang, there I go again).

Sunday, April 1, 2007

Resolve Bazaar Merge Conflicts with Emacs

How to fix bizarre merge conflicts with emacs will be in a different chapter. Here you will just find tips for working with the Bazaar revision control system, also known as, bzr. This assumes you are fairly comfortable with the basics of bzr and emacs.

When you do a bzr merge to pull in changes from a different branch (try bzr pull first, it will tell you if you need to bzr merge instead), it's possible that conflicting edits have been made to the files you are versioning. In that case bzr will tell you about it, and drop three new files in your directory tree for each file with conflicts. They will be named, file.THIS, file.OTHER, and file.BASE. "Whoa! Scary! What do I do with all of these?" you might say to yourself. I'm here to answer that question, with a handy emacs tool called ediff. Open emacs and and type M-x ediff-merge-with-ancestor. It will ask for three files, which you should give in this order: file.THIS, file.OTHER, and file.BASE. It will split the screen so you see two buffers side-by-side and a third below them. Another little window, the ediff windows, will pop up as well. With the ediff window active you can hit some special keys to navigate through the differences in the files. Most importantly, n and p step through diffs, and v scrolls down a few lines, V scrolls up a few lines (and hit ? for more help). Your changes are on the left, changes incoming are on the right.

It's really easy to resolve the merge conflicts, just start stepping through the diffs by hitting n. Watch the bottom window (emacs window, more like what you might call a frame these days), you really only need to pay attention when it shows two alternative choices and the original. That's where a conflict occurred. Just hit a or b to choose which of the two changes you'd like to keep. If they aren't exactly right, you can edit the file right there in place in the bottom window.

When you have resolved all the conflicts this way, you hit q to quit the ediff session. Then you can save the bottom buffer right over top of the original file (c-x c-s, y). Go to your command-line and type bzr resolve file. Once you resolve all the conflicts like this you can bzr ci and you have successfully merged and resolved conflicts like a pro.

P.S. After figuring all that out, I found some good ediff-merge-with-ancestor tips out on the web (with svk, not bzr, but still helpful). Go figure.