The MagPi issue 7 is out

The MagPi issue 7 has been released. What’s more I have two articles published in this issue: an interview with Mike Thompson who created Raspbian, and my first ever published computer program! I took over The Python Pit this month to demonstrate how one can implement command line arguments to make configuring an application that is about to be run easier than having to manually edit the program code.

I am especially pleased with the program I wrote as it generates graphical output (see image below) that I used to draw by hand when I was a child. Back then I don’t even think it occurred to me to write a program to do this!


The program supports a number of command line arguments to change the output. Run: -h
to see all of the options.

For your viewing pleasure, here’s the output of the above:

usage: [-h] [-s SCALE] [-t STEP] [-r {y,n}]

Render shape

optional arguments:
-h, --help show this help message and exit
-s SCALE Render size, default=2, 200x200px)
-t STEP Step value (default=5): lower the value for denser lines
-r {y,n} Render line by line (slower) (y) or only display finished object
(faster) (n)? (default=y)


Using an Android phone as an XBMC remote control

I’ve been a little quiet on the RPi for a week while enjoying XBMC working pretty well. However one thing has been bothering me: a lack of a decent remote control.

XBMC Huzzah!

My N570 powered Asus Eee Netbook took 12 hours to build OpenELEC for the RPi. And now I have XBMC up and running :)

Raspberry Pi: do NOT read the FAQs!

Here is an odd one for you. The one web page that seems to give my shiny new RPi more headaches than any other I have tried is the official RPi FAQs page: . This is a very long page. No, that is an understatement: it is a veeeeerrrry long page. Even my iMac took a few seconds to start rendering it. The RPi just chugs on this page.

Moving the gazillion comments out to per-FAQ sub pages may help, but there you have it, you have been informed ;)

LXDE on Pi, not the fastest cookie (but that's ok)

In my last post I mentioned that I had used the command startx to run the LXDE GUI, aka “Gnome without the hassle” (IMHO). This time around I explore a little of what LXDE has to offer on the RPi.

Raspberry Pi - first hands on moment

Opening the miniscule box that the Raspberry Pi comes in (if it were a plug computer it would challenge them all in the size stakes) myself and those around me at work started making the obligatory “ooo” and “aahh” noises.

The MagPi issue 8 is out

The MagPi issue 8 has been released, featuring my second ever published program when I take over The Python Pit again. This time around I show how to use Python’s subprocess to create desktop widgets. Think: those things what Windows Vista and 7 has and you won’t be far off.

The Python program has an intentional flaw, but I only reveal general details on this to the readership. This is by design as one of the things I always liked about programs in those 1980s computer magazines (you know, the one’s that listed the code and you had to type it yourself back in the days before cover cassettes / disks or discs became the norm) was that you often had to finish the program off, or improve it to get it to work _just_right_.

If you are reading this I’ll let you know a bit more detail to help you out.

As I note at the end of the article, refreshing the Pygame screen for each widget occurs at the same time as each checks for new content. The problem this causes is that if I drag another window on top of either Pygame window it will blank the output until the next check for content, which could be hours away. The fix is quite straightforward and involves adding an if statement that uses datetime to determine when to check for new content, and changing time.sleep(28800) and time.sleep(3600) to both be time.sleep(1). This means that each pygame widget’s screen will refresh every second (change this to 0.1 for faster refresh, every tenth of a second, at the cost of higher CPU usage by Python) BUT a check for new content will still only happen periodically when the new datetime value is suitably different from the old datetime value. You do NOT just want to change to time.sleep(1) on its own as this will cause both URLs to be queried every second for new content which is much too frequent.