However, the actual reason why I type all this is that a lot of people have asked me whether I am about to provide an update of the openFrameworks 005 binding since 006 has been released. I am sorry to say that even though I plan to do so, I do not have the time to do it right now. What’s more, I don’t really know how long it will take, as there are some major changes in this of release.

WhyNotUnmount works on Mac OS X 10.4 (Tiger) and 10.5 (Leopard) and comes as a Universal Binary.

For more information on what the application does, please see the original post on WhyNotUnmount.

Download WhyNotUnmount (DMG, 315 KB, Freeware)

A new openFrameworks-Python Binding for OS X 10.5 is finally available for download. The new binding comes with an Xcode project including the openFrameworks 005 source code and required libraries plus an example of how to use the binding. As in the previous versions, after building the binding using Xcode, you may run the test example as follows: open up a terminal, go to the build/release directory of the binding and type: ‘python animation.py’. The example script should run out of the box. If it does not please don’t hesitate to contact me.

Note: for those who want to build the binding for OS X 10.4, please see the readme file contained in the package. It contains hints on how to build the project using the 10.4 SDK.

Requirements: OS X 10.5.5, Xcode 3.1.1+, SWIG, Python 2.5(+)
Download openFrameworks-Python Binding for OS X 10.5

This has now been solved as suggested by Maddi with an exception handling block. That is, as soon as draw.py has syntax errors in it, the draw code’s exception is caught by the Python code in animation.py. Rendering stops under this condition, but does not crash the framework. What is more the type of exception is outputted on stdout. As soon as the error is corrected, rendering is automatically resumed.

Unfortunately stderr is still redirected to nirvana inside the overridden functions called by the openframeworks library. I appreciate any suggestions on this issue.

» Download openFrameworks-0.04-Python Live Coding POC

Pythonware’s PIL, the Python Imaging Library, is an extension to Python enabling you to process and arrange images quickly. It supports the popular JPEG and PNG image formats and provides font rendering using the freetype2 library. Unfortunately, PIL is not included in the standard Python environment on Mac OS X 10.4/10.5, so you have to download and build it.

First of all, you might find that there is plenty of forum/blog posts, articles etc. on the web attempting to provide useful instructions on how to build and install PIL in the right fashion. However, I found that most of them are telling different things and so I didn’t really trust them. I tried a lot and basically all of them failed. I am going to explain now, why that was.

Following the README what you need in advance is: libjpeg (6b), libpng3 and freetype2. You can get these using fink or MacPorts. Since I don’t like my machine to re-compile all the stuff that is easily available in a binary form, I used fink.

After installing the required libraries via fink I tried to build PIL using the command as described in the README file:

$ python setup.py install

… and all I got was a lousy:

--- TKINTER support ok
--- JPEG support ok
--- ZLIB (PNG/ZIP) support ok
*** FREETYPE2 supported not available

It turned out that the setup.py file did for some reason not search the correct directories for the freetype2 library. Fixing this is quite easy: just set

FREETYPE_ROOT = "/sw/lib/freetype2/lib"

Note: This does only apply as long as you use fink. MacPorts directories differ!

I again built PIL using the setup.py install command. Everything seemed OK this time. So, as suggested by the installer script, I tried to run PIL’s self test now using

python selftest.py

which would result in

Failure in example: _info(Image.open("Images/lena.jpg"))
from line #24 of selftest.testimage
Exception raised:
Traceback (most recent call last):
  File "./doctest.py", line 499, in _run_examples_inner
    exec compile(source, "", "single") in globs
  File "", line 1, in 
  File "./selftest.py", line 22, in _info
    im.load()
  File "PIL/ImageFile.py", line 180, in load
    d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
  File "PIL/Image.py", line 375, in _getdecoder
    raise IOError("decoder %s not available" % decoder_name)
IOError: decoder jpeg not available
1 items had failures:
   1 of  57 in selftest.testimage
***Test Failed*** 1 failures.
*** 1 tests of 57 failed.

