No sooner than when I said Shoes was moving to 3.3, I got a complaint that recent OSX builds of 3.2 don’t work on OSX 9. As is often the case, the bug report was correct. 3.2.25, 3.2.24. and probably 3.2.23 don’t work on 10.9 – they do work on 10.10 but not everybody chooses to update and I promised 10.9. I failed and that must be repaired.
If you don’t care about how or why: There is a Shoes-3.2.26 for OSX. It was built on 10.9 and works for 10.9 and above. If you package a script or app for OSX that’s what it’s going to use on the end-users system. You’ll might notice it is 14MB in size instead of the usual 16MB.
I’ve also built the same Shoes on 10.10 (Yosemite) only its called Shoes 3.3.0 and available at the beta download site
The root problem was I’ve been updating my OSX system (now Yosemite) and xcode and more importantly, I did a ‘brew update’ and ‘brew upgrade’ which is when things really broke. By design brew updates to the latest packages and some of the latest don’t work on 10.9 and there is no way to remove an upgraded package by version number in brew. So I did what I do for building Shoes on Windows (and the we don’t talk about snow leopard build): Build my own dependencies. Don’t use brew. Don’t use rvm.
That was not an easy road nor is it the fast road. But I did it. It’s frozen in stone. 10.9 won’t change and those deps won’t change (unless there are bugs in them that matter). While I was at it, I built ruby 2.1.7 from source and stuffed rubygems 2.4.7 in it. It does not use rvm to install or build that Ruby, just like it didn’t use brew. While that was a very long process (2 days times 3 because that’s how many times I had to start and build every thing from scratch). There are benefits.
Shoes 3.3 is about new infrastructure and really pushing forward. For OSX, I cleaned up the rake files although there is always more to do for that task. The download size is 14MB so it’s about the same size as some Linux builds. No unused X11 libraries inside. No brew or rvm hangovers. I learned some things (X 3)
In truth, for many Shoes users, nothing all that exciting. We’ll fix some some bugs of course (if they get reported). We’re not going to support GTK2 – we’ll only use GTK3 for Linux and Windows. That allows us some flexibility in the future. We’re going to support Ruby 2.2.x and 2.3.x which is not as easy as we hoped. Both of those mean we need to make some major changes to the C and Objective C code otherwise the ball of spaghetti just gets larger and larger and even harder to understand.
Just as Gtk and Ruby change underneath us, Shoes 3.3 is going to be less compatible with Shoes 2 and 3.1 and probably Shoes 4. Still easy to install, still easy to play with, still easy to package up a script. Mostly compatible, sort of. But we’re going to add some features that will get “professional” developers a little more excited about Shoes as a “platform”. We’ve also got some fun ideas & demos of what a better Shoes “platform” could deliver and how developers could “leverage” the MRI Ruby in Shoes 3.3.
Have you gagged down enough Corporate Speak yet? I have, but some folks consider it useful or even important and it’s not all nonsense. Shoes 3.2 was all about getting 3.1 working again, fixing the egregious bugs. We tossed in some interesting new features along the way. A Maintenance Release.
For Walkabout, we’re going to build on that (leverage) and create something a little more useful for “real” applications. It’s going to be fun.
I went to Costco and bought a 1.5TB usb external drive. $59 USD. Because I live dangerously, I upgraded the pi2 to the latest Raspbian Jessie and eventually got my user name set up instead of the default ‘pi’. It makes everything easier in NFS to have the same user id (1000) on all NFS systems.
Then I had to get ssh whipped into shape. Always a mystery. Always a struggle.
I connected the SeaGate to my raspberry pi2 and after much horsing around with usb cables and even more horsing around with /etc/fstab and netatalk, it’s doing a Time Machine backup of the Mac Mini over enet to a pi with an external usb disk. Slow? Of course it is. Neither enet or USB is going to be fast on a Pi. 50% of one of 4 cores on the pi2. I also need to modify/add to the Linux backup scheme which uses rsync to backup to the pi2.
Having had to restore from backups before, I know what I should do buy there are constraints that in any scheme. Constraints that don’t need to apply get encoded into scripts and processes. Since I’m pushing around GB of data around, it takes time. A lot of time.