Sam Shapiro — Saving Ghandiah

April 30, 2010

I just learned of the passing, last summer, of Sam Shapiro, half of the dynamic duo behind Force Monkeys. His family has been erecting memorials: samshapiro.org and Saving Ghandiah (Ghandaiah being his best-known handle). Here is some of his writing:

WITHOUT PERSONAL EXPRESSION, WE BECOME STATISTICS. WE ARE NO LONGER PEOPLE, BUT INSTEAD MACHINES, BODIES MOVING ABOUT AND FUNCTIONING ONLY TO ASSURE OUR BASIC SURVIVAL.

WITHOUT PERSONAL EXPRESSION, WE LOSE PART OF OUR HUMANITY, AND WE LOSE PART OF WHAT MAKES US SENTIENT.

FOR THIS REASON, WITHOUT PERSONAL EXPRESSION, NOTHING ELSE IS POSSIBLE. AS AUTOMATONS WE WOULD LOSE OUR HAPPINESS. AS AUTOMATONS WE WOULD SHED ALL VARIETY AND BLUR TO A SINGLE SHADE OF MONOTONOUS GRAY.

PEOPLE CHERISH THEIR DIFFERENCES, AND YET, SIMOLTANEOUSLY [SIC], TAKE ADVANTAGE OF THEM. WE OFTEN DISCARD THE OPINIONS OF OTHERS AS INSIGNIFICANT MERELY BECAUSE THEY ARE NOT OUR OWN.

IF PEOPLE REALIZED THE IMPORTANCE OF SELF EXPRESSION, THEN PERHAPS CONFLICT WOULD NOT BE SO COMMON.

A lot of his art is really stunning. Here is one that I’m fond of. Look at the eyes in particular.

http://travelogue.betacantrips.com/wp-content/uploads/2010/04/wpid-dsc00011-copy1.jpg

Comments Off

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

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:

emacs-got-git

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

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

Like, Python

April 24, 2010

Cute nerd joke: Like, Python.

#!usr/bin/python
# My first Like, Python script!

yo just print like "hello world" bro
Comments Off

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.

Thanks!]

Comments Off