Smalltalk and my misinterpretations of life

We've reached an important milestone with Seaside 2.9 in VisualWorks 7.7 - all the tests pass!

We'll start integrating versions in to the development builds of VW7.7 soon.

Today I had a chat with someone about Terminator: Salvation. It got me thinking about what kind of Terminator movie I would make. Terminator was never about the war, it was about trying to dodge the future. The first movie involved Skynet sending a machine back to kill its perceived enemy, John Connor.. but the story wasn't about John Connor at all, it was about Sarah Connor.

The second movie was about John Connor because apparently he's still enough of a threat that Skynet needs to try again. The window for sending machines back must be closing right? Whatever Skynet is doing, it is doing it wrong because Connor is not only able to send back someone to stop the machines but also knows what the machines were after too.

So let's get back to the roots of the story.. battling against insurmountable odds. What's say we have Skynet try to pull a fast one - send a copy of itself back in time to give it foreknowledge of all the battles to come. We know paradoxes are okay in the Terminator universe, because of who John's father is.

So Skynet sends back a machine to go and upgrade Skynet before the battles even begin.. Connor sends someone after the machine. Now, this is a person who comes from an era where they have basically won the war. Yes, machines are tough, but they know how to beat them. They also know almost as much about Skynet as Skynet knows about itself. So now we have a machine being terminated by a human. I'd find that twist to be very interesting and enjoyable.

Of course, the machine will eventually kill the human and if you want to keep the series going, you leave it with the status quo.. however, I wouldn't. I would give Skynet the upgrade and I'd have Connor's man successfully stop Judgement day. But stopping the nukes from flying most certainly won't stop the rise of the machines....

There are almost a dozen ObjectiveC interfaces floating around for VisualWorks right now. It's pretty silly to have so many. They seem to range from raw runtime interfaces to full on class building ObjectiveC-connect type beasts. Which approach is best? we don't know really, people will have differing requirements.

John Sarkela has been busy making native print dialogs for MacOSX in VisualWorks 7.7 and as part of that, we need a nice answer to talking to ObjectiveC. So the problem of "which approach" rears its ugly head once more. A group of us had a round table (over skype) about this and decided that we should having the complete ObjectiveC Runtime interface available for developers in the base image. Anything beyond that we deem "ObjectiveCConnect" and is open to discussion and debate as to its actual implementation.

I was given the dubious honor of implementing the ObjectiveC Runtime interfaces for version 1.0 and 2.0. This work is on-going but I've been invested in this ObjC problem for a few years now so I've spent the weekend working on it.

As well as that, I have revisited my previous attempts at an "ObjectiveCConnect" and have merged them together. Here are some of the unique properties each ObjC Connect brings to the table and which ones I chose to go with are bolded:

• Fast interfacing
• Native Smalltalk classes reifying ObjectiveC classes
• Lightweight Smalltalk classes reifying ObjectiveC classes
• Extensive Refactoring Browser intergration
• DoesNotUnderstand proxy pattern for message dispatching
• ExternalInterface methods for message dispatching
• Support for Float and Struct return values
• Support for Callbacks
• Use of the Runtime Type Encoding for interfacing
• Root.ObjectiveC namespace for class lookup

There are probably more tricks that people have used that I'm not mentioning here. So after two days of feverish programming (literally, I have a flu right now), I have two layers: The Runtime layer and an ObjectiveCConnect layer.

I decided to put it to good use. First off, I ported the OpenGL-MacOSX interface to use it. Success, not a hiccup in sight. Next I decided to revisit the classic "Why don't you guys use native MacOSX menus" challenge. I've seen this done in no less than three of the ObjC variations and now I can present the fourth, hastily hacked together with one or two amusing bugs that would need to be sorted out before I shipped it:

I saw the new Terminator flick today. It was a fun romp, definitely held true to the original Terminator movie.. the soundtrack was a bit poor though (the same thing was true of Star Trek).

Now for the plot holes.. Star Trek had a lot of plot holes too. Who do they hire to write these plot holes? they're overpaid.

Here's my take on how the movie should have gone:

John Connor and his team unearth a lost Cyberdyne project - The Marcus project. They accidently wake him up from suspended animation and the movie continues as per normal. Once Connor and Marcus finally reconcile, Marcus discovers that he is indeed a part of skynet.

Here's the twist - Skynet doesn't know about his existance. He was a Cyberdyne project back before Skynet came online and had laid dormant since then. He's a backdoor in to skynet's network, which allows Connor and the rest of the scooby gang to get inside and save Kyle Reese and deal Skynet a serious San Francisco blow.

The final battle happens when Skynet realizes it has been hacked by a living breathing cybernetic human being, gets pissed and unleashes it's as-yet-uncompleted T-1000 Governator to destroy Marcus. Connor is able to rescue the human prisoners before Skynet kills Marcus and the San Fran defences come back online and start mowing down the helicopters.. then Connor flicks the switch and San Fran goes byebye.

There we go, much tighter plot story, more interesting, easier to write, fewer plot holes if I do say so myself and probably an even better movie - one I would have walked away from going "Whoa, that was awesome" instead of how I'm currently feeling, which is more along the lines of "Too bad Christian Bale yelled at that guy, I really don't like him that much anymore... the movie was okay though."

Today is Towel Day, for all of you who are the uninitiated in to the wonderful story of The Hitchhikers Guide to the Galaxy.. go get yourself a copy of the guide as soon as you can - and, don't panic.

I grew up with the hitch hikers guide to the galaxy. It helped me love books and I will always forever love Douglas Adams for that. Thank you DNA. PS: Dirk's sofa is still stuck in his stairwell.

"A towel has immense psychological value. For some reason, if a strag (strag: non-hitch hiker) discovers that a hitch hiker has his towel with him, he will automatically assume that he is also in possession of a toothbrush, face flannel, soap, tin of biscuits, flask, compass, map, ball of string, gnat spray, wet weather gear, space suit etc., etc. Furthermore, the strag will then happily lend the hitch hiker any of these or a dozen other items that the hitch hiker might accidentally have "lost". What the strag will think is that any man who can hitch the length and breadth of the galaxy, rough it, slum it, struggle against terrible odds, win through, and still knows where his towel is is clearly a man to be reckoned with."

As a continuation from my previous post on Monticello loading/merging/importing, we now have the ability to publish the Monticello .mcz files to contribute code back to the Squeak community as well.

You can load this up from public store as the Monticello bundle version 7.7 - 35. We do not include the fileIn like Squeak does, that seems to be fairly antiquated a technique anyway, so hopefully that won't cause any body any trouble - if it does, we'll just add that in too.

Watch this video to see the publishing in action, applying changes to a Seaside package and importing it in to Squeak.

My colleague Jerry Kott, who works on WebVelocity, has made an interesting example application that will come with the product. It's a photo catalog - the database stores your photos, thumbnails, albums and occasions. The application itself uses lots of scriptaculous drag and drop to make it super easy to use.

Watch the video to see for yourself. I think it's pretty neat!.

(Updated the video to be hinted, so it plays as it loads)

With Seaside 2.9, there are several package inter-dependencies that didn't exist in Seaside 2.8. The technique we used for importing the Seaside code just doesn't work so well - especially not with the speed that the Seaside team fixes bugs. We need the ability to merge individual Monticello packages in to our image without having to unload everything.

As a result, we now have better (read only) support for working with Monticello http repositories.

Watch the video to see how it works.

(The Monticello bundle in Public Store is what you want to load)