Monday, March 26, 2007

Foxmarks: Must Have Firefox Extensions

Foxmarks was listed as the number one must-have Firefox extension today on LifeHack! Apparently, this was also on Digg, so we're pretty excited here at Foxmarks! :-D

Friday, March 23, 2007

Humor: Funny Signatures

Here are some funny signatures I've had over the years:
  • Hacking is to software engineering as climbing Mt. Everest is to building a Denny's there.

  • GNU's not UNIX. Emacs is most definitely not UNIX!

  • Perl: fork while fork

Thursday, March 22, 2007

Python: Returning Multiple Things of Different Types

If you are a strong believer in statically typed languages, you won't want to read this post!

Sometimes it makes sense for a function to return multiple things. In such cases, it's common to just return them in a tuple: "return (count, new_obj)".

Sometimes you might want to return objects of different types based on whether an operation succeeded or not. For instance, if the operation was successful, you might return "(True, obj)". If it failed, you might return "(False, reason)". Often, you can use exceptions to handle this situation.

Sometimes you might want to return objects of different types based on arguments to the function. For instance, did the caller ask for the data in this format or that format?

Sometimes you'll want all of these variations at the same time. In such cases, I have found that using a dict for your return value is a good solution. For instance, here is a piece of a docstring that I wrote yesterday:
    Return a dict (which I often call "response") with one or more of the
following as appropriate:

This is a bool to indicate success.

If unsuccessful, this is a Pylons response object that your
controller can return. It will contain an appropriate error
message for the user.

Upon success, this is the file handle returned by
``urllib2.urlopen``. Per urllib2, it has an ``info()`` method
containing things like headers, etc.

Upon success, if you set ``parse_xml_document=True``, this will
contain the parsed xml_document. I'll take care of parsing errors
with an appropriate pylons_response for you.
The calling code then looks like this:
        server_response = talk_to_server(parse_xml_document=True)
if not server_response['successful']:
return server_response['pylons_response']
etag = server_response['file_handle'].info().getheader('ETag')
xml_document = server_response['xml_document']
If you read it out loud, the code "reads" easily, and yet it has the flexibility to contain all the different things I need to return. If I ask for something that isn't there, I get an exception, which is life as usual for a Python programmer.

Thursday, March 15, 2007

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;)

In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3, Erlang, and the original Lisp machine. The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts.

Now, I'm sure that many of these ideas have already been envisioned within, LLVM, Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway.

Rather than wax philosophical, let me just dump out some ideas:
  • Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code." I bet it's written well enough to provide the basis for some fun hacking.

  • Run Erlang as a daemon in userland. Erlang has the sort of "ridiculous number of 9s reliability" that I'm looking for.

  • Step by step, move everything into Erlang ;)

  • Hence, almost everything is interpreted. This is also inspired by Java, .NET, and LLVM. Unlike Java and .NET, the interpreter uses high level P-codes, more like Python.

  • Because of this, hardware-based "protected-mode" isn't nearly so important. I'm still debating whether it's even necessary to have more than one context (i.e. hardware-based address space) in userland since the Erlang interpreter provides this on another level.

  • Processes are like Erlang "processes": they're dirt cheap, they don't share a common namespace, and they have really nice message passing semantics. After all, if we're going to be dealing with 100s of CPU cores in a few years, it makes sense to get away from the hard way of doing threads (mutexes in C) and embrace the easy way of doing "threads" (a la Erlang).

  • Erlang processes have no shared namespace, but they can easily pass data amongst themselves--not just streams of bytes, but full-on data structures. Imagine taking advantage of this between every "program" on your system.

  • Due to the nature of Erlang data, passing data between programs is copy on write.

  • Like a Palm, every "program" is running at all times. Unlike a Palm, things are running in an interpreter, so you don't need cooperative multitasking. Nor will a single program bring down the whole system. Rather, the interpreter itself can "context switch" after every few instructions. Since the "processes" are super light-weight, context switching is very fast and happens a lot more frequently.

  • Since every program is running at all times, that means every program is implicitly started when booting. It's more like turning on a Palm pilot than booting a computer.

  • Throw away the filesystem. Every "program" has every "document" implicitly loaded at all times. The documents don't have to be serialized to a stream of bytes. They're always meaningfully structured like Lisp data.

  • Don't throw out virtual memory! If everything is in memory, you're going to need really smart virtual memory.

  • Unlike object-oriented systems today that have many objects and few threads, unify the concepts of objects, threads, and modules into something I call a "cell".

  • That means every object has its own thread.

  • "Programs" are constructed from a collection of such objects.

  • Since every object is like a module, it can be reloaded independently of everything else. This has been done in both Erlang and in the Lisp machines.

  • Since every program is always running and is composed of objects that can be independently reloaded, the objects behave more like biological "cells". Sometimes you get new cells. Sometimes old ones die. However, in general, things are pretty "static". Failures are treated more like a cancer than a stroke.

  • These "cells" know how to do continuations that can be journaled to disk. That means that if the system needs to restart, the cells restart at their last "checkpoint".

  • Naturally, the message passing in Erlang works seamlessly between machines. Hence, the "N" in "ERNOS".

  • Programs that create "documents" for view by other people on other systems do so in an applet-like manner. That is, the code "goes with" the data (a la object oriented programming). The receiver doesn't need to have the same program installed. However, I will assume that non-ERNOS users can install Erlang in the same way most people have a JVM and a Flash player installed. Of course, the normal sandboxing applies.

Wednesday, March 14, 2007

Blogger: Pragmatic Programmers and Erlang

Dave Thomas announced on ruby-talk that the Pragmatic Programmers are about to publish a book on Erlang.

Awesome. So according to Tim O'Reilly, my strange fascination with Erlang isn't just my being crazy like normal ;)

Saturday, March 10, 2007

Second Life: My Video Card Stopped Sucking!

I upgraded my video card driver once again using the directions here (using the most modern driver), and Second Life stopped sucking! That makes me happy.

I was so bummed about my Second Life experience, I had contemplated getting a Mac. Unfortunately, the Macbook (non-pro) doesn't work with Second Life, and the Macbook Pro is like a grand more--i.e. way more than my wife would ever let me spend.

Anyway, I'm happy.

(Dell Inspiron 6400, Ubuntu 6.10, ATI Mobility Radeon X1300)

Friday, March 09, 2007

Erlang: The Movie

I'm sure everyone who codes in Erlang has already seen this, but it was new to me. It's a dead-serious, educational video on Erlang. It's very well done and quite interesting, but I found it totally hilarious in a Monty Python sort of way:

Erlang: The Movie

Monday, March 05, 2007

Linux: Gamma Correction

I have a Dell Inspiron 6400 running Ubuntu 6.10. I know there are two different displays for this laptop. At least for me, running "xgamma -gamma 0.7" brings great joy :) To make the change permanent, I added "Gamma 0.7" to the "Monitor" section of "/etc/X11/xorg.conf".

Finally, I can enjoy a nice blue background without becoming subconsciously irritated.