- Lana works again (i.e. it doesn’t cheerfully move the bytecode around in memory while you’re trying to run it)
- I’ve implemented the Hough transform and the inverse Hough transform
- The following ImageLana code runs:
go = procedure() a=imgload("testvertline.png") b=a.hough() c=b.dehough(0) c.normalise() a.view(0) b.view(1) c.view(2) end go() wait()
And I get the following images out:
I keep everything in Subversion. Lecture notes, bits of writing, everything. Including bits of miscellaneous code, the prototypes of which sometimes blossom (or metastasize, depending on your point of view) into full-sized projects.
To this end, I have a “miscellaneous code” repo with subdirectories for each new thingy. Most of these are very small, but sometimes they get large or I might want them to become public, in which case I have to turn part of this repo into a whole new repo.
To do this, I need to:
- dump the repository
- filter the repository to include only the bit I want
- change paths
- populate a new repo with the new data
svnadmin dump svn/misc_code | svndumpfilter include \ --drop-empty-revs \ --renumber-revs /barry >barry.dump
Now you can create the new repo and load the data into it:
svn create svn/newrepo svn load svn/newrepo < barry.dump
Also, pretty much none of this will work with binary data because of the hell that is md5 checksums being screwed up. But for text-only repos, it should be fine.
Well, that bug’s fixed. Simple matter of changing the order in which reference counts are incremented and decremented. Valgrind reports no problems from the unit tests under both memcheck and exp-ptrcheck. Now for more documentation (which is about halfway through its initial release.)
I’ve reached what feels like a fairly significant milestone in Lana today – the following transcript shows dictionaries and iterators working, with all the objects and temporaries being garbage collected successfully. There is, of course, a bunch of rather more extensive unit tests to write now, but it’s starting to feel like a proper language.
Script started on Sun 24 Jul 2011 11:43:44 BST white@cranberry:~/misccode/script/lib/lana$ cat foo f=function() a=dict() a=0 a="wobble" a["hello"]=56 print("ITERATOR START") for i in values(a) print(i) endfor print("") for i in keys(a) print(str(i) + " " + str(a[i])) endfor end f() white@cranberry:~/misccode/script/lib/lana$ valgrind ./testmain foo ==4441== Memcheck, a memory error detector ==4441== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==4441== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info ==4441== Command: ./testmain foo ==4441== ITERATOR START 0 wobble 56 0 0 1 wobble hello 56 ==4441== ==4441== HEAP SUMMARY: ==4441== in use at exit: 0 bytes in 0 blocks ==4441== total heap usage: 160 allocs, 160 frees, 60,172 bytes allocated ==4441== ==4441== All heap blocks were freed -- no leaks are possible ==4441== ==4441== For counts of detected and suppressed errors, rerun with: -v ==4441== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 18 from 7) white@cranberry:~/misccode/script/lib/lana$ Script done on Sun 24 Jul 2011 11:43:58 BST
- Creating a basic applet
- Registering the applet by writing a server file
- Testing the applet
- The Meter class – making the code OO
- Adding a timer
- Adding the wattage
- Files to download
Last time we looked at the basics of Python, and how Linux allows access to system information via file-like objects inside the
/dev filesystem. We then looked at writing a Python function which got the battery information and calculated the power drain in watts.
Now, we’re going to actually build a panel applet to display this value at regular intervals, and write the special file Gnome needs to be able to run the applet and insert it in a panel.
Let’s start our code off with a whole bunch of imports, for the various Python libraries we’ll need; and the
get() method we wrote last time. We’ll put all this into a file called
#!/usr/bin/env python import gnomeapplet import sys import pygtk pygtk.require('2.0') import gtk import gtk.glade import gnome.ui import os.path import re import gobject def get(): f = open('/proc/acpi/battery/BAT0/state') for x in f.readlines(): if x.find('present rate')>=0: d,data=x.split(':') ma,d = data.strip().split() ma = float(ma)/1000.0 if x.find('present voltage')>=0: d,data=x.split(':') mv,d = data.strip().split() mv = float(mv)/1000.0 f.close() return ma*mv
A basic applet
Gnome uses the Bonobo object model to connect components together. This lets us have many different programs, displaying data in their own way inside components belonging to other programs. And this is how panel applets work: your applet is a Bonobo component, displaying its data as part of the Gnome Panel app.
To write a Bonobo applet, you need to provide a function which Bonobo will call. We’ll call this the “factory function.” It takes a Bonobo container widget and the activation IID (a unique string for every bonobo object type, we can ignore it here.) We pass this function to a special
gnomeapplet method called
bonobo_factory(). This will set up the container widget for us and then call our function.
Inside our factory function we should create our GTK widgets, and add them to the applet, and tell the applet (and its widgets) to show itself.
Our code will therefore go something like this for a very simple applet:
def factory(applet,iid): widget = gtk.Label("test!") applet.add(widget) applet.show_all() return gtk.TRUE # indicate success! gnomeapplet.bonobo_factory("OAFIID:GNOME_Wattometer_Factory", gnomeapplet.Applet.__gtype__, "wattometer", "0", factory)
This is pretty much the simplest panel applet there is, displaying a single label with the word “test!” in it. Everything in here should be straightforward, apart from all those arguments to
bonobo_factory(). These are:
- The bonobo-activation iid of the factory (more on this later.)
- The type of the object, which will be an applet – bonobo factories are actually used all over Gnome for all sorts of things, but here we want an applet. We get the type using Python’s reflection mechanism.
- A description.
- A version.
- The factory function we’re providing.
Of course, if you run this, it won’t do anything – we haven’t told Gnome about it.
Registering the applet
We now need to tell Gnome about the applet. We do this by providing a server file and putting it into
/usr/lib/bonobo/servers/, where it will be read by the bonobo activation server daemon. Here’s our file, which we should call
<oaf_info> <oaf_server iid="OAFIID:GNOME_Wattometer_Factory" type="exe" location="/home/white/misccode/wattometer/wattometer.py"> <oaf_attribute name="repo_ids" type="stringv"> <item value="IDL:Bonobo/GenericFactory:1.0"/> <item value="IDL:Bonobo/Unknown:1.0"/> </oaf_attribute> <oaf_attribute name="name" type="string" value="Wattometer"/> <oaf_attribute name="description" type="string" value="Wattage applet"/> </oaf_server> <oaf_server iid="OAFIID:GNOME_Wattometer" type="factory" location="OAFIID:GNOME_Wattometer_Factory"> <oaf_attribute name="repo_ids" type="stringv"> <item value="IDL:GNOME/Vertigo/PanelAppletShell:1.0"/> <item value="IDL:Bonobo/Control:1.0"/> <item value="IDL:Bonobo/Unknown:1.0"/> </oaf_attribute> <oaf_attribute name="name" type="string" value="Wattometer"/> <oaf_attribute name="description" type="string" value="Wattage applet"/> <oaf_attribute name="panel:category" type="string" value="Utility"/> <oaf_attribute name="panel:icon" type="string" value="iconimage.png"/> </oaf_server> </oaf_info>
Complicated, yes? However, it’s pretty much a standard format for applets. You can see it registers two servers: the first is the executable (type “exe”), which is our Python program. The second is the applet factory itself, which is told about the exe so it can use our program to fill itself with our widgets.
The only things you need to worry about are:
- Making sure the IID’s are unique. The IID of the factory is the IID which we should use in our program’s call to
- The name and description in the factory block
- Making sure the factory’s location attribute points to the exe
- Making sure the exe’s location attribute points to the location of the python program
You might also want to change category and image, too.
Once you’ve set this up correctly, and copied it into the servers directory, the Gnome Panel’s “Add To Panel…” dialog will contain the new applet. Naturally, you’ll have to be an administrator to be able to put the server file into its new home!
Testing the applet
If you just run this program from the command line it won’t do much: it’s not being called from inside the activation server, so there’s no applet framework for it to plug its widgets into. We’ll modify our code so that we can run it:
def factory(applet,iid): widget = gtk.Label("test!") applet.add(widget) applet.show_all() return gtk.TRUE # indicate success! if __name__ == '__main__': # testing for execution if len(sys.argv) > 1 and sys.argv == '-d': # debugging mainWindow = gtk.Window() mainWindow.set_title('Applet window') mainWindow.connect('destroy', gtk.main_quit) applet = gnomeapplet.Applet() factory(applet, None) applet.reparent(mainWindow) mainWindow.show_all() gtk.main() sys.exit() else: gnomeapplet.bonobo_factory("OAFIID:GNOME_Wattometer_Factory", gnomeapplet.Applet.__gtype__, "wattometer", "0", factory)
Let’s look at those changes.
First, we use the “if name=main” trick to make sure we’re actually being run from the command line. If the code is just being included in another program, we won’t do anything. It’s not entirely necessary here, but it’s good practice. Then, we look to see if we’ve been called with a “-d” argument. If so, instead of going the normal route of plugging into an existing widget (the applet,) we
- create a window
- create an applet widget
- call our factory, creating our widgets inside the applet
- make the applet part of the window
- show everything
- run the GTK main loop until we exit
So now, if we run the program with
python wattometer.py -d
we’ll see a tiny window pop up with our applet inside it, just like a normal application. There are no title bar buttons, so you’ll have to close it by killing the process. Ctrl-C from the command line should do it.
To keep everything tidy, we’re going to put all the user interface code into a class called
Meter. All our factory function will do is create a new
Meter object. Add the following code, and change the factory method as shown:
class Meter: # this is the constructor def __init__(self,applet,iid): self.applet = applet self.ebox = gtk.EventBox() self.label = gtk.Label("test") self.ebox.add(self.label) applet.add(self.ebox) applet.connect("destroy",self.cleanup) applet.show_all() def cleanup(self,e): pass # pythonese for "do nothing" def factory(applet, iid): Meter(applet,iid) return True
If you’re new to Python, note the following oddities of Python’s object syntax:
- Methods definitions always have
selfas their first argument, even though this isn’t passed in in the normal way
- Methods and instance variables must be preceded by
self.when accessed from a method
- The constructor is called
- Like all variables in Python, we don’t need to declare instance variables – just setting them to values inside the constructor will do that.
Two functional changes have also been made here: the label is created inside an EventBox, so we can catch clicks and the like; and the applet now calls a cleanup method when it’s closed – which does nothing, but it’s always a good idea to have it there in case you need to add something to it.
Everything’s now nicely contained, and we can start to build the Meter functionality.
Adding a timer
It’s not much use just displaying the wattage once; we need to show it every few seconds. To do this, we’ll use a timeout timer, which will call a given method at regular intervals.
We start a timer by adding a method called
settimeout() to our class:
def settimeout(self,delay): if self.source>=0: gobject.source_remove(self.source) self.source=gobject.timeout_add(delay*1000, # delay in milliseconds self.timeout_callback, self)
What this method does is destroy a timer if one already exists, and then create a new one. That way, we can call the method several times if we want to change the interval.
We’ll also need to add some code to our constructor to initialise the source value and start the timer. We’ll also initialise a counter for testing purposes:
def __init__(self,applet,iid): ... self.counter = 0 self.source = -1 self.settimeout(2) # 2 seconds
We’ll use the counter in our callback method:
def timeout_callback(self,event): self.counter = self.counter+1 self.label.set_label("count %d" % self.counter) return True
If you run this you’ll find that the label says “test!” for the first five seconds. This is because the correct data isn’t put there until the timeout runs. This is no good for our purposes, so we’ll put the code to change the label into a separate method which we’ll run from both the constructor and the timer tick:
def __init__(self,applet,iid): ... self.counter = 0 self.source = -1 self.settimeout(2) # 2 seconds self.setlabel() def setlabel(self): self.label.set_label("count %d" % self.counter) def timeout_callback(self,event): self.counter = self.counter+1 self.label.set_label("count %d" % self.counter) return True
Run this with
-d, or even as an applet if you’ve installed the server file, and you’ll see a slowly increasing count. Nearly there!
Adding the wattage
Finally, we’ll want to actually call our
get() function to output the ever-changing wattage. Get rid of the counter, and replace the new
setlabel() method. One little quirk – if the system reports we’re using a very small about of battery power it doesn’t mean that we’ve suddenly gone into Hyper-Efficient Battery Usage Mode, it means that we’re plugged into the mains. Although it could be argued that this is a Hyper-Efficient Battery Usage Mode… anyway, we’ll check for that case:
def setlabel(self): v = get() if v<0.001: s = "(charging)" else: s = "%0.1fW" % v self.label.set_label(s) return True
Note how we’re formatting the wattage: the format string
%0.1f means we should use one decimal place of precision.
And we’re done! You now have a working wattage applet!
You can download the files developed in these articles as a zip file from here. They are:
GNOME_Wattometer.server, which should be edited to change the location of
wattometer.pyand put into
wattometer2.py, an improved version which uses a drop-down menu to allow the user to change the sampling rate
- Writing a power consumption applet
- Using Bonobo (sorry)
- Very quick intro to Python
- Reading the battery info from a pseudofile interface
- Writing a function to calculate the power
So that I can see the power consumption of my shiny new netbook second by second, I’m going to write a Gnome panel applet which will display it constantly.
Now, this may not work in Unity, the new desktop environment for Ubuntu, but I’m not using it (yet) and a lot of people aren’t happy with it, so I’m ignoring it.
First, a confession. This applet uses Bonobo, which is deprecated. It’s also, it seems, currently the only way to write Python applets using standard repository packages, until the new GObject Introspection API is stable. When that happens, I’ll write a post porting this code.
Another alternative might be a rewrite in C, using this version as a prototype – and that’s something I’m seriously considering.
I’m going to use Python – it’s a good language for doing this sort of task, with lots of helpful text processing stuff and not too many barriers to getting something up quickly. For me, Python sits neatly between a scripting language and a software engineer’s language. If you don’t know Python, hopefully you’ll at least be able to follow along, but I’ll get you started by quickly introducing the oddest thing about the language.
Python doesn’t use curly brackets like Java and C to delineate blocks of code. Instead, it uses a colon on the line before, and an increase in indentation. When the block is finished, the indent decreases again. For example:
def foo(a,b): if a>b: print "A is greater than B" print "so I'll call bar()" bar(a,b) else: print "Other way round, so I'll call baz()" baz(a,b) def anotherfunction(): ...
You see that there’s no keyword or symbol saying we’re at the end of an “if” statement, or even at the end of a function definition – it’s all in the indenting.
First we need to write the code to get the power drain in watts, and just print it on the console. We’ll write this as a function called
getpower() which returns a floating point value.
To do this, we’re going to need to look at the battery state, which is in a special file called
This isn’t actually a file – it’s a pseudofile. It looks like a file, but reading it runs some special code which outputs some text describing the state of the battery. This sort of thing happens a lot in UNIX-style operating systems – the pattern is called “Everything is a File.” If you look around, you’ll find pseudofiles which represent devices (in
/dev), files which represent processes (in the top level of
/proc) and many files which represent system state (such as our battery file.)
Note: Your machine may use a different name for the battery – please check. If I were writing this properly, I’d probably make the code find the battery file itself by scanning the directory, and I’d have to make it deal with multiple batteries.
The contents of this fake file look something like this:
present: yes capacity state: ok charging state: discharging present rate: 773 mA remaining capacity: 3145 mAh present voltage: 12067 mV
We’re going to need to
- extract the “present rate” and “present voltage” values
- convert them from milliamps and millivolts into amps and volts
- and multiply them together to give the current power drain in watts
Luckily this is very easy in Python!
We start by opening the battery state file for reading:
def getpower(): f = open('/proc/acpi/battery/BAT0/state')
If you’re not familiar with Python,
def is used to define a new function, which in this case takes no parameter. Blocks of code are marked by a colon, a new line, and a change of indentation – this is the weirdest thing about Python to a (say) Java or C programmer.
Now we scan the file line by line, using the
foreach construct, which repeats a block of code for each element of a list, and the file method
readlines() which returns a list of lines in a file:
for x in f.readlines():
First we see if the current line has “present rate” in it. If it has, we split the line into two strings – the part before the colon, and the part after. Here we make use of the handy ability of Python to return lists of things, making it look like we’re returning two values:
if(x.find("present rate")>=0): dummy,data = x.split(':')
We throw away the string before the colon, and just use
data. This string looks something like this: ” 654 mA”
We need to remove the leading space, and split the “654 mA” by the space in the middle, giving us just the “654″ part (or whatever the amperage actually is.) We can do this by chaining a couple of methods together:
ma,dummy = data.strip().split()
strip() returns a string without leading or trailing spaces, and the
split() will split that string into two using the whitespace, leaving “654″ in
ma and the “mA” in
dummy. Finally, we need to turn this string into a floating point number:
amps = float(ma) / 1000.0
We now have the current in amps, as a floating point value.
We do exactly the same thing to get the volts:
if x.find("present voltage")>=0: dummy,data = x.split(':') mv,dummy = data.strip().split() volts = float(mv) / 1000.0
We scan the whole file, doing these two checks on every line. Finally, we get to the end of the loop. We can now close the file, and return our power drain – calculated by multiplying the current and the voltage:
f.close() return amps*volts
And that’s that. If we put this altogether in a test program, we can print out the current:
#!/bin/python def getpower(): f = open('/proc/acpi/battery/BAT0/state') for x in f.readlines(): if(x.find("present rate")>=0): dummy,data = x.split(':') ma,dummy = data.strip().split() amps = float(ma) / 1000.0 if x.find("present voltage")>=0: dummy,data = x.split(':') mv,dummy = data.strip().split() volts = float(mv) / 1000.0 f.close() return amps*volts print getpower()
That function is the core of our applet, which we can now build around it.
Next, we’ll start looking at building the applet itself.