Sometimes you run programs in xterm windows that try and do you a favour, by setting the xterm title property. Potentially useful enough, but aggravatingly some of them don't restore the previous title when they exit. If you're using some scheme of your own to set meaningful window titles, this is annoying.
Here's a shell one liner that you can use to grab the current title in an xterm. You could use this to write a wrapper script that gracefully launches any such rude application, and restores the rightful title property when it's done
Another kind of iteration you often want to do when constructing programs, is to count things. Quartz composer provides the counter patch, which increments a running total when one of it's inputs switches from false to true. Similarly, it decrements the total whenever the signal to it's other input changes from false to true.
By generating a regular true/false alternating value, and connecting this up to the increment line, you could generate a regular count. This composition demonstrates one way to do this. Using the Patch Time patch, a count of time in seconds is passed through a modulo 2 operator to generate a regular sequence of alternate 1s and 0s. This is connected up to the increment line of the counter, which then counts upward in integers.
The counter value is used to govern the stripe width of a vertical stripe pattern. As the patch runs, the stripe width increases every other second. This is a very simple display, but the bit generator and accumulator demonstrated are useful in a variety of ways. You can download a copy of this patch here .
Quartz composer is a visual programming tool from Apple that ships as part of the Developer tools with Mac OS X 10.4 or later. It presents a visual object-oriented programming metaphor around Quartz and Core Graphics that allows you to simply compose graphical effects by connecting inputs and outputs of different objects together, graphically.
You can use QC to build pipelines that respond to a variety of inputs, local or via peripheral interfaces to construct visualisers for a variety of source signals, such as MIDI, audio from the built in mic, video signals from an iSight camera, or even networked events from computers on your internet or LAN. It also can be used to procedurally generate graphics, which you can use to build fancy displays or screen savers. Some of the system screen savers that ship with OS X, like the 'word of the day' or the 'rss visualiser', are actually simple Quartz Composer scripts.
It's an impressive tool, and ships with documentation and some examples of what you can do. You can achieve nice effects quite quickly, but there is still a learning curve to climb. As an example, a common thing you might want to do when constructing simple animating displays, is loop over a set of possible outcomes. Iterators are a common piece of the vocabulary of programming languages, but it took me a little while to figure out how to achieve this with the 'box and string' interface of this tool.
Here is a simplistic solution solution I came up with. This sample patch demonstrates cycling over a fixed set by rendering live video from an iSight onto the surfaces of a 3d spinning cube, applying a cycle of realtime video filter effects to the image.
You can follow the patch from left to right. The brains of the procedure is the multiplexer , which is a patch that selects one out of a set of possible numbered inputs, depending on the value fed into it's Source Index field. In order to generate a periodic iteration over the right integers, I'm employing a linear interpolator, with a range of 0 - 3 , over a duration of 20 seconds. Because this is generating floats, I'm plugging it through a Round patch, that grossly rounds it to the nearest integer, before feeding it to the multiplexer. To get an even rounded cycle, tweak the interpolater range down a step, -0.5 to 2.5. The rest of the sequence is simple - the video input is split through three filters, one of these paths is selected via the looping mechanism, and that output is connected to the Image property of the built-in cube patch.
Here is the 7.1Kb .qtz file . It's not a terribly pretty end result, but it is quite impressive considering that it's such a tiny source file. The looping construct it illustrates is very simple, but could be used to build up any sort of repeated cycle over a set of different input paths, such as image files, or colour tones that you could connect to other patches to build cyclic displays.
XCode has a nifty integrated debugger which is really a pretty wrapper around gdb . It lets you point and click, and drill down on things within the gui with ease, but still preserves access to the underlying raw gdb console and output. You can create breakpoints and watches, both literal and dynamic, step through your application as it runs, all the usual stuff.
I'm not the world's greatest user of debuggers. I'm more likely to trace through things until they make sense using some combination of logging, print statements, paper and pencil, or my absolute favourite, just explaining your mystery problem out loud to a nearby third party, embarrassing yourself by spotting the obvious bug mid-flow. That last one sometimes even works with the dog. Sometimes though, you're stumped, and you want to set some watchpoints, step through your program as it executes, or just generally prod things mid-run, and poke around under digital rocks.
Something I've been trying to practice recently is Test Driven Development . XCode 3 ships with support for the OCUnit testing framework built in. You can add a Testing target to your XCode project, and build up test case classes that use this framework, and the build tools know how to run these through the test harness. And so you progress, write a test for a feature, run the test harness, write code to pass the test harness, repeat. It's a great way of not only catching certain classes of bug before they happen, but perhaps more interestingly imposing a more minimal design focus on your application as you build it; you're automatically casting yourself more in the mind of a consumer of your application services, something I find really helps avoid over-design.
At some point though you are likely to run into some kind of hard to understand failure case within a unit test, and find yourself reaching for the debugger. And then finding that the debugger doesn't work. This is because the runtime of your unit testing target is actually the separate test harness framework, and not your application target. The test harness is a regular application that's dynamically loading your test classes and running them. In order to be able to use the IDE to debug your unit tests, you just need to do a little extra configuration within your XCode project, as follows.
The tool that runs the tests is called otest . You need to add this to your XCode Unit Test target as the executable. You can do this with the command ' New Custom Executable ' in the Project menu. Add /Developer/Tools/otest .
Once it is added, set it as the active executable for the Unit Testing target, using Set active executable , in the Project menu. A green tick badge appears over the active exectuable in the xcode source list.
The otest tool expects to be run with a certain environment, and arguments. There's a man page that describes them. You could run gdb against the otest executable from a shell in this fashion, but it means switching away from XCode. Alternatively, you can set up XCode to provide these when it runs your target by double clicking the otest executable in the source list to bring up it's inspector. The runtime settings you need to set are all on the Arguments tab.
Add two arguments -SenTest Self and the name of your Unit test bundle, which will be the name of the Unit Test target with a '.octest' suffix e.g. "My Unit Tests.octest" . The quotes are important, if you have whitespace in your bundle name. Make sure that the order in the inspector list has '-SenTest Self' as the first element, and the bundle name the second, so that when they are concatenated to a command line, the switches come before the bundle name.
You also need to set two environment variables, in the lower pane of the arguments inspector, so that the dynamic linker can resolve your test components. The lower pane of the Arguments tab covers variables. Add two items to this list, DYLDLIBRARYPATH and DYLDFRAMEWORKPATH . Set both of these to be $(BUILTPRODUCTSDIR) which is the variable xcode build will populate with the correct destination of your compiled test cases object code.
With all of this set, you can just use the debugger within XCode. Click to set break points within the editor as you write your test cases, and the debugger will spring into action appropriately, whenever you build and run the test target.
