Emacs Got Git

April 29, 2010

I saw Emacs Got Git, sometimes called "Egg", listed on the list of git-related software on the git wiki (although now taken down) and of course on the EmacsWiki. I decided I’d give it a whirl. The most recent version I could find was the one listed on the EmacsWiki, the version from bplayer, which seems to still be actively developed. The incumbent here is either magit, which is by far the best user interface I’ve ever seen for any version control anywhere, or VC mode, which was written once to support SCCS and has largely survived unchanged since then.

A brief digression about magit and vc-mode. Magit is a little bit of a challenge to pick up: you actually have to read the manual. But the short version is: M-x magit-status to open a view of your repository, and then TAB things open and closed. You can press "s" to stage files, hunks, or even "highlight" lines using the region and stage only those. "u" to unstage; "c" to start a commit, and then C-c C-c to make the commit. You can create a commit that amends the previous commit by pressing C-c C-a in the log message buffer. It probably offends some that there are already conventions here for VC system integration, notably vc-mode. But vc-mode takes a file-based view of version control, has no support for staging hunks, and in general just doesn’t feel good to use. magit is much better — so much better that it is easily worth the break in convention.

So I thought I’d check out Emacs Got Git, to see if it was any better than magit. This isn’t a detailed analysis — actually I’ve probably spent longer writing this post than I did looking at Egg.

I find a screenshot is worth a thousand words. On my ~/etc repository, magit looks like this:


Magit highlights all the important details: which files are changed? Which are untracked? What commits exist locally that don’t exist on the remote?

On the same repo, Egg looks like this:


This is what we call the "angry fruit salad" school of UI design. Also, it doesn’t have a section for "unpushed" commits.

I’m going to be sticking with magit for the forseeable future.

Comments Off on Emacs Got Git

Porting a C# app to Java

April 24, 2010

Seen on LWN, an article about porting an application from C# to Java. Punchline: automated translation. Quote:

The inspiration for this was an article about Boeing and automatic conversion. Well we thought "if Boeing can do it so can we". Sounds stupid? Well it is. Luckily for us we did not think that at the time.

Comments Off on Porting a C# app to Java

Emacs Lisp Best Practices?

April 24, 2010

