I wouldn't want to be debugging that 'wired format control'!

via Royal Pingdom.

As the organiser of CocoaHeads Sydney I wanted a way to better connect Cocoa developers and employers here in Australia. The result is CocoaJobs.info - a free job post site exclusively for Cocoa and Cocoa Touch positions.

http://CocoaJobs.info/

It is available for use globally so please feel free to let any companies or recruiters know about it, as well as your own CocoaHeads chapters of course.

The first Mac I ever used was a Mac 128, when my Dad brought one home as part of the ground breaking Apple Test Drive promotion. It booted into the Finder quickly even though it used a floppy. It only ran one program at once, so programs (mostly) started and exited quickly and didn't interact. It had a fixed screen size so everyone's experience was the same. There were desk accessories that gave access to limited functionality while applications were running.

Sounds a lot like the iPad (except bigger and black and white - and of course no 3G ;).

Seriously, it's Steve Job's core vision all over again. Steve Jobs didn't want the Apple ][ to have any expandability, it was Steve Wozniak who convinced him (correctly) that computers were still very much a hobbyist device and need expandability. The original Mac wasn't supposed to have upgradeable ram - it was the engineers (Burrell Smith I think) who secretly made the circuit board easily upgradeable.

Only now, the hardware and connectivity reality has caught up with Jobs' reality: hardware is cheap, expendable and compact - and Apple makes the best. Once again another insanely great device is going to change the place computers have in our lives.

So your code crashes with an EXC_BAD_ACCESS in objc_msgSend and there is *none* of your own code in the stack trace. Bummer. Since all we know from objc_msgSend is that it's trying to call a method on an object. Since we got EXC_BAD_ACCESS you can bet your bottom dollar that it's attempting to call a method on a freed pointer, so there's no obvious way of finding out what the object was. We can, though, easily find the method. Read Greg Parker's excellent post So you crashed in objc_msgSend(). For the iPhone simulator on my Mac I need to do this at the gdb prompt to decode the eax register:

(gdb) x/s $ecx
0x980530c4:	 "release"

you can see that the selector in the second argument is "release". Now we're getting somewhere, we know an already freed object is trying to be released. Since there is none of our code in the stack trace it's a fair bet that it's happening when the autorelease pool is releasing.

There are a few tricks in your toolbox for tracking down over-released objects. There's the NSZombieEnabled, NSAutoreleaseFreedObjectCheckEnabled and other environment variables which will give you better logging rather than just crashing.

I've found this is not always reliable (logs from the above builtin debug options showed that the over-release was on an NSCFDate object, when in fact it was an NSNumber). Sometimes you also just want to trace through exactly what is happening with your retain/release/autorelease cycles. That's what we're about to achieve here.

Ok, so you have a unit test that replicates this problem right? I use the excellent GHUnit by Gabriel Handford. If not you'll have to play around a bit to narrow down your problem code. In my case, I wanted to confirm that a particular unit test was failing during the autorelease pool release. Best way is to wrap the offending code in a new autorelease pool. Then it will be freed inside your code, which you will see in the stack trace, and confirm you have found the reason. My unit test now looks like:

