Pensieri di un lunatico minore

7 September 2009 Programming

Emacs macro trick

I don’t know when this was added, but as someone who has used Emacs pretty constantly since 1985, I can’t believe I never knew this. Most people know you can record a simple macro with C-x ( to start and C-x ) to end. You can then replay it back with C-x e. Nothing new there, right? Well, obviously you can combine the C-u prefix, which will repeat it. So C-u 10 C-x e will execute the macro 10 times. If you say C-u 0 before, then it’ll run until it has an error (usually the end of the file, or something).

But here’s the trick. If you type C-u C-x e, it will run the macro once, and then allow you simply to press e to keep running it. This is very handy when you’re trying to go through a list in the middle of a document.

Funny how I never noticed.

Comments Off

4 December 2008 Programming

The Ring of Perl

I see a post entitled Perl 5 Programmers Are Dying, and all I can think of is The Ring. Odd, eh?

2 thoughts

27 September 2008 Programming

Obama campaign needs talented geeks

If you’ve got talent and time on your hands:

The Obama campaign’s grassroots movement is supported by the best data management in politics.

The Obama Data team is looking for data-savvy supporters to join our team as Data Fellows for the last weeks of the campaign. The position is full time through November 4th.

Data Fellows will be required to attend an online training and will be expected to volunteer full-time in the state of their placement for three weeks. Data Fellows will also:

Apple online.

Comments Off

20 July 2008 Programming

Speed freaks

Other’s muse on the absurdity of those obsessed with speed. Like a meth addict, the use any possible rationale to justify their unhealthy obsession. My favorite is:

“What do you mean my algorithm runs at O(n!)? It’s twice as fast as yours with this small test set”

The number of times I’ve seen someone rant about how fast their new algorithm is—when running on an irrationally small sample—is uncountable. As I’ve said a million times:

  1. Make it work
  2. Make it right
  3. Make it fast enough
  1. Profit!

    Seriously. Don’t put things in the wrong order, or you’ll never get anywhere.

    1 thought

6 June 2008 Programming

More Mosquito Lisp

Scott Dunlop writes about the transition of his work from Mosquito Lisp (MOSVM) to Wasp Lisp. One of the thing that I wanted to point out about my interest, though, was that it wasn’t strictly about it being a Lisp dialect. It’s more what that brings with it: flexibility. It’s a tight, very small, and reasonable performing implementation that’s very flexible. It also comes with, to steal a phrase from Python, “batteries included”. This makes developing neat applications nearly trivial.

Comments Off

4 June 2008 Programming

Close, but note quite close enough

So today I was trying to debug some code, and for some reason, I couldn’t see what was wrong for a few seconds. Then, I realized that I had been typing lambada instead of lambda. Time to stop coding for the day.

Comments Off

2 June 2008 Programming

Uninformed commentary

One of the great things about the intertubes is that it allows people of all capabilities and skill sets to shoot off their mouth and make fools of themselves. Recently, Sho Fukamachi demonstrated the truly epic capability to not only miss the entire point, but demonstrate a nearly bottomless lack of knowledge of the area of virtual machine technology and what actually represents “state of the art”. Oddly, it reminds me of me when I was 20. Fortunately, Patrick Collins straightens it out. Oh, and I’m quite aware of object databases in the public eye that are nearly 1PB compressed. There are some in the intel community that even larger and more complicated.

It’s amazing how some communities think that they’ve actually had an original idea. There are almost no original ideas left. The only reason anyone thinks their “idea” is original is that they’re simply oblivious to the decades of work of others.

2 thoughts

1 June 2008 Programming

Sacred cows

It’s amusing as all hell to watch some people blow up about the MagLev Ruby implementation. Personally, while I find Ruby interesting, the performance is embarrassingly bad for a lot of problem domains. That doesn’t mean it’s not useful, it just means it’s not as useful as it could be. I’d like to take a couple comments that Charles Nutter made and just “observe”:

First off, they demonstrated its distributed object database automatically synchronizing globally-reachable state across multiple VMs. It’s an amazing new idea that the world has never really seen…

except that it isn’t. This is based on existing OODB technology that Gemstone and others have been promoting for better than a decade. It’s cool stuff, no doubt, but it’s been available in Gemstone’s Smalltalk product and in their Java product for years, and hasn’t seen widespread adoption. Maybe it’s on the rise, I really don’t know. It’s certainly cool, but it’s certainly not new.