I’ve been spending a bit of time steeping myself in EmacsLisp these last few days. I’ve been looking for information on elisp "best practices" — specifically, is it OK to rely on (require 'cl)?

Here’s one page wondering the same thing. There’s always a ton of interesting stuff whenever you go poking at emacs packages; most surprising to me this time around was ELPA, the Emacs Lisp Package Archive. Perl has CPAN, Python has PyPI, Ruby has Rubygems.

I also found the blog emacs-fu pretty interesting looking — approximately one post a week, I think. Lots of stuff I wish I could absorb better.

Emacs Coding Conventions from the Elisp manual is also pretty helpful. To this point (about CL), it says:

Please don’t require the cl package of Common Lisp extensions at run time. Use of this package is optional, and it is not part of the standard Emacs namespace. If your package loads cl at run time, that could cause name clashes for users who don’t use that package.

However, there is no problem with using the cl package at compile time, with (eval-when-compile (require 'cl)). That’s sufficient for using the macros in the cl package, because the compiler expands them before generating the byte-code.

For me, this is enough, because I want to use dolist. But there are programmers out there like David O’Toole, who writes in his interactive guide to the GNU Emacs CL package:

Despite what people say about still being able to use the macros while complying with the policy, in my opinion the policy is still a discouragement. You have to memorize which of its features you must abstain from using (and therefore lose the benefit of those features) if you are to have any hope of someday contributing Lisp code to GNU Emacs.

I think the GNU Emacs maintainers are hesitant to allow use of a package, like cl, which isn’t "namespaced". I bet if all the functions in cl were prefixed with cl-, nobody would mind…

[Update, 2010-Apr-27: From an email on the magit email list:

There’s also the small matter that many of the function implementations in cl, striving for the full generality of Common Lisp (much of which is completely useless in Emacs), turn out to be horrible.

E.g., for a fun time, dig down through

(find-if pred list :from-end t),

and look at what it ACTUALLY does when you finish macroexpanding everything. It tests every element of the list against the predicate, not just the rightmost ones stopping when it finds the first match. Once it determines the rightmost match, it then retains NOT the element itself, but its ordinal position N, which then gets used in (elt list N), meaning ANOTHER listwalk, just to get the element back in order to return it. Nor is the byte-compiler anywhere near smart enough to optimize this away (I’m not sure any compiler would be…)

I’ll grant cl has some useful macros in it, but it comes bundled with a lot of crap and you need to be really careful about what you use. For many things, you’re better off rolling your own functionality using the standard routines available (e.g., while, mapcar, and reverse are all written directly in C).

And you most definitely do NOT want to be foisting the crap on everybody else, hence the need to keep it out of the runtime.


Comments Off on Emacs Lisp Best Practices?

Damn right you can.

March 3, 2010

Seen on Planet Debian: ‘Can you get cp to give a progress bar like wget?’ The solution starts:

   strace -q -ewrite cp -- "${1}" "${2}" 2>&1 \

The author notes in the comments:

If you feel the need to point out an alternative solution, then you have missed the entire point by a wide margin.


Comments Off on Damn right you can.


February 27, 2010

At PyCon, I saw a lightning talk about scrape.py, a lightweight Python library for parsing webpages/interacting with them programmatically. For example, finding page elements:

>>> from scrape import *
>>> s.go('http://zesty.ca/')
<Region 0:17780>
>>> d = s.doc
>>> t = d.first('title')
>>> t
<Region 247:258 title>
>>> t.tagname
>>> t.text
u'Ka-Ping Yee'

The presentation I saw focused on the use case of testing your website. This is definitely a pain point for me personally: I currently either grep the HTML with regexes or I parse the whole thing using ElementTree and use XPath. But there’s still a couple of problems: 1. JS isn’t usually testable this way; 2. you often have to construct your HTML with an eye towards testability. For example, to test pagination, you might need to add a class or id specifying that this is the pagination section and that these pages link to pagination things.

Comments Off on scrape.py

Openhatch, the open source involvement engine

February 27, 2010

One of the neat things I saw at PyCon was a project called OpenHatch, which (among other features) indexes bugs and makes them easy to find according to your skillset and experience level. For example, lots of projects tag bugs as "easy" or "beginner" to promote newbie involvement and ramp-up; openhatch makes it easy to get involved with a project you can contribute to.

I think there’s still some work to be done — bugs about "you need a better logo" or "help, our docs are crap" don’t quite fit into this workflow. Still, good effort.

Comments Off on Openhatch, the open source involvement engine


February 17, 2010

Did you know (via the Debian NEW and BYHAND package list) that there’s a new kid on the IM software block? Behold: instantbird, based on the XUL framework and the pidgin libpurple codebase.

Instantbird is a multi-protocol Instant Messaging client. Using it, you can connect to all your different IM accounts.

It uses the Mozilla rendering engine to display IMs, and the Pidgin libpurple to connect to the different networks.

Comments Off on instantbird

How To Safely Store a Password

February 16, 2010

Thanks Adam — how to safely store a password.

Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt. Use bcrypt.

Good to know!

Comments Off on How To Safely Store a Password

Nokia, Intel merge Maemo, Moblin into Meego

February 15, 2010

Some coverage of the recent announcement: Nokia, Intel merge Maemo, Moblin into Meego on Slashdot, Moblin and Maemo to merge on LWN, Maemo + Moblin = MeeGo = Failure on Planet Debian. Some quotes:

A stupid name is a prerequisite for being a successful FOSS product. Nokia and Intel have clearly done their homework.

Also indicating huge potential, MeeGo has already ignited a flamewar between RPM and DEB supporters. Welcome to the community!

—EvilTNUser (here)


Today, Nokia and Intel announced the merge of Maemo and Moblin into the MeeGo project. This is sad, because it will end the era of the Debian-based mobile operating system Maemo and replace it with a system using RPM and probably some other evil stuff as well. In fact, dpkg & apt-get where two of my main reasons to buy the N900.

And another question is why yet another name. Moblin was already a well-known name and they shouldn’t have changed the name just because they switch the servers and add some Nokia developers.

Furthermore, does this all mean that there will be no Maemo 6? What will happen to the Maemo users on the N900, will it be possible for them to use MeeGo?

I recently bought an N900 (very recently — like, using it four three or four days now. Review forthcoming) and I have to admit to a few moments of shock and terror. But having thought things over, I’m giving in to "cautious optimism". Here’s my take on it:

  1. Like Julian Klode, my getting an N900 was prompted by my extremely positive experience on the Nokia N810. And it’s true that part of that experience was the discovery you can apt-get pretty much anything in the Debian repository. But the mechanism whereby this occurs is a little subtle: although apt-get is the application-installation mechanism for Maemo apps, the Maemo repositories aren’t really compatible with Debian. You can’t just open a terminal and sudo apt-get install emacs. Cross-compiling Debian packages is possible but (in my experience) a really bad idea; I broke APT on my N810 this way.

    The preferred mechanism for getting access to the Debian repository is a package, installable by default, called easy-deb-chroot. As you might guess, what this does is to set up a Debian chroot, wherein you have free range of whatever you want to do. In other words — the mechanism by which applications are installed by default on the device is completely independent of having access to the Debian universe. This is important: it means they can switch to RPM for installing packages, and still give us our easy-deb-chroot, which is what we really want anyhow.

  1. I’m surprised that they chose a new name — I think both Maemo and Moblin have great brand recognition in the community.

Nokia is the only hardware company in the mobile space that I think really "gets it" (some examples occur to me). Intel has been making strides towards getting it. And best of all, there are no telecoms involved in MeeGo yet. For these reasons, I’m going to take a wait-and-see approach. After all: there’s lots of work ahead of us if we’re going to build a better mobile stack than Google and Apple.

Comments Off on Nokia, Intel merge Maemo, Moblin into Meego

iPad is a “Huge Step Backward”

February 7, 2010

I was browsing this thread on Slashdot and came across a really interesting meme:

I bought an iPhone this year. This is one asset that is so important that I just want it to WORK. I don’t want to worry about viruses, or ongoing maintenance. This is my ONLY TELEPHONE LINE, and so I finally do approve of somebody keeping it locked down and pristine.


The lockdown here is on two devices. You want a laptop or desktop you can do whatever you want with? There’s the macbook, imac and mac pro for that. Want an expandable handheld appliance with a limited (albeit ever-expanding) functionality that’ll have no hidden surprises? There’s your iPad and iPhone.

You may as well criticise arcade machine makers for vetting all the roms you can put in their hardware. Or any of the console makers for vetting what’s available for theirs. Or that kindle can’t do anything but display books. Experience has shown them all, time and time again that as soon as you open up a platform to anyone and everyone, quality and reliability take a hit, not to mention susceptibility to attack. It’s a specific product for a specific market and like the iPhone, will be hated by geeks everywhere, but loved by everyone else who want something that just works. Apple will likely do little to stop people jailbreaking these things, they’ll just make it difficult enough that only determined people do it.

CrazyBusError (emphasis mine)

First, the FSF needs to convince us average users need to have control. Why should average users have control over their computer? Isn’t this what got us the virus nightmare in Windows?


The idea that most people don’t want control over their computers, and that having them be locked down offers tangible benefits, is new to me. In particular, a locked down device obviates the need to perform "good houskeeping" sorts of system maintenance. Some commentators respond that you can have a good design that eliminates housekeeping without control, but by definition if a user has the potential to do whatever they want with a device, it’s just a matter of social engineering to turn their computer into a spambot.

Comments Off on iPad is a “Huge Step Backward”