(Note that the code examples, embedded in github gists, are not showing up in my RSS feed. I'll fix that later, but for now please read the original post)

Now when I fail with EXC_BAD_ACCESS my stack trace looks like this:

Where line 91 of CJTestCJCard.m is the [pool release] call above. So something is being added to the autorelease pool, and is *also* being fully released, or maybe it's being added to the pool more times than it is being retained. There doesn't seem to be a way to interrogate the contents of the autorelease pool (which is a shame) but we log some really useful info by overriding a few methods, like NSObject's release and autorelease methods, so we can see when things are being added to the pool and when things are being released. This is some funky stuff, but since we're only doing it in our unit test class, not code we're going to release you can sleep soundly at night. Here's how I effected logging in release and autorelease.

Add this to the top of your unit test class, before your current @implementation:

Now in your unit test class @implementation, you can use the setupClass method to effect the method implementation switcharoo:

Now your log will be filled with log lines like:

This can help when tracking down tricky releasing bugs. Note that not all classes seem to comply. For instance I see plenty of log lines for NSCFString, but never any release lines. I assume that NSCFString release implementation is a bit different since it's a toll free bridged object - getting that to log is an exercise left for the reader!

If you're interested in the functions I used above to interact with the runtime, check out the Introduction to The Objective-C Programming Language and Objective-C Runtime Reference. Note that the code above works fine in the iPhone simulator. It should be fine on 64 bit Mac apps, but you may need to diddle the method structs manually in 32 bit Mac apps since they use the legacy Objective-C runtime (which you can read about in the Objective-C 1 Runtime Reference).

Also note it won't work on the iPhone itself, so to save constantly commenting out code, you can wrap the offending code in #if TARGET_IPHONE_SIMULATOR #endif pairs.

CocoaHeads Sydney member Duncan Campbell has just published a book with PeachPit press titled "iPhone SDK 3 Visual Quickstart Guide".

Like all of Peachpit's "Visual Quickstart Guides", the book is mostly broken into two columns - text and images. At first I thought it would suck! As soon as I got into it though, I quite liked the thin column. It has readability like a newspaper, although it did make following inline code a little tedious.

The book covered all the basics you need for making a great app, and made some tricky tasks simple - like custom cells and multi-touch.

It avoids a common approach of many intro books where they continually build into an ever evolving single app. Instead, each example is short and entirely standalone. I have to say it was refreshing - it avoided wasting time in frivolities and allowed the author to introduce concepts at the time he chose, rather than the time it was needed to continue building the app.

I also appreciated the time spent on one of the most important rools - the Xcode interface. Even I learned a handy Xcode shortcut!

The choice to use code for UI layout instead of interface builder makes the writing easier to follow, no enless 'click here, control click and drag here...' and also avoids those madenning bugs where you've missed a step but can't easily compare the compound result. Similarly, the continual tweaks to IB won't invalidate the examples.

I also appreciated how each example was standalone - building and running an interesting looking example didn't rely on carefully building examples stretching back through previous chapters.

Two extra chapters can be downloaded as PDFs from the Peachpit press website once you have the book covering the Address Book api and the Media apis. The latter is very useful - covering saved images, using the camera and playing audio and video.

While this is a book for people starting out with iPhone programming, it's not for people who have never programmed before. If you have programmed before but don't know at least the bare basics of one of C, C++, Objective-C then I would suggest completing an introduction to Objective-C first. Apple has one and there are lots of great books.

One of the positives above is that the use of code to create UI controls is repeatable, easy to error check and shows how it all works. Once you start building apps, though, you'll use Interface Builder a lot. You'll need to brush up on that after completing this book. Again, Apple has one and there are lots of great books! Aaron Hillegass's Cocoa Programming for Mac OS X will cover both Objective-C and Interface Builder really well - and you'll learn how to write MacOS X apps to boot!

So in summary, it's a great book. I enjoyed it and you hopefully will too! Available at Amazon and all good bookstores :)

I was getting the following error compiling erlang 13B02 on MacOS Leopard:

Thanks to the Google translation of a page in Japanese on javaeye.com (link) I figured out I had to rebuild wxWidgets (even though version 2.8 already seems installed in Leopard). Here's the nub of it:

• Download wxWidgets 2.8.x, untar to a directory of your choice
• cd into the un-tarred directory and make a build dir (eg. mkdir MYBUILD)
• cd into that new directory and build a static install into a destination of your choice (I put it in /opt/wxWidgets28):
  ../configure --with-opengl --enable-unicode --enable-graphics_ctx --enable-gnomeprint --disable-shared --prefix=/opt/wxWidgets28
  make
  sudo make install
  cd contrib/src/stc
  make
  sudo make install
• Now you can build OTP/Erlang properly, but make sure the new wx-config is first in your path, eg:
  PATH=/opt/wxWidgets28/bin:$PATH ./configure ....

I've reviewed "Higher Order Perl" by Mark Jason Dominus before - it's a great book for people who know Perl and want to master topics such as parsing or memoisation or who want to incorporate more functional approaches such as currying into their code.

It's worth buying, but now you can also get a free PDF thanks to the generosity of the author, Mark Jason Dominus:

http://hop.perl.plover.com/book/

Unfortunately the recent Safari 4.0.2 update doesn't seem to have fixed the cpu usage runaway with Google Apps email. Basically after some time (say 10 minutes) of having Google Apps email open, Safari 4 goes to 20% cpu usage and stays there.

It's a bug in either Google's Javascript or in Safari because the cpu utilisation is minimal in the first 10 minutes, and drops back to zero again as soon as you close the tab with Google Apps email.

I was *really* hoping that the "Nitro stabilisation" improvements would resolve that.

From reading internet threads about the error, [BUG] unknown type 0x22 (oxc given), it seems to occur when C code compiled against ruby 1.8 is loaded into ruby 1.9.

At least using the MacPorts ruby 1.9 install there is a very odd issue related to this. You get a crash, under some circumstances, when a gem loads into ruby 1.9 and the MacOS linker decides it's a good idea to link against the standard OS installed version 1.8 libruby.

What's especially odd is that the stack trace doesn't show it, but i did track it down by running lsof in a while /bin/true loop as I caused the crash:

...
ruby1.9 41978 aufflick txt REG 14,2 3148976 67264 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/libruby.1.dylib
...
ruby1.9 41978 aufflick txt REG 14,2 1906476 3915360 /opt/local/lib/libruby1.9.1.9.1.dylib
...

Now to find a way around it!

Update: I may have found the culprit. The ruby core .dylib files (the Mac equivalent of .so files) are correctly linked to the ruby1.9 library, but the thin library (installed via gem1.9) is not:

bash-3.2$ otool -L /opt/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.1/lib/thin_parser.bundle
/opt/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.1/lib/thin_parser.bundle:
/usr/local/lib/libruby.dylib (compatibility version 1.8.0, current version 1.8.6)
...

Now I can manually tweak this with install_name_tool, but the gem build process must be broken somehow...

Update 2: That wasn't the problem. I fixed the linking path in the thin_parser.bundle:

sudo install_name_tool -change /usr/local/lib/libruby.dylib /opt/local/lib/libruby1.9.dylib /opt/local/lib/ruby1.9/gems/1.9.1/gems/thin-1.2.1/lib/thin_parser.bundle

but it still crashes...

Update 3: It's something to do with the MacPorts build. I did a compile from source of runby 1.9.1 into a new prefix and ruby/rack/thin work fine. Sweet!

I prefer to use functional style programming wherever possible. In many popular dynamic languages such as Perl, Python or Ruby there is quite good support for functional programming with arrays such as Perl and Ruby's map and Python's even better list comprehensions.

With hashes (or dictionaries or whatever you call them) you're usually stuck to sequential programming. Since in Ruby hashes are objects we can inject a nice map_each method into the Hash class which will process each key value pair and the resultant list will have one result for each pair.

class Hash
  def map_each
    ret = []
    self.each do |key, val|
      ret.push yield(key, val)
    end
    ret
  end
end

In my last post (Ruby, HTML, s-expressions, lambdas?) I said I would show how we can modify the html generation to allow streaming.

Of course I was making it out to be a lot more complicated in my head than it really is - all the hard work is done already by the lambdas enforcing correct execution order. All we need to do is add a few judicious STDOUT.flush calls before anything that might take some time (ie. evaluating the tag content which could include a database lookup etc.)

I've done that in the new htm.rb below, but first, here's some demo code with some delays:

engines = [["http://google.com/", "Google"],
           ["http://yahoo.com/", "Yahoo!"],
           ["http://webcrawler.com/", "Showing my age"]]

Htm.htm(:ul, engines.map \
        { |e| Htm.htm(:li,
                      [:a, :href, e[0], [:b, lambda { sleep 3; Htm.str(e[1])}]])}).call

Notice also how we can use a lambda anywhere we can put content. Instead of a sleep, perhaps it's an external ImageMagick command. Or perhaps instead of the map iterator our loop is iterating over results being streamed from a slow database query.

Our output will look the same, but I've indicated with !!! where the output pauses for 3 seconds:

You can see that the http stream will receive all the output it possibly can while waiting for the expensive operation, and the tags are still automagically closed. Job done!

Here's the up to date htm.rb:

require 'cgi'

module Htm
  def Htm.str(content)
    lambda { print CGI.escapeHTML(content.to_s) }
  end

  def Htm._build_tag(tag, args)

    # open the tag
    print '<' + tag.to_s

    tok = args.shift

    # find any tag attribute key/value pairs
    while tok.kind_of? Symbol
      print ' ' + tok.to_s + '="' +
        CGI.escapeHTML(args.shift.to_s) + '"'
      tok = args.shift
    end

    if tok.nil?
      # self-close tag if no content
      print ' />'
    else
      # finish open tag
      print '>'

      # output tag content
      Htm._eval_content(
                        tok.kind_of?(Symbol) ? Htm.htm(tok, args) : tok )

      # close tag
      print '</' + tag.to_s + '>'
    end
  end

  def Htm._eval_content(content)
    while content.kind_of? Proc
      STDOUT.flush
      content = content.call
    end

    if content.kind_of? Array
      Htm._eval_content(Htm.htm( *content ))
    elsif ! content.nil?
      print content
    end
  end

  def Htm.htm( *args )
    lambda do

      tok = args.shift

      while ! tok.nil?
        if tok.kind_of? Symbol
          Htm._build_tag(tok, args)
        else
          Htm._eval_content(tok)
        end
        tok = args.shift
      end
    end
  end
end

I've been noodling around with various lisps lately, and one of the sources of lisp's elegance is the lack of separation between data and code. A practical example of that is the cl-who library which creates html from an s-expression representation, ensuring all tags are correctly closed. For example:

(with-html-output (*http-stream*)
  (loop for (link . title) in '(("http://zappa.com/" . "Frank Zappa")
                                ("http://marcusmiller.com/" . "Marcus Miller")
                                ("http://www.milesdavis.com/" . "Miles Davis"))
        do (htm (:a :href link
                  (:b (str title)))
                :br)))