There are only a tiny handful of companies in the world who can show production object environments of that scale. Gemstone and Objectivity being two of the most successful. Both are rooted in the Smalltalk world originally, though offer other products to most of their customers. What I find troubling is the dismissive nature that Mr. Nutter has about the problem domain. The fact that most people worship at the relational temple doesn’t mean that it’s actually a good idea in many cases. Some of the most complex databases in the world are object databases. There’s a reason a huge percentage of Objectivity’s money comes from the intelligence community. Data fusion is everything.

Except that these are results reported entirely in a vacuum. Whether this is fib following the “rules” of Ruby is entirely an open question. Whether this is method dispatch adhering to Ruby’s call logic is entirely an open question. Whether this is a while loop using all method calls for its condition and increment steps is an open quesetion. Because the Maglev guys haven’t started running Ruby tests yet. Is it Ruby?

Well, once someone actually defines what Ruby is we can have that discussion. One of the most frustrating aspects of Ruby is that there is no actual language definition. There is only a language implementation, several at that, and if I recall correctly all have had to reverse “engineer” the language from the implementation. This makes discussing “is it Ruby” a laughable prospect, and Mr. Nutter should know that. Let’s examine “some words of his from just a few weeks back”:

Compatibility is hard. I’m not talking a little hard, I’m talking monumentally hard. Ruby is a very flexible, complicated language to implement, and it ships with a number of very flexible, complicated core class implementations. Very little exists in the way of specifications and test kits, so what we’ve done with JRuby we’ve done by stitching together every suite we could find. And after all this time, we still have known bugs and weekly reports of minor incompatibilities. I don’t think an alternative implementation can ever truly become “compatible” as much as “more compatible”. We’re certainly the most compatible alternative impl, and even now we’ve got our hands full fixing bugs. Then there’s Ruby 1.9 support, coming up probably in JRuby 1.2ish. Another adventure.

So before the stones are cast, perhaps the house should be repaired?

Then there’s Maglev. Like the other impls, I’m excited that there’s a new possibility for Ruby to succeed. A high performance, “scalable” Ruby implementation is certainly what this community needs. But unlike most of the other implementations, it seems like Maglev is pushing performance numbers without compatibility metrics; marketing before reality. Am I far off here?

Here’s the thing. Maglev is a new language on top of an existing VM. One that has over a decade of hardcore production use, something that even Java can’t really claim. There’s a wide gulf between putting a new syntax on top of an existing VM architecture and building a new VM. VMs are intensely hard, and only a few people in the world are truly good at them. Dynamic VMs all derive from Smalltalk, and even Java is having to glue on all sorts of silly doo-dads to try and pretend it can support it without huge cost. Ruby is very much Smalltalk in different clothing, and therefore I would expect Ruby to run at near Smalltalk speeds once you clean up some pieces. I know the great wizard had a Python implementation running on a Smalltalk VM, alas it never got released.

The truth is that not all of these optimizations are kosher right now. Removing the ability to override Fixnum#+ certainly makes it easier to optimize addition, but it’s not in the spirit of Ruby. Removing frames may be legal in some cases (like this one) but it’s not legal in all cases. And of course I’ve blogged about how Thread#kill and Thread#raise are broken, but we have to support them anyway. On and on we can go through lots of optimizations you might make in the first 100 days of your implementation, only to back out later when you realize you’re actually breaking features people depend on.

Features, or design errors? Because if it’s the later, then breaking them is the best thing that can be done. The refusal to fix them in the past is simply a weakness. The totem of backward compatibility is what gave us Windows Vista.

6 thoughts

16 May 2008 Programming

Emacs color themes

In my continuing adventures getting back to using Emacs, I was working on tweaking the color theme that I use. While it’s based on someone else’s originally, I’ve made quite a few minor changes. Somewhere along the line, I messed it up and started getting all sorts of strange errors that made no sense. They couldn’t possibly be wrong.

Here’s the old one:

