andymatuschak.org: archive

You are at the archive for the October, 2007

Something Corporate ringtonesJacks Mannequin ringtones

RubyCocoa Shininess in Leopard

Wow, maybe Apple agrees with my sentiments after all. Check out /Developer/Examples/Ruby/RubyCocoa— there’s 40 examples there! Many of the classic examples have been recreated in Ruby, including Stickies and DotView. There are RubyCocoa examples for KVC, KVO, OpenGL, Address Book, Core Data, Core Image, ImageKit, QTKit, PDFKit, and Spotlight.

In other RubyCocoa news, Apple has opened up a new area on Ruby integration at MacOS Forge. Make sure you check out what’s new in Leopard. Interesting tidbits:

  • Most of RubyCocoa was rewritten by Apple. This explains why it’s a lot more solid.
  • Xcode has better Ruby auto-completion, driven by BridgeSupport, a new technology.
  • Interface Builder works correctly with Ruby for outlets and actions.
  • Scripting Bridge works in RubyCocoa.
  • Ruby has DTrace probes, so it works with Instruments!

There’s also now the Ruby and Python Programming Topics in the reference library, including a nice tutorial for RubyCocoa.

These are huge steps forward. My only real wants now are a graphical debugger (I’ll write the bridge to rdb myself, Apple, just open up the interface!) and integrated documentation. I have high hopes.

Learning a Thing or Two from Ruby

So I was sitting in a lounge full of freshmen, typing furiously, when suddenly I shouted with glee:

“My network! It neurals!”

The network converges! Ignore the typo in the second title.

My task, and I had to accept it:

I’m taking this course called “Learning Systems,” which teaches things like neural networks, genetic algorithms, and other buzzword-sounding devices. Our first assignment went along the lines of:

“Design and implement a neural network that learns through gradient descent on its error function. We give you a bunch of training data; you give us a function that generates outputs for all inputs with an error of less than 10-3 and has low probability of being a local minima. You’ve got one week—go.”

That wouldn’t be so bad, except that this is only one of my five classes, and I like sleeping. Eep.

Traitor!

So I need to do this fast. You might think that as a zealous Cocoa programmer, I started up Xcode and started writing a bunch of @interface declarations. Nay, I say!

This summer, I wrote my research project with Ruby on Rails; this gave me a huge appreciation for that spunky little language. Much as I like Cocoa, I’ve found that since I’ve returned to Objective-C this fall, there’s a whole lot I miss in Ruby.

continued…

SparkleCaster lives! And a status report.

Exciting news: Adam Radestock has taken up the gauntlet for SparkleCaster and has a preliminary version available! You can get more information and download it here.

Status report!

Meanwhile, I’ve frankly gotten nothing done on Sparkle since classes began again. Schoolwork eats all time, and even when it doesn’t, it eats all energy. On the bright side, my course in discrete mathematics is coming in handy for the new branching system based on posets. I have a nice algorithm in mind for solving some special case releases.

One particularly mean test case I’ve been considering is that of Dave Watanabe’s Inquisitor. The path from 1.x to 2.0 was a paid upgrade, but 3.0 was free for everyone. Obviously, users of 1.x shouldn’t be prompted to pay for the upgrade to 2.0 before getting 3.0 for free. That’s tricky.

In another tricky case, imagine a developer who is preparing for a 2.0 launch. They give out 2.0 beta builds to a small group of testers and provide upgrades to those beta versions via Sparkle. The users in the main branch never see these updates because they’re not connected to this branch. But when 2.0 final comes out, the developer wants to give his testers a free upgrade as a way of saying thank you. The normal 1.x users, however, are expected to pay. Tricky. I think I’ve got it, though.

The other guys

Software update is a trickier thing than it should be. It’s a silly, small, tiny problem that really shouldn’t be occupying this much time or attention. But if you think I’m sweating the details, you should see Apple’s implementation.

They download and execute Javascript files like this one for each update available; the scripts provide functions the software update client can call to determine whether the update should be displayed and how it should be installed. If you ever wondered why the “checking for updates…” progress bar took so long, that’s why.

On another interesting note, it seems that the software update client can be configured to use another server’s URL. Like maybe localhost. Intriguing. A tiny webserver could be run on users’ machines to serve update catalogs to localhost, thereby providing a unified update interface for Apple’s updates and 3rd-party updates alike. I’ll have to investigate this further.

If you're looking for something specific then give the search form below a try:

RSS Wordpress Grady (theme) Valid XHTML Return to the Top ↑