openFrameworks-0.04-Python Live Coding POC Reloaded

December 12th, 2008 · No Comments · Creative Coding

Recently I presented the openFrameworks-Python live coding proof of concept on this blog. Unfortunately, the first version was quite unstable, because code changes introducing syntax errors would crash the running application framework.

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

→ No CommentsTags:··

Kill PIL – The Python Imaging Library Headache or Building PIL on Mac OS X

December 4th, 2008 · 6 Comments · Creative Coding, Information Visualization

PIL Clusters

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.

→ 6 CommentsTags:···

WhyNotUnmount 0.2 (Alpha Prerelease)

November 21st, 2008 · 2 Comments · Projects

WhyNotUnmountWhyNotUnmount 0.2 has been released today. A number of bugs are fixed now. WhyNotUnmount will now display all blocking processes regardless of whether they are UI or system processes.

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

Download WhyNotUnmount (DMG, 530 KB, Freeware)

→ 2 CommentsTags:·

openFrameworks Live Coding Proof of Concept

November 20th, 2008 · 5 Comments · Creative Coding

Live Coding OF Proof of Concept

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)

→ 5 CommentsTags:··

WhyNotUnmount v0.1 – Prerelease Alpha

November 12th, 2008 · 4 Comments · Projects

WhyNotUnmount Screenshot

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.

→ 4 CommentsTags:·

Installing tufte-latex 2 on OS X 10.5

November 8th, 2008 · 2 Comments · Bugfixes

The tufte-latex package is a template implementing the tufte book style on latex. When I upgraded to Mac OS X 10.5 my old teTex configuration became obsolete. I replaced it with the newest MacTex 2008 package including TexLive 2008. As a GUI I chose to continue using the TexShop application, which I have gotten used to in my previous work.

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.

→ 2 CommentsTags:···

Embedding Python in a Cocoa Application

November 4th, 2008 · 4 Comments · Tutorials

I stumbled upon Ragestorm.net‘s great tutorial on Python embedding when I was trying to embed Python in a Cocoa application and redirect standard output / standard error to an NSTextView. Ragestorm’s tutorial is not particularly about Cocoa / Objective-C, but does though solve the problem. Stdout / stderr is simply redirected using a fragment of Python code, which is injected directly after the Python runtime is loaded. It makes use of a couple of C-functions provided by the host application, which connect the Python output to the Cocoa-based NSTextView.

I have uploaded the Python Console Sample Xcode project containing all the code. I think it’s pretty self-explanatory. Have fun!

→ 4 CommentsTags:····

Energy Information – The next Big Thing?

October 29th, 2008 · 3 Comments · Buzz, Energy

I recently read an article at the New York Times Green Inc. Blog about rough speculations on the next (really) big thing planned at Google. The talk is about »Google’s energy ideas« and whether these will be implemented in an open source way or not. However, in my opinion, of more importance than the applied licensing form are the actual ideas currently developed, which may shape future energy markets if implemented smartly. The NYT quotes Mr. Ed Lu from Google as follows:

“We can’t really talk too openly about what we are doing just yet,” said Ed Lu, who works in advanced projects at Google. Mr. Lu, a former NASA astronaut, said he could only talk in general terms. “The big area that we are looking at is energy information,” he said.

[…]

He chose to explain Google’s thinking with an analogy. Buying electricity today, he said, is a bit like going to a grocery store where the items have no prices and where you get billed a month later for your purchases. Some engineers in Mr. Lu’s team, are working on tools to turn energy buyers into more informed consumers, he said.

Mr. Lu does not reveal a lot. However, what he reveals points in an interesting and potentially very profitable direction. Firstly the term »Energy Information« itself caught my attention. I predict this will be one of the most important buzz words in the beginning 2010 decade, even if there is (at the moment) no Wikipedia article on »Energy Information« and you won’t even find anything of relevance in this context when you type the term into the Google search field (considering that the EIA is a helpful energy information source only for experts, and even for them they cannot provide consistent and complete information in all cases). The term has not been defined closer by Google yet, which is simply because it still remains a business secret. However, combining energy and information is, in my humble opinion, the most promising step for an IT company seeking to »index the planet« in the present situation. There are at least strong hints that high energy prices and increased energy scarcity will remain an issue for the world for a significant amount of time. What is more, information about energy costs, flows and inventories seems to be inaccessible or unavailable on a broad scale. This holds true for the governmental, commercial and the consumer side. Mr. Lu clearly identifies the latter as what Google aims at with its »Energy Information« ideas.

So what is Google likely to do? How do they seek to implement a convenient consumer (end-user) tool for controlling energy costs? Does the existing infrastructure (internal and external) enable Google to implement such a tool successfully? What has to be done on the commercial / industrial (or even governmental?) sector to provide such a tool?

As you can see there are several questions that arise from this. The ones listed above are not even half of what came to my mind when I read the article. I admit I don’t have answers for (all of) them yet. However, a rough guess is that implementing such a thing as a consumer energy information system implies that you need collaboration with energy retailers and the industry. Probably you will also need infrastructural improvements or work-arounds. Moreover, it would make much sense to base the system’s business model on a win-win situation (better prices / price control for consumers, better grid capacity utilization for energy retailers). However, these are just rough thoughts on the issue. I will certainly write another article on the topic therefore.

