Side note: You need Python 2.4 or above to use generators, you’ll probably have this anyway, but it might pay to check before wondering why this stuff doesn’t work.

A Quick Introduction

At it’s heart a generator is a function which can return a value several times within it’s body. Each time the function is called it resumes from where it terminated in the previous call, with all it’s internal state intact (i.e. variables are held between calls). In Python a generator is defined by creating a function which uses the ‘yield’ keyword. Each time that a yield is hit the function will return the specified value. Let’s start with an example which defines a generator implementation of the built-in ‘range’ function:

def genrange(start, end):
    i = start
    while i < end:
        yield i
        i += 1

As you can see this is incredibly simple and behaves in the same way as the standard range function. The only difference is that when the generator method is called it will return a generator object rather than a value (in contrast to range, which will return a list of values in the range). These generator objects are iteratable so calling the ‘next’ method on the object will run your code and return the next yielded value. Because the generator object is iteratable, the way in which you are likely to use it should look familiar:

for i in genrange(0, 10):
    print i

If you want to go ahead and create a list from the sequence as you generate it, you can use a list comprehension, like so:

l = [i for i in genrange(0, 10)]

Of course, as hist comprehensions can be much more complicated than this you can use it to achieve more than just creating the equivalent list as calling the built-in range function. For example, you could filter the output elements according to some criteria, or call a method on each element returned.

A Trade Off

Although the above example is incredibly simple, it presents an interesting trade off between memory use and the speed of iteration through the ‘list’. The trade off exists because you could just build the list of elements in a separate function and then iterate through it. This is a perfectly valid approach but if there are a large number of elements you will use a significant quantity of memory to store the list. You are also more likely to double handle the data, unless you are building the list up over a period of time. Using a generator in this case is likely to be more efficient, as you are just creating the elements as you need them, so only storing a minimal amount of data at any one time.

The other side of the trade off is performance. If the process that produces your iterative data is computationally expensive, it makes no sense to calculate more values than you will need. So if you have a data processing loop, that can potentially exit early (i.e. before reaching the end of the ‘list’) a generator will be more efficient. But equally, if you require a tight loop which iterates quickly, you would want to pre-compute the values.

When considering using generators you should weigh up these factors and think which method is going to be most efficient for your situation. I think in a lot of cases, you will end up coming down in favour of the generator solution.

Another Example (Dan Brown is going to love me)

I’m going to leave you with another quick example, namely a very efficient way of generating Fibonacci numbers using a generator. Without further ado:

def fibonacci():
    p1 = 0
    p2 = 1
    while True:
        f = p1 + p2
        p2 = p1
        p1 = f
        yield f

There you go, easy. Many other Fibonacci implementations use a recursive method, which is horribly inefficient. Most other implementations will require either a class to store persistent data in, or the use of static variables, both of which are more tricky to handle from a programming point of view.

Well that’s it. I think I’ve demonstrated that generators are pretty cool. The examples I’ve presented are very simplistic, but I’m sure you can think of awesome uses for them. Go forth and code!

Intent i = new Intent(Intent.ACTION_SEND);
i.setType("text/plain");
i.putExtra(Intent.EXTRA_TEXT, "Testing intents on android");
startActivity(i);

These four lines of code hook into a key feature of the Android platform: Intents. The intent system is a neat way of communicating via apps and enables different apps to integrate together without knowing about each other specifically.

In this case, we are sending the ACTION_SEND intent, which Mustard is set up to handle. We set the mime-type of the message to ‘text/plain’ and put the contents of our message into the EXTRA_TEXT field. We then start the intent, and we’re done!

When the intent is started Android presents the user with a list of all the possible applications which can handle the ACTION_SEND intent. In my case this is Email, Gmail, Messaging and Mustard, when I select mustard the new message screen pops up and is populated with my message content. Hitting send posts the message and returns control to my app. Neat!

There are probably a whole host of ways you can integrate your apps with other apps on the phone using the intents system, I guess it’s just a matter of knowing what intents are received by each app and what they do.

Thanks to @macno (main developer of Mustard) and @bugabundo on identi.ca for their help working this out!

Anyway, I hope someone finds this useful. This is the first time I’ve posted about Android development, but I’ll hopefully write more about it in the future. Bye for now!

The following commands will resize an ext2, ext3, or ext4 filesystem running on LVM while it is mounted:

