The day was broken up in to two, we lately bound, dynamically linked our small short 15 minute snippets together to talk about our interesting hacks, for good for evil and had a real fun time.

After each snippet, the group would give it thumbs up or thumbs down. Thumbs down meaning it's evil and thumbs up meaning it's good. We generally judged by whether we would want to use this technique for an actual production system.. it's a sign of success if you get all thumbs down in my opinion :)

In the first half we saw some good hacks with prototyping, Martin kicked it off by showing how Gemstone changes the class of a session to optimize between normal execution and debugging execution.

I showed off BeforeYouLeave (all thumbs down!), a way to reduce terminal nodes in a tree hack using thisContext and many others. Some of them very humorous. Another example was the ability to return any value from a current stack frame in the Squeak debugger - we have that in VW too. This superpower is so useful it got full thumbs up.

After all thumbs down on BeforeYouLeave, I got all thumbs up on Jobs which I use for OpenGL, to control animations. The prototyping stuff shown was interesting, it paralleled my BareBehavior, IamMyOwnClass and Whatever, so I decided to skip those and talked to Adrian Kuhn about those techniques I used for him to apply to his own Prototypes work.

The second half of the day we put up our ideas on the wall and voted on them in terms of interest, since we weren't sure how much time we'd have to get through everything. Everybody is involved, engaged and having a good time. Lots of people have contributions and we've even got some stories emailed in to us and read out by Travis.

Now we're hearing about Duck R_ping which is basically ducktyping by any means necessary. It's for evil. When we have an evil talk, we dim the lights. When we have a "for good" we turn the lights back on. It adds to the atmosphere. In this case, he fakes an ActiveRecord object without having to read from the database, which can be slow.

Now it's John's turn to talk about how to get the address of an object. First he shows the "remove the first character from a string" by turning it in to a large positive integer, bit shifting it, then turning it back. That's a cute evil trick that one.

John now shows us the traditional way to get the address of an object. It's a complicated technique using another fake. You fill a slot in your object with the object you want the address for, then you can use a become: trick. You can use the same trick to find the bit pattern of numbers like 1.. which is 7 because of the two tag bits.

The new technique involves changing a literal in a method to change who your class is.. which is used to lookup super calls, which John realized meant you could reuse an existing class to fill in an instance variable. He now have a one method implementation for getting the address of an object.

With a different technique, he can catch the VM copying methods in to the code cache too, very fascinating. This way you can find out that a method is no longer in the code cache - you can also count how many times it has been put in to the code cache and thrown out again, neat if you want to see if your code is optimized or not.

Next, Travis is showing off super super, a neat tricky way to call the super method of the superclasses superclass (or further up the hierarchy). Travis destroyed his image by calling super beyond the class hierarchy, woops. So evil, it destroyed itself.

Now Travis has moved on to CachedBlockClosure, which we use for Assets, so it's a superpower, but something we actually use in the product. This technique requires changing the class of the object. We've seen this a few times today, but this time we see an interim Array object so that the shape can be changed become it is turned from BlockClosure in to CachedBlockClosure.

Next, on to Ward Cunningham's SymbolValue hack, Travis is presenting. Apparently, in Ruby, they got it wrong - the rails folks apparently did it badly.. one guys opinion (apparently it's slow, but built in to ruby 1.9, so the speed penalty is gone). ... But we love it in Smalltalk (some of us anyway).

To finish off SymbolValue, I talked about HigherOrderMessaging. Now, on to Monkey Patching, we can no longer say "No animals were verbed in this talk". Monkey Patching is basically changing methods on a class, or adding to the class.. something we Smalltalkers do all the time without batting an eyelid.. but Rubyists seem to emphasis the technique more.

A good example here is to patch Array to change [], to record who is calling array index, run tests, get the profile information. The Ruby profiler is a beautiful 55 lines of code, but it is incredibly slow... so this technique is more convenient.

Next I just talked about WriteBarriers, Martin wrote the previous write-barrier like thing, so he still needs to review it. We're thinking of putting it in the base image, but we need Martin to pontificate on it first.

Now we're on to MessageRecorder for Squeak, which can record -all- message sends, which is trickier than it sounds. It's like a full execution trace, but it also means you can replay the message sends later. It's a bit like the way Glorp does block query specifications. When you replay, you replay it on a particular target. Pretty neat really. Currently, it can only be replayed once. I suggested that he could make a parse tree instead and then he could compile too.

Now Randy Coulman is talking about Fitness in Smalltalk. James Robertson has a video of this from Smalltalk Solutions. But basically, you write your tests in wiki, reflecting off the executable environment. It's neat but i'm not sure it's for me personally.

To finish off, I presented the X86 Assembler I wrote. It got mostly up thumbs, which is fun.

Martin McClure and Travis Griggs ran the session and it was highly enjoyable, thanks guys!