There are a number of ways to replicate this style in other languages. You can do it by building up a big string, but I want to print to a stream like the example above. Using lambdas we can make a pretty good approximation in Ruby. Here's some Ruby code using a simple module I whipped up (see below) to achieve the same output as the cl-who lisp code above:

engines = [["http://google.com/", "Google"],
           ["http://yahoo.com/", "Yahoo!"],
           ["http://webcrawler.com/", "Showing my age"]]

Htm.htm(engines.map { |e| Htm.htm(:a, :href, e[0], [:b, Htm.str(e[1])],
                                :br, nil)}).call

Lets say we realise that the br tags are nasty and want to put the list of links into a list:

Htm.htm(:ul, engines.map \
        { |e| Htm.htm(:li,
                      [:a, :href, e[0], [:b, Htm.str(e[1])]])}).call

It's not quite as elegant as the lisp equivalent because we are mixing lambdas and arrays - both as nesting constructs. Here is the final output (indented for clarity - the Htm module below does no indenting):

<ul>
  <li><a href="http://google.com/"><b>Google</b></a></li>
  <li><a href="http://yahoo.com/"><b>Yahoo!</b></a></li>
  <li><a href="http://webcrawler.com/"><b>Showing my age</b></a></li>
</ul>

Now even though we are controlling the order of execution such that the various parts will be printed to the stream in the right order, we still can't print until we have closed our outermost tag (usually html). To be able to stream output while also auto-closing the tags we're going to need to use continuations - I'll cook up an example of that for a later blog. There's also other neat ways we can have self-closing tags that will allow streaming - I'll post about that later also.