$ sudo lvresize -L +XXG <path to fs device>
$ sudo resize2fs <path to fs device>

In the above command you need to replace XX with the number of GB you want the filesystem to grow by and <path to fs device> by the device node (typically /dev/mapper/something).

An there you have it, done! Obviously there is a huge amount more you can do with the two tools above, take a look at their man pages for more info.

Hopefully this post will save me from having to work out how to do this every time!

But it is kinda static. By this I mean it’s not particularly suited to environments where things change frequently. For example, we have a local mirror at uni, which of course it much faster than using the external Ubuntu or Debian ones, however as this is only available from internal University of Auckland IP addresses I would have to change my /etc/apt/sources.list file if I wanted to install something from home.

Today I knocked together a quick Python script to fix this, all it does is basically manipulate a symlink which points to the real /etc/apt/sources.list file, but I thought I’d share it anyway:

#!/usr/bin/env python
import sys, os
def usage():
print "Usage: %s " % (sys.argv[0],)
def main(argv):
if argv[1] != None:
sources_path = "/etc/apt/sources.list.%s" % (argv[1],)
if os.path.exists(sources_path):
os.unlink("/etc/apt/sources.list")
os.symlink(sources_path, "/etc/apt/sources.list")
print "SUCCESS: Don't for get to run 'sudo apt-get update'"
return 0
else:
print "ERROR: Unknown repository set '%s'" % (argv[1],)
usage()
else:
usage()
return 1
if __name__ == '__main__':
sys.exit(main(sys.argv))

Unfortunately wordpress screwed with my formatting there (which kinda matters in a python script) so here is the file (repo-switch.py). You’ll need to download it and put it somewhere in your $PATH. Then make it execuatable:

chmod +x repo-switch.py

The next step is to set up your lists of repositories. Each list will have a suffix which the script will use to identify it. First I copied my main repositories (for the NZ Ubuntu mirrors):

sudo cp /etc/apt/sources.list /etc/apt/sources.list.nz

Obviously replace ‘nz’ with a suffix of your choice. Then I dropped the list of repos for the local mirror into another file (in my case /etc/apt/sources.list.ece). You can set up as many different sets as you like, but I only need two.

Next step is to practice switching between them:

sudo repo-switch.py nz

…sets apt to use the file /etc/apt/sources.list.nz by changing /etc/apt.sources.list to a symlink pointing to the relevant place. Calling the script again with a different set (e.g. ‘ece’ in my case) will set it up to use one of your other sets.

Obviously, you’ll need to run ‘sudo apt-get update’ each time to make apt work with the new repos, but I added a line to the script to remind you!

Magic!

I found this page, which documents the Xrandr, which can be used to configure monitors and screen resolutions from the command line. Some of the code snippets on the page got me into writing a script, which could toggle between the displays and be assigned to a hot key. I also added a mode to switch back to the laptop screen when there is not external screen (just in case my external monitor dies as happened in the power cut the other day!).

#!/bin/sh
# names of outputs
EXTERNAL_OUTPUT="VGA"
INTERNAL_OUTPUT="LVDS"
# external and internal resolutions
EXTERNAL_RESOLUTION="1024x768"
INTERNAL_RESOLUTION="1024x600"
# if the external output is disconnected, then switch back to internal output
xrandr | grep $EXTERNAL_OUTPUT | grep 'disconnected'
if [ $? -eq 0 ]; then
# just check to make sure we aren't on internal output already
xrandr | grep $INTERNAL_OUTPUT | grep $INTERNAL_RESOLUTION
if [ $? -eq 1 ]; then
xrandr --output $INTERNAL_OUTPUT --auto --output $EXTERNAL_OUTPUT --off
fi
exit 0
fi
# check to see whether the external output is active
xrandr | grep $EXTERNAL_OUTPUT | grep $EXTERNAL_RESOLUTION
if [ $? -eq 0 ]; then
# yep, we're currently using the external output, so switch back to the internal output
xrandr --output $INTERNAL_OUTPUT --auto --output $EXTERNAL_OUTPUT --off
else
# otherwise we want to change to the external output
xrandr --output $INTERNAL_OUTPUT --off --output $EXTERNAL_OUTPUT --mode $EXTERNAL_RESOLUTION
fi
exit 0

I assigned this to the Fn-F5 key combination using eee-control, which I already have running on my eeepc. The result is really nice switching between internal and external outputs, which solved my problem perfectly.