seandenigris.com

When compiling the VM for Xcode, one has to switch back and forth from the image to the command line. To make things easier, here’s a little script that:

1. empties the build directory
2. generates the sources and cmake info
3. Configures with cmake
4. Opens the project in Xcode

First, load PipeableOSProcess via:

Gofer it
	squeaksource: 'MetacelloRepository';
	squeaksource: 'CommandShell';
	package: 'ConfigurationOfOSProcess';
	package: 'CommandShell-Piping';
	load.
(Smalltalk at: #ConfigurationOfOSProcess) load.

Then, execute this script (also available as a gist) whenever you want a fresh Xcode project:

PipeableOSProcess waitForCommand: '/usr/bin/osascript -e "tell application \"Xcode\" to quit"'.
 
buildDir := FileDirectory on: '/Developer/cogvm/cog/build/'.
buildDir entries do: [:e | e name = 'vmVersionInfo.h' ifFalse: [ 
		e isDirectory
			ifTrue: [ e asFileDirectory recursiveDelete ]
			ifFalse: [ e delete ] ] ].
 
StackCocoaIOSConfig new
  addExternalPlugins: #( FT2Plugin );
generateForDebug;
  generateSources; generate.
 
PipeableOSProcess waitForCommand: 'cd /Developer/cogvm/cog/build/; /opt/local/bin/cmake -G Xcode'.
PipeableOSProcess waitForCommand: 'open /Developer/cogvm/cog/build/StackVM.xcodeproj'.

Apparently, gcc 4.2 is no longer installed with Xcode (as of Xcode 4.2). Unfortunately, older projects may need to be compiled with gcc. There is some scattered information online about how to get gcc 4.2 with Xcode 4.2, but they seem complex and error-prone (e.g. install Xcode 4.1, then upgrade to 4.2).

UPDATE: Here are some situations you might find yourself in:

• Upgrading from Snow Leopard to Lion – it seems that gcc et al will be moved to a different location. See here for a fix.
• Upgrading to Xcode 4.2 – gcc 4.2 should still be on your machine; you just have to tell Xcode 4.2 to list it as an option (in which case, skip to step #2 below)
• Installing Xcode 4.2 with no previous version – no gcc 4.2 at all; follow instructions below.

Here’s an easy way to get gcc 4.2 working [1]:
1) Install gcc 4.2. via Mac Ports:

sudo port install apple-gcc42

2) Tweak Xcode so that gcc 4.2 appears as a compiler option, by editing the Xcode 4.2 GCC 4.2.xcspec file to get gcc 4.2 to show in the list of compiler options:

• Open the xcspec file for editing:

sudo vi "/Developer/Library/Xcode/PrivatePlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/GCC 4.2.xcplugin/Contents/Resources/GCC 4.2.xcspec"

• Change lines 41 and 42 from this:

ShowInCompilerSelectionPopup = NO;
IsNoLongerSupported = YES;

To This:

ShowInCompilerSelectionPopup = YES;
IsNoLongerSupported = NO;

•  Link the gcc 4.2 binary to the location that Xcode expects

sudo ln -s /opt/local/bin/gcc-apple-4.2 /Developer/usr/bin/gcc-4.2
sudo ln -s /opt/local/bin/g++-apple-4.2 /Developer/usr/bin/g++-4.2

[1] Adapted from this Stack Overflow thread

The Tiobe index is total rubbish. But it’s worse than useless. It’s actually harmful. As Tyler Cowen mentioned in his TED Talk, “Be suspicious of stories”, feeling like you know what’s going on is way worse than admitting you don’t have a clue:

The most dangerous people are those that have been taught some financial literacy

Undoubtedly, there are people out there choosing careers and technologies based on the information age’s “divining by chicken bones”.  Tiobe is based on search engine hits for goodness sake. In the uber-democratic-everyone’s-a-technical-blogger web, of what is “talking about a language” a good indicator? Here is a primary one: that the language and its tools are not sufficient to support development. In other words, the Niobe Index (i.e. search engine results) is inversely proportional to language quality, as seen below:

Since the equation above is obviously scientific (because it seems “mathy” and nerdy), it must be true. Furthermore (another great smart-people word), if one believes in (yes, like Santa Claus) the Niobe index (which can only be believed because it superficially seems scientific), one must believe my equation, which creates a paradox (another great science-y term).

In a live, open, dynamic environment (like Smalltalk*), the programmer has at their fingertips most of the things they would otherwise be force to search the internet for, which is succinctly described by Torsten Bergmann. Also, working in a low level language, like C++ (e.g. manual memory management), guarantees search engine love. I used to need a Safari Books membership just to make sure I didn’t shoot myself in the foot.

