Here’s one I found once a long time ago and keep thinking of randomly. jynx on Perlmonks explains what makes and breaks an Obfuscated Code entry. Does anyone still write Perl? Does anyone still write (intentionally) obfuscated Perl? Still, I really like the way he offers examples and counter-examples of each principle.

2) pack/unpack is not obfuscation

The reason i list the counter-example is because it is not unpacking anything like what you think at first glance. While the obfu itself does need some work, that is an acceptable use of unpack. On the other hand, looking at the example we see a fairly common use of unpack: get the string and unpack it, oh look the string is japh. While a packed string is line noise, it’s easy to see past it and note what the code is doing if it’s a simple obfu.

Since I have a tag dedicated to version control, I thought to use it to link to iolaus, a git porcelain that emulates darcs. It’s written by the same guy who wrote darcs, possibly as a one-off project. Perhaps it was meant to solve the darcs "exponential merge time" problem. The same problem has been drastically improved in Darcs 2, and iolaus hasn’t been updated since March 2010, so it probably isn’t worth worrying a lot about.

I realized that the semantics of git are actually not nearly so far from those of darcs as I had previously thought. In particular, if we view each commit as describing a patch in its "primitive context" (to use darcs-speak), then there is basically a one-to-one mapping from darcs’ semantics to a git repository. The catch is that it must be a git repository with multiple heads!

Fortunately, this is not such a foreign concept to git. In fact, git has a whole framework to help users manage repositories with multiple heads (see, e.g. checkout and branch). So it’s not so very foreign at all. There are just a couple of major differences how git works. First, in git your working directory will only reflect one of the heads, while in darcs (or iolaus) the working directory reflects the union of all changes in the repository.

Just to make things even more interesting, it’s written in Go.

I spent a few hours today dicking with my N900 and thought I’d write up some of the things I dealt with.

For a long time I’ve been using Dropbear SSH client/server on my phone, due to an alleged less-memory-usage. (When your phone starts swapping, it sucks big time.) Dropbear even supports serving SCP, but does not support SFTP. This prevents you from using any relatively-nice "file transfer over SSH" GUI, such as Nautilus’s "ssh" support or gFTP. (I think Konqueror’s fish mechanism would still work, but that is of limited utility to me right now.) It may be possible to use the sftp from OpenSSH with dropbear, but since the Dropbear packages conflict with the OpenSSH packages in the Maemo repository, that’s not especially on an N900. In fact, dropbear-scp conflicts with openssh-common (both provide /usr/bin/scp, which I think is silly, but there you are).

Of course, if you insist on using Dropbear, you can use Bluetooth to copy files over Obexftp (which Nautilus supports nicely). But since this requires Bluetooth hardware to be powered on both the laptop and the phone, I decided to replace Dropbear with OpenSSH.

Installing OpenSSH server on your N900 forces you to change your root password (the default is "rootme"), whether you’ve already changed it or not. Kind of annoying. The user account by default "doesn’t have a password", which I think means all password access is disabled. Folk wisdom suggests that giving a password to the user account "could" cause problems, but I think this is based on an (incorrect) belief that the default password is "blank" (in fact, it’s invalid, meaning there is no phone software that relies on using a password to switch to the user account, so there should be no problem with granting a password). Nevertheless I decided to just drop in a key using authorized_keys. But if you don’t set a password, OpenSSH won’t let you log in (even using publickey access); the log messages will tell you that your account is "locked". The reason is that OpenSSH looks at /etc/passwd to decide whether to let you in using any access methods at all; since the password hash is "!", it locks you out.

This page shows how to fix the "locked account" status.

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.

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.

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.

Thanks!]

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

#!/bin/sh
cp_p()
{
   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.

—lamby

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
'title'
>>> 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.

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.

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.