I googled and googled and found a lot of similar results, but no answers unfortunately. After some time I realized that PIL would run from any other directory, but only the selftest.py failed. The reason for this is that in the Imaging-1.1.6 directory there is a PIL.pth file and a PIL subdirectory. Python picks these up and tries to run PIL from there. Of course this cannot succeed, since the library is not built properly for our system there. The solution is to delete both the PIL subdirectory and the PIL.pth file and there it goes – the self test runs through without any failures.

Hope I have saved you some valuable time.

When it gets really cold in winter and you find your hands wrapped in thick gloves, it’s not that easy to pick up an iPhone call fast enough. CHCH.cc has a great solution on MacOSXHints.com: use your nose! I have googled around a bit to find some illustration of this (see YouTube video above).

Of course there are alternative solutions. For instance: iPhone-enabled Dots Gloves.

For more information on what the program does, please see the original post on WhyNotUnmount.

Download WhyNotUnmount (DMG, 530 KB, Freeware)

Recently I promised to write another post on what cool stuff can be done with the openFrameworks-Python binding. Besides the fact that being able to quickly write openFrameworks apps with Python is cool enough actually, Python is an interpreted language and does therefore enable us to execute and change code dynamically — even at runtime. Hence, an obvious purpose for using this feature is live coding.

In order to get us there, modifications need to be made to the original source code of animation.py. More precisely, the draw function of the testApp class has to be changed to something like this:

def draw(self):
    file = open(oscwd + '/draw.py', 'r')
    source = file.read()
    exec(source)
    file.close()

This code snippet loads the file draw.py located in the current working directory, which has previously been stored to a variable called oscwd. draw.py is going to contain the actual code responsible for rendering the openFrameworks scene. As you can see on the screenshot you can now start animation.py, fire up a code editor (in this case Xcode) to edit draw.py and begin live coding. As soon as you save your changes to the draw.py file the modified code will be executed in the animation.py application.

So far so good, but there are still some issues: for some reason (which I will explain later) the code inside the testApp class has a different Python environment than the surrounding code. This causes stdout / stderr to be redirected into nirvana (what ever you try to put on stdout inside the class will not appear in the shell; errors in your code will not be prompted either). What is more, the os and sys functions do not work properly here. This is the reason why I temporarily stored os.getcwd() in the oscwd variable of the animation module. Finally, the execution of the whole application will be broken as soon as you save draw.py with syntax errors (and as mentioned previously, stderr will not be prompted on the shell in this case). Consequently, the whole approach is still quite unstable and should therefore be considered a POC.

Download the live coding POC files (ZIP file, 5.1 MB, requires Mac OS X 10.4.11+ and Python 2.5)

WhyNotUnmount is a small project which I have started to make life a little bit easier for all those people carrying external hard drives with their MacBook. Of course, it is suitable for all other kinds of Macs also. WhyNotUnmount attempts to tell you why a certain (external) hard drive, DMG or other volume cannot be unmounted. In most cases this is because a file on that disk remains opened by an application on your Mac. WhyNotUnmount tells you which Application prevents your volume from being unmounted properly.

The application is currently in alpha (prerelease) state, which means that there may still be a number of bugs and – more importantly – that it may not always detect the correct reason for why unmounting is not possible. I am working on these issues at the moment. However, WhyNotUmmount is freeware, so it may take a little while until it is completely stable. In the meantime enjoy the early version!

Requirements:
Mac OS X 10.4 (Tiger) or 10.5 (Leopard).
Details on the artefacts page / Direct download.

Unfortunately the tufte-latex templates did not work initially in this configuration, which was kind of a mystery to me at the beginning, since the TexLive distribution included all required packages for tufte-latex. After a quick search I came across a discussion thread on the tufte-latex problem on 10.5 that got me in the right direction.

What I have done to make it work is as follows:

• Open up tufte-handout.cls in a text editor.
• Swap lines 294 and 295, so that it becomes:
  

  \newcommand{\footnotelayout}{\@tufteh@marginfont\@tufteh@justification}
  \RequirePackage[side,multiple]{footmisc}
  

• Typeset tufte-handout.