Further reading:

• TIOBE or not TIOBE – “Lies, damned lies, and statistics”
• TIOBE Index is being gamed

* I am not pushing Smalltalk. In fact, I can’t wait until someone invents something better (hint, cough; VPRI).

For a while, I’ve been thinking about using MacRuby for native UIs and multiple windows in Pharo on the Mac. I uploaded a proof of concept to https://github.com/seandenigris/PharoMacRubyTest . It has a simple Cocoa UI that uses http to get a value (the current time) from a running Pharo image and displays it in a text field. See the discussion on the Pharo mailing list.

Xcode 4.1 had a bug where IB did not recognize outlets in MacRuby classes. It is corrected in Xcode 4.2. However, if you upgrade to 4.2, you must then reinstall MacRuby for MacRuby outlets to start working again.

See this StackOverflow thread for the more information.

This is just a small example, but multiply it by the number of text editing and command line operations you do in a lifetime.

After executing the following on the command line:

HandBrakeCLI -e x264 -q 20 -f mp4 -m --main-feature -i /Volumes/DVD_01 -o /path/to/DVD_01.mp4

I needed to do the same for DVD_02.

With vi bindings, I pressed [Esc], [Shift]+[f], [1], [r], [2], [;], [.], and the command was transformed into:

HandBrakeCLI -e x264 -q 20 -f mp4 -m --main-feature -i /Volumes/DVD_02 -o /path/to/DVD_02.mp4

Woot! How else would you do this? Copy and paste into a text editor? Hold down the back arrow………………..? The investment in learning vi pays off in countless small ways over a lifetime of programming.

Metacello Is Cool

Metacello is a great project that manages your Smalltalk project’s dependencies on:

1. other projects
2. Smalltalk platforms (e.g. Squeak 4.2 vs. Pharo 1.2)

Overcoming the mess that package loading has historically been (imagine trying to guess which version to use of each package of multiple interoperating projects while the platform evolves beneath you!), it lets you say the programmatic equivalent of:

Before loading my project, you must load the current stable version of the OSProcess project. Then, for my first package: if this is Pharo1.2, load version X; if Squeak 4.2, load version Y…

But We Need Tools!

Writing configurations by hand can be a drag. But fear not! Dale and Co. have created an API to facilitate your workflow. It is described in detail in the draft chapter of Pharo By Example 2. Here’s a walkthrough of my first experience using it…

Describing Project Structure