→ 3 CommentsTags:·

Creating XCode Projects for SWIG Python-bindings

October 24th, 2008 · 9 Comments · Tutorials

SWIG makes the creation of bindings for C/C++ libraries easy for various high-level exits (Java, Perl, PHP, Python, etc.). However, in the case of Python on OS X, when the actual SWIG wrapper is finished the difficulties begin: one needs to create an adequate dynamic library for the Python runtime — and like with everything in life, the devil is in the details. I attempt to provide some helpful instructions on how to create an XCode project for compiling Python modules. The tutorial is based on XCode 2.4.1 and Python 2.5. The instructions may not be valid for newer versions of XCode / Python.

Some preliminary words on the SWIG documentation regarding this topic: there is a general SWIG tutorial featuring instructions on how to create wrappers for some of the most popular exits. In the case of Python there are special instructions on how to build an adequate dynamic library using command-line tools. Unfortunately, these instructions cover the basics, but are a bit misleading sometimes and leave out some important details. The following step-by-step tutorial should fill in the missing stuff.

The following tutorial uses the openFrameworks (0.04) library as an example. However, the process should be very similar for other libraries.

  1. Create the SWIG wrapper for the library you would like to create a Python-binding from. (On OS X you can use fink to install a command-line SWIG tool; instructions on how to build wrappers are available on the SWIG website.)
  2. Ensure both the SWIG wrapper files and the library source code are in the same directory, so you can easily create an XCode project for them.
  3. If there is an XCode project available for the original C/C++-based library, I suggest that you use this project and create a new target for the Python-binding. Otherwise you should first create an XCode project for the actual library and then attach a binding target to it as both the actual source code and the SWIG wrapper need to be compiled.
  4. Create the target by right-clicking on ‘Targets’ and then choose ‘Add’ » ‘New Target…’. Then select ‘BSD’ » ‘Dynamic Library’ as type of the new target:
    Creating the Target
    Finally provide a name for the target. In this case I have named the target ‘ofpython’.
  5. Now it is time to populate the target with source files and linked frameworks. Simply drag and drop the required source files and linked frameworks from the library target and add the SWIG wrapper source files. In the case of openFrameworks this looks like the following:
    Python Target
  6. As you can see I have added the Python.framework to the ofpython target. You must do so as well by right-clicking the target, then choose ‘Add’ » ‘Existing Frameworks…’ and select the Python.framework from ‘/Library/Frameworks’.
  7. Now let’s talk about the tricky part, target configuration. In order to enable Python to load the compiled module, there are a number of modifications that have to be done. The following is a step by step to-do list of each setting that has to be changed:
    1. Change the Product Name to the library name prefixed with an underscore. That is for the openFrameworks project (which is named ‘openframeworks’ internally) the right product name for the binding is ‘_openframeworks’. This ensures the module can be loaded properly (see discussion on ‘ImportError: dynamic module does not define init function’ issue).
    2. Add adequate Library Search Paths and Header Search Paths if necessary.
    3. Change the Mach-O-Type of the target to ‘Bundle’. (This is roughly discussed in the SwigFaqMaxOSXSharedLibraries also.)
    4. A number of settings have to be changed in order to enable correct linkage with the Bundle Mach-O-Type: firstly deactive ZeroLink. Then set Bundle Loader to the Python runtime (usually ‘/usr/bin/python’). Set CurrentLibraryVersion and Compatibility Version to an empty string as it is not supported with Bundle. Activate Perform Single-Object Prelink. Finally set Executable Prefix to an empty string (erase ‘lib’) and change Executable Extension from ‘dylib’ to ‘so’.
  8. Build the newly configured target.
  9. Finished.

Testing your Python module is easy as well. Just open up a terminal and change to the build directory of the target. Then launch a python shell and type ‘import mymodulename’. Afterwards all functions / classes from the module should be available in the Python environment.

→ 9 CommentsTags:····

openFrameworks vs. Python

October 22nd, 2008 · 1 Comment · Creative Coding

If you know Processing you may have heard of openFrameworks. openFrameworks is a library for »creative coding« with regard to simplicity, performance and platform-independence. It is available in C++ featuring pre-compiled binaries and IDE projects for the major platforms (Mac OS X, Linux and Windows). However, during the work on my master’s thesis I have written and re-used a lot of Python code. Plenty of scientific (and also industry) code is readily available and easily combinable in the form of Python modules. Consequently a Python-binding for openFrameworks is very desirable for native high-performance visualization (and more) purposes.

In a thread within the openFrameworks forum I finally found a binding, which was only available for the Windows platform at that time unfortunately. Thus, I created a first version of an openFrameworks-Python-Binding for Mac OS X. The binding is available as an XCode project and is based upon the original version (introduced in the above mentioned forum thread).

I will discuss the details of what is possible with this binding and provide some examples soon.

→ 1 CommentTags:····

© 2013 Tobis Lensing. All rights reserved. Powered by Wordpress — based upon Cutline by Chris Pearson. This page reflects the personal opinion of the author and is in no way linked to institutions the author is working or has worked for. For more information, see the disclaimer.