(defun color-theme-charcoal-personal ()
  (interactive)
  (color-theme-install
   '(color-theme-charcoal-gray-personal
     ((background-color . "Grey15")
     ...

And here it is, fixed:

(defun color-theme-charcoal-personal ()
  (interactive)
  (color-theme-install
   '(color-theme-charcoal-personal
     ((background-color . "Grey15")
     ...

Do you see the difference? No? Look carefully.

It seems that if you name the defun differently than the first element of the first list passed to color-theme-install, it goes wonky. Unfortunately, the debugger wasn’t much help, and it was simply by stepping through a comparison with the original to see if somehow I’d missed something that I found the place where I’d screwed up. Something annoyingly tiny, and a mistake that should have generated a more useful error.

If you want the Elisp code, you can find it here: color-theme-charcoal-personal.el

1 thought

12 May 2008 Programming

Fun with Pymacs

Pymacs was developed by François Pinard, and it allows two-way communication between Emacs and Python. Very cool, except… it breaks my copy of Aquamacs, causing all sorts of things to spit out this lovely error:

Variable binding depth exceeds max-specpdl-size

What, you ask, is causing that? Well, it seems to be tied up with the advice framework (e.g., defadvice) and creating more recursion than Emacs will allow. Specifically, it trips at 600 levels. Very annoying.

Comments Off

6 May 2008 Programming

The debugger is your friend; even in Java

I am continually fascinated by how little many people use a debugger1 when they’re trying to understand their code. Today, I watched an otherwise very intelligent person stare at some Java code for 15-20 minutes trying, apparently, to mind-meld with the JVM and understand what went wrong and why he was getting a glorious NullPointerException, something I still find gloriously amusing.

“Why don’t you set a breakpoint and look at what’s going on right there?” I asked. You would think I was talking Aramaic. Even I, arch-hater of Java—and Eclipse—was able to divine the way to do this task and within 15 seconds we had a solution.

Learn to use the debugger, even if you’re working in a dead language like Java. It might not be a live object universe like Smalltalk, but it is 100x better than simply guessing.

1 If you’re cursed with either C or C++, invest your hard-earned money in TotalView if you have to do anything with multi-threaded code. It is unparalleled by any other debugger.

1 thought

6 May 2008 Programming

Writing code is easy; designing software is hard

In reading an article about SciPy, the author has this gem:

The bottleneck in writing code isn’t in the writing of the code, it’s in understanding and conceptualising what needs to be done.

I mean gem quite literally. This, in the end, is the core difficulty that people seem not to grasp about writing good software. Writing lots of code is trivial; any monkey, or IDE can do it. The difficulty comes in the concept and more importantly the domain knowledge around the problem. For me, that’s 90% of the problem.

This is why I say languages don’t matter that much. Knowledge is language-insensitive.

Comments Off

9 March 2008 Programming

The ad

When I was in TX, I started seeing Senator Clinton’s infamous homage to LBJ: the telephone ad. I almost fell out of my chain, though, as she hasn’t got an ounce of applicable experience to make that decision, which puts her exactly where Senator Obama and Senator McCain are. None have ever been the executive. Dick Morris, never a retiring wall-flower, has some advice for the campaign:

The next time Hillary uses the recycled red phone ad, counter with one of your own. When the phone rings in the middle of the night, have a woman’s voice, with a flat Midwestern accent, answer it and say, “Hold on” into the receiver. Then she should shout, “Bill! It’s for you!”

Because with Hillary’s complete lack of any meaningful experience in foreign affairs, and her lack of the “testing” that she boldly claims, she’ll be yelling for Bill.

I don’t think he should run that ad, as some might see it as misogynistic, even though it’s not. But at the end of the day, the only test she’s had, on the Iraq war, she freaked and picked the wrong answer.

1 thought

5 February 2008 Programming

Amazon Simple Queue Service

Amazon just released a new API and pricing model for their Simple Queue Service. There are two changes that I find especially interesting:

6 December 2007 Programming

Mercurial tips

So, I’ve switched to using Mercurial for all my version control needs. As a distributed design, it makes it easy to work on a detached machine—say on an airplane—and not lose the functionality of a full version control system. This is in stark contrast to either CVS or even Subversion, which was my previous choice. All is not perfect, of course, but I’ve learned a few tricks that weren’t obvious, at least not to me.

First, Mercurial doesn’t track directories, at least not as such. This is a big change from Subversion. This means that some of my scripts, which set up a uniform directory layout for projects and build that as the skeleton in the repository, no longer work. I fixed this relatively easily by simply putting a file names 00README in the directory which contains a one line description of what the directory is for. Overkill, but it feeds my habits.

Second, I found it a bit annoying when I needed to “push changes”: that I had to specify the location every time. Turns out, you don’t have to, as you can create aliases and you can also create defaults. If, for example, you put the following in the .../.hg/hgrc file in the repository, you just use the default all the time:

[paths]
default-push = <url></url>

Now you can just use hg push to publish your changes, and not have to do anything else. Much nicer.

Lastly, because it’s so easy to create new changesets, and takes almost zero time, I find myself checking things in much more frequently. This means that the changeset is smaller, and therefore easier to find issues should they arise.

Comments Off