MetacelloToolBox
    createBaseline: '1.0-baseline'
    for: 'SimpleApplescript' "Project name"
    repository: 'http://squeaksource.com/SPDPlayground'
    requiredProjects: #('OSProcess')
    packages: #('CommandShell-Piping' 'SimpleApplescript')
    dependencies: {
        ('SimpleApplescript' -> #('CommandShell-Piping')).
        ('CommandShell-Piping' -> #('OSProcess')) }
    groups: { ('default' -> #('SimpleApplescript')) }.

As good Smalltalk code, it does just what it says – describes the project and its dependencies – namely, that the SimpleApplescript package depends on CommandShell-Piping, which in turn depends on OSProcess. Usually, it would not be our responsibility to describe dependencies of an external package like CommandShell-Piping, but CommandShell currently has no Metacello configuration of its own, so we step in (although creating one would be cleaner ). Here’s the method it generated:

baseline10: spec
    <version: '1.0-baseline'>
 
    spec for: #'common' do: [
        spec blessing: #'baseline'.
        spec repository: 'http://squeaksource.com/SPDPlayground'.
        spec project: 'OSProcess' with: [
            spec
                className: 'ConfigurationOfOSProcess';
                versionString: #'stable';
                repository: 'http://www.squeaksource.com/MetacelloRepository' ].
        spec
            package: 'CommandShell-Piping' with: [
                spec requires: #('OSProcess' ). ];
            package: 'SimpleApplescript' with: [
                spec requires: #('CommandShell-Piping' ). ];
            package: 'SimpleApplescript-Specifications' with: [
                spec requires: #('SimpleApplescript' ). ].
        spec group: 'default' with: #('SimpleApplescript' 'SimpleApplescript-Specifications' ). ].

Now there was one thing I was unable to specify above. Because CommandShell-Piping is an external package, we need to tell Metacello where to find it (see how quickly things get complicated without Metacello). So I added a line to the generated baseline above:

package: 'CommandShell-Piping' with: [
    spec
        repository: 'http://www.squeaksource.com/CommandShell'; "added manually"
        requires: #('OSProcess' ). ];

Version Snapshot

MetacelloToolBox
    createDevelopment: '1.0'
    for: 'SimpleApplescript'
    importFromBaseline: '1.0-baseline'
    description: 'initial development version'.

Here, we just did something amazingly cool. Metacello walked through our project’s packages and dependencies and created a version with:

• the current versions of each package
• the appropriate version of each external project (e.g. stable, bleedingEdge)

Here’s the method it generated:

version10: spec
    <version: '1.0' imports: #('1.0-baseline' )>
 
    spec for: #'common' do: [
        spec blessing: #'release'.
        spec description: 'initial development version'.
        spec author: 'SeanDeNigris'.
        spec timestamp: '12/6/2011 10:38'.
        spec project: 'OSProcess' with: #'stable'.
        spec
            package: 'CommandShell-Piping' with: 'CommandShell-Piping-dtl.10';
            package: 'SimpleApplescript' with: 'SimpleApplescript-SeanDeNigris.1'. ].

Validation

PBE2 advises us to validate our configurations after editing. It’s easy to do, just printIt the following, which will return a collection of problems, if any:

MetacelloToolBox validateConfiguration: ConfigurationOfSimpleApplescript.

A configuration is Born

Now we have a functioning configuration. We will commit it so we can start testing it on the different platforms we support:

Gofer new
    url: 'http://squeaksource.com/SPDPlayground';
    package: 'ConfigurationOfSimpleApplescript';
    commit: 'Initial version of configuration'.

Release into the Wild

Once we are satisfied that our configuration is correct for all supported platforms (beyond the scope of this post, see the PBE2 draft chapter), we promote our current development version (the one we created a few steps ago) to released status:

MetacelloToolBox
    releaseDevelopmentVersionIn: ConfigurationOfSimpleApplescript
    description: '- release version 1.0'. "this will be the commit comment"

Sharing

So the community can easily find our configuration, we copy it to http://www.squeaksource.com/MetacelloRepository (note that this location may change in the future as the community is rapidly evolving best practices for Metacello):

MetacelloToolBox
    copyConfiguration: ConfigurationOfSimpleApplescript
    to: 'http://www.squeaksource.com/MetacelloRepository'.

Conclusion

Metacello solved a great need in the Squeak/Pharo ecosystem, and its tool support is making it easy and fun to use.

Here’s a github gist of the code above that you can customize to create your own configuration. Have fun!

I’m still experimenting, but so far I found two strategies:

• Enable Folder Actions and attach a script to the folder in ~/Library/Mail/ which hold the inbox’s messages
• Create a rule general enough to reply to all messages (e.g. account = my_email_account)

The rule approach seems to fire a bit quicker than the Folder Actions, so I’m going with that for the moment.

In an enlightening blog post, Ramon Leon explains that most applications are designed for small businesses with small amounts of data. Therefore most applications will never have to scale (i.e. become the next Twitter), so a relational database is overkill. However, persisting by simply saving the image is slow and error-prone.

Based on these ideas, he suggests a simple (one class) framework which saves only your model. The idea is to use it as long as you can get away with, which may be forever.

I packaged the code from the post, added a few tests, and put it on SqueakSource as SimplePersistence.

It’s really easy to give your application persistence (see SPFileDatabase’s class comment). The three steps are:

1. Subclass SPFileDatabase
2. On the class-sode of the subclass, implement
   • #repositories – returns a collection of objects to be saved
   • #restoreRepositories: – gets passed back the collection.

That’s it! Now, whenever you want to save, call class>>saveRepository or class>>takeSnapshot (background save).

I’ve been playing with an Objective-C Bridge in Squeak and Pharo. Now I can do cool Cocoa things in-image! For example, sometimes I need a Mac app’s bundle identifier. I previously used a Ruby script. There are a few options, but the easiest is MacRuby:

#!/usr/local/bin/macruby
 
p NSBundle.bundleWithPath('/Applications/Mail.app').bundleIdentifier

Now, I can do it in Smalltalk, although it’s a little wordy:

bundle := ObjectiveCObject findClassName: 'NSBundle'.
aBundle := bundle bundleWithPath: '/Applications/Mail.app' asNSStringUTF8.

There were two things annoying me about the above code:

1. Object create – wow, a lot more complicated than MacRuby!
2. #asNSStringUTF8 – I was certain that this could be done automatically by the bridge, and in fact, the above code has a memory leak, because the NSString must be released.

The first one, I did something about. I wrote a simple little class called ObjC to use like a namespace for ObjC classes. The above Smalltalk code becomes:

ObjC NSBundle bundleWithPath: '/Applications/Mail.app' asNSStringUTF8.

Okay, we’re getting better… Currently not a part of the bridge, the changeset for the class is available here. I’m still working on the NSString issue, so standby…