If you’ve got a weird graphics corruption problem when you try to play Frozen Bubble on Mac OS X that looks like this:

Try downloading my patched version of Frozen Bubble which fixes the problem.

Note to hackers: the patch to fix the problem is pretty trivial …

diff -Nru Frozen-Bubble (Original).app/Contents/Resources/__main__.pl Frozen-Bubble.app/Contents/Resources/__main__.pl
--- Frozen-Bubble (Original).app/Contents/Resources/__main__.pl	Thu Jan  1 06:12:48 2004
+++ Frozen-Bubble.app/Contents/Resources/__main__.pl	Sun Nov 28 23:00:13 2004
@@ -1679,12 +1679,8 @@
 	generate_new_bubble($PLAYERS[1], $next_bubble{$PLAYERS[0]}->{img});
     }
 
-    if ($graphics_level == 1) {
-	$background->blit($apprects{main}, $app, $apprects{main});
-	$app->flip;
-    } else {
-	fb_c_stuff::effect($app->{-surface}, $background->display_format->{-surface});
-    }
+    $background->blit($apprects{main}, $app, $apprects{main});
+    $app->flip;
 
     $display_on_app_disabled = 0;
 

I have no idea why the fb_c_stuff::effect there is screwing things up so badly; I suspect it’s either a problem with SDL for Mac OS X, or Frozen Bubble’s fb_c_stuff.xs Perl/C code. Furthermore, it only doesn’t work on some Macs I’ve tried (my 1GHz TiBook/Radeon Mobility 9000, and Michelle’s 800MHz iBook G4). Some Macs work OK, some Macs don’t. With the patch, all Macs work OK. Beats me completely. I’ve emailed the Frozen Bubble for Mac OS X maintainer to see if he can dig around a bit to find out why it’s causing such a ruckus …

Update: The official Mac OS X port has now properly fixed the graphics corruption bug as of version 1.0.0e, so this patch is now redundant. Go grab the new version!

Oliver Steele writes an excellent article on language mavens vs tool mavens, or: do you use Emacs/Vim+insert obscure language of your choice here vs do you use a mainstream language such as C#/Java with an excellent supporting IDE, such as Visual Studio or Eclipse? (Or maybe you use a mainstream language without any sort of IDE, in which case you’re doing yourself a great disservice.) Two quotes I liked from the article:

Why canít one be a language maven and a tool maven? Itís hard. One reason is that developers have limited time, especially for learning new skills. You can use any given block of time to master language features, or to master development tools … in fact, the most powerful languages may initially have the least powerful tool support. The reason for this is that the language developer, like the language adopter, has to make a choice: whether to dedicate limited development resources towards language features, or towards tool support.

Kudos to the Lambda community for finding the article.

Patrick Logan writes an insightful blog entry about problems with ‘rigid’ languages:

I am not sure why Python is changing or needs to. But the core language is more limited than Lisp or Smalltalk in the sense that it is “C”-like and distinguishes significantly between function calls, operators, and control structures … A more uniform language would not have as many of these backward-compatibility issues. This is the main issue I have with Python… it’s syntax is OK, but not great for extension.

This is also one issue that I have with Haskell (its syntax and semantics aren’t quite malleable enough for some embedding of domain-specific languages), but I’ll save that rant for a rainy day.

If you’re seeing the above error on Mac OS X, see pdm’s Mac OS X hint for the quick fix. For a more thorough explanation, check out John Bellardo’s page about the fork and vfork problem in Darwin. John’s page also has a neat kernel extension that somewhat fixes the bug, but it didn’t work for me with Panther (10.3.5), and I was after a really simple fix.

Update: If you’re running Mac OS X 10.4 Tiger, there’s a much easier solution that involves (you guessed it) editing a launchd configuration file.