Here is the Htm module in full:

require 'cgi'

module Htm
  def Htm.str(content)
    lambda { print CGI.escapeHTML(content.to_s) }
  end

  def Htm._build_tag(tag, args)

    # open the tag
    print '<' + tag.to_s

    tok = args.shift

    # find any tag attribute key/value pairs
    while tok.kind_of? Symbol
      print ' ' + tok.to_s + '="' +
        CGI.escapeHTML(args.shift.to_s) + '"'
      tok = args.shift
    end

    if tok.nil?
      # self-close tag if no content
      print ' />'
    else
      # finish open tag
      print '>'

      # output tag content
      Htm._eval_content(
                        tok.kind_of?(Symbol) ? Htm.htm(tok, args) : tok )

      # close tag
      print '</' + tag.to_s + '>'
    end
  end

  def Htm._eval_content(content)
    while content.kind_of? Proc
      content = content.call
    end

    if content.kind_of? Array
      Htm._eval_content(Htm.htm( *content ))
    elsif ! content.nil?
      print content
    end
  end

  def Htm.htm( *args )
    lambda do

      tok = args.shift

      while ! tok.nil?
        if tok.kind_of? Symbol
          Htm._build_tag(tok, args)
        else
          Htm._eval_content(tok)
        end
        tok = args.shift
      end
    end
  end
