After upgrading to Mountain Lion, the following all seemed to be broken:
- MacPorts… Issuing a selfupdate command produced:
checking whether the C compiler works... no
configure: error: in '/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base':
configure: error: C compiler cannot create executables
error: There is no SDK with the name or path '/Developer/SDKs/MacOSX10.8.sdk'
The solution to these problems were fairly simple:
A few minutes later, I was back in business compiling the Pharo Smalltalk VM!
Apple’s “free upgrade to Mountain Lion” for MBP retina purchasers, announced without qualifications at the WWDC, has a 30 expiration from time of purchase.
Sounds reasonable… except that they never put that anywhere in writing when you make your purchase… oh, and that Apple’s recent OSes have been notoriously unstable at their release… oh, and that my $3000+ laptop was freezing (i.e. worse than kernel panic, no feedback whatsoever) several times daily, and I didn’t want to complicate debugging by upgrading the OS while I was diagnosing the problem.
When you add all this up, it lead me to wait until 10.8.1 to upgrade, at which time Apple support told me that they thought the best course of action would be to screw me out of the $19 for Mountain Lion, even though I had just spent more than $3000 and they had made a public promise to give it to me for free.
So they sent me a survey with the following question:
Is there anything that the Advisor could have done better to resolve the issue during the call?
and my answer:
At issue is the standard support response at mega corporations, which is that everyone you speak to doesn’t have the authority to do the right thing, even if both sides agree on what that is. Of course the follow-up is that there is someone who does have that authority, but there’s no way to actually talk to them (in this case there was an email address to which I could send a message). So, probably the only thing “that the Advisor could have done better to resolve the issue” would be to quit their job at Apple and start a small computer company in their garage, from which I could buy computers, and receive reasonable support decisions because responsibility is not diffused among countless executives, directors, and other bureaucrats. Although, that somehow sounds familiar – oh right, that’s what Apple used to be – so until the culture evolves beyond the evil economics of Milton Friedman (i.e. profit at any cost), there’s probably nothing they can do. Also, it’d be hard to do all that “during the call” because I don’t like waiting on hold and had already been transferred four times
Mark Watson wrote a nice blog post about his appreciation for Pharo and its progress.
I was inspired to comment on my own experience of Pharo as we move toward 2.0:
Thanks for the shout, Mark! Given how much you’ve enjoyed Pharo so far, I think you’ll be really impressed after the 2.0 release – I’m sure it will be a game-changer.
Much of the work the past few years has been in improving Pharo under the hood, like the new compiler, class builder, vector graphics, keyboard shortcut framework, and countless cleanups. This has been coupled with great leaps in infrastructure, like the CI server testing many variants of Pharo and its VM on Mac, Window, and Linux with every commit.
Now, all these investments are starting to payoff for Pharo users:
- Continuous integration has given us the confidence to replace the uggggly File library with FileSystem, a beautiful object-oriented library which is a joy to work with.
- Nautilus, the new browser, has long-awaited features like a history and custom groups.
- I’ve been playing around today with Vim bindings for Pharo tools, made easy by Keymapping.
- Fuel is a new fast object serializer
- Fuel might soon allow near-instantaneous bootstrap times for Metacello, the new package-mananagement system, which is getting closer to RubyGems (plus tools) every day
- The Pharo Kernel is driving the system to become more modular
I feel that we are close to a tipping point where the system becomes so easy and fun for developers that we will see a self-perpetuating revolution in the IDE. For me, Vim bindings are something I’ve sorely missed since finding Smalltalk two years ago. It’s only now that I’ve seen in Pharo an opening to make that dream a reality…
Now, if we can just clean Morphic…
As per Soundflower issue #67:
sudo chmod -R g-w /System/Library/Extensions/Soundflower.kext
sudo kextload /System/Library/Extensions/Soundflower.kext
And Soundflower will be working in Lion – no restart required!
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:
- empties the build directory
- generates the sources and cmake info
- Configures with cmake
- Opens the project in Xcode
First, load PipeableOSProcess via:
(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: [
ifTrue: [ e asFileDirectory recursiveDelete ]
ifFalse: [ e delete ] ] ].
addExternalPlugins: #( FT2Plugin );
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) 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;
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
 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 forced 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.
* 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], , [r], , [;], [.], 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.