Cyclopedia Square

I just learned how to merge incrementally with Mercurial. I wasn't really even aware of what that means until I learned about it. Most people use a graphical diff/merge tool with Mercurial such as kdiff3 , and for a good reason. Resolving merge conflicts any other way is much more difficult. Normally when you run hg merge it merges all the files right then, and pops up your graphical merge tool right when conflicts occur. You can leave the gui window up and sort of ignore it for a while, but then you wonder what happens if your computer loses power or you need to reboot for some reason. Will your working copy be left in some weird state? What if you have already spent a lot of time resolving tricky conflicts on a previous file, you'd hate to lose that work. Or what if you know one particular file is going to be onerous and you'd like to resolve conflicts there first? Wouldn't it be nice if Mercurial could just present you a list of files with conflicts and let...

I have written A UNIX/Linux environment manager that allows on-the-fly configuration of your shell environment. It's called, albion . Using albion, environment variables, aliases, functions, and so forth can be changed without requiring you to do the tedious log-out-and-log-back-in-again routine. Simply type 'albion load ' and your shell environment will be reconfigured according to the specification in your environment file. It should work with any POSIXy shell (bash, ksh, zsh, etc.) Albion is similar to the Environment Modules Project , however, environment configuration files (configs) are written in standard shell language, not tcl. Another improvement over modules is that when unloaded, the effect of the configs is correctly undone, even if the configs have changed or been deleted after loading. The main albion tool is written in Python, with some supporting pieces written in POSIX shell code. albion is currently alpha quality. The core functionality seems to be ...

Ubuntu, in all its helpfulness, has a feature that tries to guess what you mean when you type commands at the bash prompt. If you type a command that's found, it runs it, of course. If you type a command that it can't find, it takes a moment to search available packages for install and suggest what you might do to make that command available. It sometimes looks like this: $ foo No command 'foo' found, did you mean: Command 'xoo' from package 'xoo' (universe) Command 'fop' from package 'fop' (universe) Command 'fox' from package 'objcryst-fox' (universe) Command 'zoo' from package 'zoo' (universe) Command 'goo' from package 'goo' (universe) foo: command not found It's great when you have a new system and you haven't yet installed everything you need. Type emacs before emacs has been installed, and it will helpfully tell you the exact command to use to install it. After a...

A while ago I decided to start maintaining my .emacs file under revision control. I picked git because it seemed like the cool thing to do. I put it on gitorious so that I could easily sync it with my home and work machines, and it was public in the off chance that it might help out some other emacs user. Today I converted it from git to mercurial, because for some reason hg incoming is more intuitive and easier for me to remember than git fetch && git log ..origin/master Maybe I'm weird that way. Anyway, the new repo is on bitbucket . That is all.

My Mac let's me use emacs keyboard shortcuts everywhere. I'm really sad that I don't get that in Linux. How the universe ever got into this state is beyond my comprehension. Mail.App has gotten me hooked on emacs keybindings when typing emails especially. The solution in Linux, it turns out, is to just use emacs. I already have It's All Text for Firefox, with emacsclient as the editor. I just found External Editor for Thunderbird, with emacsclient as the editor and tbemail-mode for extra goodness. I think that'll do.

My team at work recently switched from Subversion to Mercurial for revision control. That’s no small feat for a hardware design team (see: Averse to Change ). It helps a little that we are mainly FPGA people (a lot “softer” than an ASIC), but there are still definitely hardware attitudes about change. Our software partners made the change a while ago, so they already had some process and infrastructure set up that made it easier for us, plus they could point out from real experience that it was an easy transition with many benefits. That helped a lot. I took the lead on making the change for our team (is it true everywhere that on a digital design team, the verification engineers are the de-facto “tool guys” as well?). I studied up on how exactly mercurial works. I mean, I had the basic idea down since I’ve been toying with the fancy new revision control tools for a while now , but I didn’t really reach enlightenment until a few months ...

I ls -ed some files today and noticed a few listed with blue backgrounds and white text. I use the --color option to ls because it's pretty, and because the colors provide information that's not always blindingly obvious from regular ls output. Case in point, what did this blue background with white text mean? It turns out that, at least for Ubuntu 9.10 an 10.04 (the two I tried), you can see a list of the colors that ls uses for various things by typing: dircolors --print-database Now, I had a hunch that these files were hardlinks, and sure enough, I saw this line: HARDLINK 44;37 # regular file with more than one link And looked up a few lines to see that, yes, 44 is blue and 37 is white. Cool. Just to be extra sure I passed the file names to the stat command and saw the, links: 2 for those files.