end

Here is the presentation I gave at last month's CocoaHeads:

Or you can download the pdf from the CocoaHeads AU Google group: apple_remote.pdf.

CocoaHeads Sydney is steaming along with our fourth monthly meeting on the trot this Thursday.

Last month at CocoaHeads Sydney I gave a lightning talk showing how to add Apple IR support to your Cocoa app. I have uploaded the slides to the files section of the google group. In the presentation I also showed how I used the LaTeX beamer class to make pdf slides, and I used the open source SplitShow application to give the presentation (using my Apple IR support of course!) You can get SplitShow from the google code project but you'll have to build from the trunk to get the IR support which has not yet been included in a release.

We also had Ben Hill show us the impressive prototype of an OpenGL iPhone game he put together using cocos2d.

This month our very own Jude Sutton will be giving us a presentation on the Authorisation Services and related APIs.

This month's details:

When: Thursday May 7th, 6:30pm
Where: UTS Broadway CB10.07.114. ie. Building 10, Level 7, Room 114
Calendar:

All details are published monthly on the CocoaHeads AU google group.

Hope to see you there!

One of the consistently popular pages on this website is my blog entry about building Umbrello on MacOS. Umbrello is the KDE UML modelling program. UML modelling programs are mostly surprisingly rubbish, so Umbrello being not rubbish is one of the better ones and it's open source to boot.

It has, though, been tough to build on MacOS even just under X11 (as witnessed by the long list of comments on my earlier blog with various configure recipies). KDE4 promises to resolve that with the native MacOS Qt support allowing Mac native applications.

The Mac KDE project has beta downloads of the (nearly) full KDE environment for Mac. All the bits you need are at http://mac.kde.org/ but note they are hosted on an ftp server that allows you to only download one file at a time, so let one finish before you start the next. No compilation or commandline trickery needed - just installing normal MacOS packages.

After installing the various bits you will find a KDE4 folder in your Applications folder. Here's Umbrello running on my Mac:

There are a few oddities - I could maximise the window, but not drag the window size to anything other than the original or the maximum, but otherwise it seems quite solid.

If this isn't the coolest thing you've ever seen in 2009 I'll eat my hat:

James Powell has featured heads up 'tunes on his iLoveMacApps.com and also has some neat feature suggestions.

I'm not sure where the slowdown he is seeing is coming from so I'll quiz him on that, but clicking the song and hiding the dock icon are good ideas.

