allocinit

Seems like I’m keeping up my tradition of reporting bugs for Report-an-Apple-bug Friday late. Not to worry though, I did have a bug to report, even if it is obscure and mostly totally inconsequential.

Shark seems to not record your hardware profile correctly when making a profile if you’ve got more than 2GB RAM. In this case it seems to cap the RAM read out at 2GB. Not an exciting bug, and mostly totally inconsequential, but a bug nonetheless.

For the record its Radar Bug ID is 4235050.

Dan Wood had an awesome idea for Report-an-Apple-bug Friday. Last Friday was the second Report-an-Apple-bug Friday, so it seemed fitting that I had filed this bug over the weekend.

My bug relates to a small problem I found — a 100% reproducible kernel panic. The panic code is actually the same code Graham and I developed for the Mac OS X Experts Challenge. While Apple fixed the panic caused by panpipes, it turns out that our code triggered another related bug, but not the same bug, which also results in a kernel panic.

Here’s the backtrace (from 10.4.2) for anyone who feels like working out where the bug is by themself:

#0  0x0026d9e4 in threadsignal ()
#1  0x002a529c in catch_exception_raise ()
#2  0x00043340 in exc_server_routine ()
#3  0x0004326c in exc_server ()
#4  0x002a5110 in macx_swapinfo ()

It’s fairly simple (threadsignal isn’t all that long), and follows on from the theme of the panic Amit used in the Mac OS X Expert’s Challenge. It should be fairly easy to work out what the trouble here is with reference to panpipes.

For the record, the Radar ID is 4225451.

I’ve got an idea for my bug for this Friday, so let’s see if we can carry on without Dan for a week, we’d all hate to let him down.

Back at the Mac OS X 10.2 Jaguar launch event here I won a copy of Storm Music Studio. At the time the copy I won was version 1.5, but I got a free upgrade to 2.0 (thanks Arturia!). I’m not particularly musical so I don’t use it all that often, but I do enjoy having a play now and then.

Recently I went to fire it up to have a bit of a play but after it launched it displayed a nasty dialog box informing me that the sound device was in use: not much good for a music application. No amount of clicking on the settings to choose the sound device would help, so what was I to do?

As this was the first time I’d launched Storm under Mac OS X 10.4 Tiger, and knowing that Storm is written in Java I thought there might be a chance I could fix this problem. It seemed that some change in Apple’s JVM in Mac OS X had caused Storm to get somewhat confused about my audio devices. There was no update available from Arturia that might fix the issue, or any documentation that I could find on it. Clearly I was in this alone.

A few months ago around the release of Storm 3, I had downloaded the demo to see what was different. I never actually got around to installing the demo, but there it was sitting in my downloads folder just waiting to be installed. After extracting and installing the Storm 3 demo, I checked that it did indeed work with Tiger. There were no problems to be seen. Looking at the about box of the two applications I noticed that Storm 3 was using Java 1.4.2, while Storm 2 was using Java 1.3.1. The obvious thing to do was to try and get Storm 2.0 to use Java 1.4.2 and see what happened.

To do this, I cracked open Storm 2’s application (Show Package Contents from the contextual menu) and edited its Info.plist file to add the following section:

<key>Java</key>
<dict>
    <key>ClassPath</key>
    <array>
        <string>$JAVAROOT/classes.jar</string>
        <string>$JAVAROOT/look.jar</string>
        <string>$JAVAROOT/shlook.jar</string>
    </array>
    <key>JVMVersion</key>
    <string>1.4+</string>
    <key>MainClass</key>
    <string>storm.application.Application</string>
</dict>

Success! After this quick modification Storm 2 launched without complaint and was ready to go making music as always.

As an aside, there’s something interesting going on here though. I went to revert Storm 2.0 back to it’s broken state so I could get a screenshot of the error message to place above but even after removing the Java section, Storm continued to work correctly. Weird, but at least I’ve got it back now.

Whew! It’s been far too long, but Proteus 4.12 has finally been released. The release notes are too long to put here (and I can’t be bothered copying and pasting them over), so head to the site to see what’s new.

From randomoracle.com:

There’s much bad press around about the Finder under Mac OS X. Probably the most common complaints about the Finder are in relation to either:

• networking, or
• previews, usually those in column views

The question many people ask is simply “Why is still still like this in Mac OS X today?”. This is, on the surface, a perfectly sensible question. After all, clearly Apple already knows about the problems: they use the Finder too, and plenty of people have complained about it over time. So what’s going on? Why hasn’t Apple fixed all this yet? Read the rest of this entry »

Mostly just a reminder for myself. A useful article provided by Apple: Mac OS X 10.4: How to prevent .DS_Store file creation over network connections.

Could be useful for those on a network with annoying Windows administrators who have to complain about something, and Macs dropping off .DS_Store files is as good a reason as any.

So drunkenbatman has posted another enthralling interview, this time with Wil Shipley of Delicious Monster. As always it’s an amazing read, so if you haven’t read it, grab a drink (alcoholic of course) and settle down for a nice long read.

Wil’s thoughts on heuristic algorithms are quite interesting. Throughout my degree (and indeed most formal education from what I can tell) much focus has been on provably correct algorithms and provably correct code. Apart from proving algorithms mathematically being boring as hell, in most cases relating to desktop computing the code is simply either too large to prove, or can’t be proved because of the amount of other code is interacts with.

That this sort of proof is a dead end in computer science mirrors what I’ve thought on this for quite a while (of course having to do it for a Uni course tends to increase this feeling). On the other hand, I can certainly see where this sort of proof is relevant — embedded systems involved in medical treatments or nuclear power plants for example. For me at least, this just isn’t what I’m working with.

Perhaps the most interesting decisions that come from this sort of idea is considering what parts of an application should be implemented using this style of programming, and what parts really need to be implemented in a provably correct style (maybe not mathematically provable, because that’ll put you to sleep, but at least logically provable). This decision can make a huge difference to how parts of a program can be implemented, but clearly the concept can’t apply to all parts of most programs, but it is certainly something interesting to keep in mind.

Ultimately, this is a way of providing better feedback to the user to allow them to do what they want, without feeling that they need to fight the computer, clearly something that every application should aspire to.

Well I finally got bored enough to create a blog. Who knows what’ll end up here but I’m sure there will be some things of some sort of interest here. Eventually.