Installing MatPlotLib on Snow Leopard with MacPorts
I have been trying to install the excellent MatPlotLib graphing module for the Python programming language on my iMac for a while now. Unlike most python module installations I’ve done the excellent python SetupTools (a.k.a easy_install) has not been up to the task. So I ended up using MacPorts (version 1.8.1) to get MatPlotLib (version 0.99.1.1) installed on Snow Leopard (OS X 10.6.2) with X-Code (3.2.1 – 1613).
So here is a brief description of how to do it:
- Install the X-Code developer tools (for GCC, make and other build tools) from your Snow Leopard installation DvD.
- Install the X11 Window System from your Snow Leopard installation DvD.
- Run ‘Software Update‘ from the apple menu on your Mac to get the latest X-Code updates.
- Download the latest MacPorts installer (.dmg file extension) for Snow Leopard from here: http://distfiles.macports.org/MacPorts/.
- Mount the installer image file (.dmg) and run the contained MacPorts installer (.pkg).
- Once installation is complete open a terminal window from Applications->Utilities->Terminal.
- Type ‘port‘ at the terminal then press enter to run MacPorts. You should see output like the following if it installed correctly:
MacPorts 1.8.1
Entering interactive mode… (“help” for help, “quit” to quit)
Then type ‘quit‘ then press enter to exit port’s interactive mode. - Type ‘sudo port selfupdate‘ and press enter to update MacPorts to the latest version. You will be asked to enter the administrators password before continuing. Depending on how new the version you downloaded is, MacPorts may do some upgrading.
- Once the update is finished type ‘sudo port install py26-matplotlib‘ and press enter. This will attempt to install the latest version of matplotlib for Python version 2.6.*. You may be asked to enter the administrators password before continuing. MacPorts will now download, configure, build and stage the dependencies needed to build the latest matplotlib for Python 2.6. This took at least thirty minutes on my iMac and involved lots and lots of scrolling text output from the build process.
- Next we need to switch our environment to use version 2.6.* of Python that MacPorts just built and installed with matplotlib. To do this run the following two commands, note you may be asked to enter the administrators password before continuing:
- ‘sudo port install python_select‘ and hit enter.
- ‘sudo python_select python26‘ and hit enter.
- To test this all worked type the following: ‘python -V’ and hit enter. You should see output like ‘Python 2.6.4‘ which should match the version of python MacPorts built and installed.
- Finally to test if matplotlib was installed correctly do the following:
- Type ‘python‘ and hit enter to enter the python interactive shell.
- Type ‘import matplotlib‘ and hit enter, this will import the matplotlib module. There should be no output if this works.
- Type ‘print matplotlib.__version__‘ and hit enter. This will print the version of matplotlib that is installed, you should see output like ‘0.99.1.1‘.
- Type ‘exit()‘ to quit the python interactive shell.
Using SQLite in Python
Python has had support for SQLite built-in since version 2.5.
This is a very convenient pairing as SQLite is an excellent lightweight SQL implementation that I find very useful for a variety of tasks e.g. data mining. Or any task involving manipulating complex data sets where I’d otherwise end up resorting to using a full blown SQL server like MySQL.
Here is a simple example of using SQLite in Python using it’s built-in sqlite3 module:
import sqlite3
# craete a connection
con = sqlite3.connect('test.db')
# create a cursor
cur = con.cursor()
# create a test table
cur.execute( "CREATE TABLE testTable (myKey INT, myValue INT)" )
# insert some data
for i in range(0,10):
cur.execute( "INSERT INTO testTable VALUES ( %d, %d )"%(i,i*i) )
# select the data
for row in cur.execute( "SELECT * FROM testTable" ):
print row
# destroy (drop) our test table
cur.execute( "DROP TABLE testTable" )
# close the connection
con.close()
As you can see Python makes handling SQLite (a C language library) much easier, less error prone, and the resulting code much more compact than SQLite’s native C.
Setting mac desktop wallpaper with Python
I have been playing with Python recently.
Here is a little script to change a mac’s desktop wallpaper to the file specified as the first argument of the script:
import subprocess,sys,os # Raw apple script Script = """/usr/bin/osascript<<END tell application "Finder" set desktop picture to POSIX file "%s" end tell END""" # get the file name which is the first argument passed to this script filename = sys.argv[1] # run the apple script inserting the filename subprocess.Popen(Script%filename,shell=True)
Or using the nifty appscript module for python:
import sys
from appscript import app, mactypes
# get the file name which is the first argument passed to this script
fileName = sys.argv[1]
# use the appscript module to change the desktop wallpaper
app('Finder').desktop_picture.set(mactypes.File(fileName))
The more I use Python the more I like it. I used to think Python was at a similar level to C# in terms of how high a level a programming language it is. After using Python for a bit I now realise that Python is a higher level programming language than C#. Out of the languages I use reguarally it would seem that Python is the highest level language followed by C# then C++ and finally C.
Fail to succeed!
The more experienced I become the more aware I become of what I don’t know and the more I come to terms with the fact that I make mistakes.
The awareness of what I don’t know helps keep me humble, humility makes working as part of a team easier: as there is no pressure to have to know everything or not make mistakes. In fact I tend to expect to make mistakes more now than when I first started programming. Perhaps it is the years I have spent shipping games that finally proved to me that I too write software that contains bugs (the horror!).
I remember a professor at university telling me that the main difference between a professor and a first year student working on a programming task is that the student will start working immediately and also start making mistakes immediately, the professor will think for a while then start work and start making mistakes as well. I have found this observation to have a surprising amount of truth in it,:whether it is at university, work or even sports.
Mistakes are healthy: without mistakes we would have not reason to every really think about what we are doing e.g. why didn’t that work? By continually pushing (or stretching) ourselves to failure we discover our boundaries, once we know where are our boundaries are we can then start to work on pushing them further. However if we always play it safe and never push ourselves (which can be scary) we will never discover our boundaries which makes improvement much harder and also makes approaching those boundaries harder due to fear (typically of loss of control).
An excellent example of this is people learning to ice skate: young children will tend to fling themselves around the rink with wild abandon falling all over the place (as failure is expected but irrelevant due to lack of social stigma), yet adult beginners typically skate in a much more conservative fashion taking less risks (as there is social stigma against falling as an adult: falling is seen as failure). Interestingly when observing ice hockey players, it is noticeable that those with the best skating technique are typically falling more than the other the non-beginner players on the ice, as they do not fear falling.
As most of us are not engaged in high risk activities on a daily basis we can easily begin to revise how we think about failure and to learn to embrace it as a powerful tool for self improvement.
No bad programming languages
I encountered some truly hideous source code today in a programming language in which I wouldn’t have thought hideous obscure code was possible: C#. It was my first real experience of abject horror when looking at the source code of a C# application. Obviously with hindsight it would seem that you can write hugely, dense, brittle and hard to understand programs in any programming language. And yet I would not expect a C# source code to be this obtuse or brittle but I would expect a Perl script to be dense and hard to read.
It is not that I have anything against Perl as a programming language: it is a fine language. I find that Perl’s motto of `There’s more than one way to do it.’ means that it is a programming language with (you guessed it) more than one way to implement most operations. This flexibility is a double edged sword: it allows a lot of creativity in program implementation, yet it also means that a dozen Perl coders will produce a dozen radically different scripts for the same problem. This makes Perl quite hard on beginners or infrequent maintainers of Perl scripts: as to understand any given Perl script requires an understanding of much more of the Perl programming language than it would for most comparable programming languages.
I digress.
I’ve known for years that it is possible to write awful obscure code in low level languages like C and C++ but it really hadn’t occurred to me that a high level language like C# could be abused to the same degree. Thinking about this some more, it is not the fault of the programming language itself but of the programmer that is using it.
So, brittle obtuse code is the result of a bad programmer not a bad programming language: well except maybe Brain Fuck (but thats kinda the point).
You Aren’t Gonna Need It!
A very common trap to fall into while implementing a new system or feature is to add functionality to ‘future proof’ your code for a use case that you imagine in may be required in the future. The future for the purposes of this post is any time that is not in your current development iteration.
This may seem harmless but consider that the future use cases you are imagining are not something you fully understand yet: as most of us will admit we are pretty bad at anticipating the future. So how can we hope to implement future functionality successfully? The most likely outcome is that whatever you implement now not be sufficient when you actually try to use it in the future. This will mean more time will have to be invested in the future to refactor or replace the functionality with what is actually required.
Unless you also plan to implement a full set of tests for this new functionality then you are adding extra code to your program that will not be correct and will not stay correct. This can also lead to really weird run time behavior if the flow of program execution goes into your new ‘future proof’ functionality unexpectedly: which can be very hard to debug. Adding functionality for future use without corresponding tests also means that as the rest of your program evolves the future functionality does not evolve with it, this means by the time you actually try to use it that it is most likely hopelessly out of sync with the rest of the code base.
The future functionality is also expanding the size of the source code of your program which leads to unnecessary code bloat. In some compiled languages (e.g. C++) code bloat will lead to increased memory usage and decreased program performance which is highly undesirable.
Another thing to consider from a business stand point is that you are spending time and money implementing future functionality when you are not being paid for it. This is a strong indication to me that implementing future functionality makes little business sense. As it means spending money now paying developers to implement functionality that you can’t sell right now.
There is a handy acronym for this: it is YAGNI which stands for ‘You Aren’t Gonna Need It’. The essence of this concept is to only implement the functionality you need right now and to implement in as simple and robust a fashion as possible. As simple robust code (preferable with acompaning unit tests) is code that can be easily refactored in the future to meet future needs and that is cost effcient!