He has a pretty eclectic playlist :)

Cubase, like Photoshop and many other seemingly professional software packages, refuse to acknowledge that software developers (who you might consider important users) often choose to install their Macs with case-sensitive file systems. Mac OS X has had case sensitive file system options since 10.0 in 2001 included UFS.

Anyhoo, to make Cubase LE work after the installer botches it's attempts, run the following in your terminal:

CUBASE="/Applications/Cubase LE 4.app"

cd "$CUBASE/Contents"
sudo mv components Components
# documentation stays lowercase
# documentation files seem missing - can get them from steinberg website anyway
# fonts must stay lowercase
sudo mkdir -p Help
sudo mv help/* Help
sudo rmdir help
sudo mv presets Presets
sudo mv scripts Scripts
sudo mv Scripts/patchnames Scripts/Patchnames
sudo mv Scripts/trackmixer Scripts/Trackmixer
sudo mv Templates templates/unknown.cpr
# templates dir stays lowercase
sudo mv vstplugins VSTPlugIns


# in case future updates have different casing:
sudo ln -s Components components
sudo ln -s documentation Documentation
sudo ln -s fonts Fonts
sudo ln -s Help help
sudo ln -s Presets presets
sudo ln -s Scripts scripts
sudo ln -s templates Templates
sudo ln -s VSTPlugIns vstplugins

Or I zipped this up in a command file you can double click if you prefer: fix_cubase_case_sensitive.command.zip.

There's a raft of new features, none cooler than the popup you get if you hover over an album cover when the window is too small to show any text. Pictured left.

Happy Matt?

The big change is that it's now designed to stay running all the time. When you pause or stop iTunes, the hut window will tastefully fade away. When iTunes fires up again, it will come back. There are a number of new options in the prefs window to support that such as adding to your login items.

Available now :)

This release adds a new preference to stick the hud display to all spaces, as per Mr Barnes request.

I also changed the framework used by the prefs window, so let me know if there are any issues or raise a bug: http://mark.aufflick.com/software/heads-up-tunes/bugs

The much awaited version 0.2 of my iTunes thingamy is now released! Version 0.1 installations should find the update automatically or go to the home page to download it yourself.

You can now resize the window yourself, so it can be skinny or wide:

You can turn off the shadow if you wish, and it now remembers it's window position between runs. And that's about it :)

No comments about my music selection please!

When I'm listening to music I like to know what tracks are queued up. Call me a control freak.

One doesn't normally have enough screen space to leave iTunes visible though, so I figured what I wanted was a heads up style panel, floating above all other applications, showing the current and upcoming songs. Something like the image on the right:

Surprisingly, no such app existed. There are many heads up controllers (which I don't need since I control tracks and level from my Apple bluetooth keyboard media function keys), or artwork viewers that display the current track only. There was no alternative but to suspend my study plan for an evening and write my own.

The result is heads up 'tunes. It's lightweight, nothing fancy (although I will add animation to it one day). You can download the current version at the software home page:

http://mark.aufflick.com/software/heads-up-tunes/

Here's the blurb from the about box:

This is a preliminary version of heads up 'tunes.

Pretty much all this program does is display the current and next two iTunes™ tracks in a "heads up" style window. It works fine with genius and party shuffle as well as manual and smart playlists. Results will be disappointing when using regular shuffle mode since it is not possible to determine what track will come next.

Please visit http://mark.aufflick.com/software/heads-up-tunes for future releases.

Please email any bug reports to mark@aufflick.com.

© Copyright 2008 Mark Aufflick. This software is free for you to use. No warranty is provided with this software except that which cannot be excluded by such disclaimers. This is free pre-release software - use at your own risk :) iTunes™ is a Trade Mark of Apple.

Oh, and it also sets its dock icon to the current track artwork. It's a Universal binary and has been tested on PPC (by me) and Intel (by Matt B and DB). Enjoy!