I’m excited to announce that as of today (March 28th), I’ve accepted a new position at LivingSocial! I’m an Engineering Director, managing a few teams that work on backend architecture such as email, scaling, etc.
For the past 5 years, Engine Yard has been an amazing employer. Back in 2007, Tom Mornini took a chance on hiring me, enabling Rubinius to progress in a way it never would have otherwise. I can’t say enough about how much I appreciate everything they’ve done for me. It has been an embarrassment of riches.
So what does all this mean for Rubinius? Rubinius started as a passion project and continues to be. I’ll keep working on the project in all the same roles I have in the past. Because I won’t have the same amount of time, I’ll be doing more project management so that the amazing Rubinius community has a clearer picture of the work that is outstanding and can apply their talents to help move things forward.
I know some of you will read this and say “Evan left EY? Rubinius is dead.” I ask that you reserve judgement. The Rubinius community is an amazing group and I know that we all will continue to build a great platform. Brian Ford will continue working on Rubinius full-time and doing his amazing work getting Rubinius 2.0 finished.
I want to close by saying again how truly amazing Engine Yard is. I’ll always call this experience one of the most amazing opportunities of my life. For me, this decision was driven entirely by the chance to help LivingSocial build their architecture. I wish Engine Yard all the best and I’ll continue to help them with Rubinius related ventures in the future.
Syntax errors are a part of life for programmers. The language of the computer, no matter how flexible the language, is very picky.
And thus how the language communicates back to the user about what it didn’t understand is important, because time is spent in this phase, no matter the skill level of the programmer.
In Ruby specifically, MRI’s parser (and by extension the melbourne parser Rubinius uses) use yacc, and thus suffer from syntax errors which can be particularly difficult to understand. One particular syntax error that commonly occurs is when there is an ‘end’ missing from an expression. This results in the dreaded syntax error, unexpected $end, expecting kEND message.
Here is a quick example:
class Spaghetti class Sause def add(plate) while more? plate << self end end end
Now, this is a short example and so spotting the error is fairly easy. But this error typically occurs when you’re working on a 600 line file with multiple classes inside classes and with complicated logic, making it quite difficult to find.
This evening, I decided to try and at least help make this easier to find. So now in Rubinius, rather than
syntax error, unexpected $end, expecting kEND
missing ‘end’ for ‘class’ started on line 1.
Thats a big improvement, because now first off, it’s fairly clearly communicated what is wrong, i.e. that you’ve forgotten an ‘end’. In addition, it tells you what element still required a ‘end’, in this case, a ‘class’ on line 1.
Now, this is far from perfect. It’s pointing you to the element that was unclosed, rather than the one that you actually forgot the ‘end’ on. But it at least is now pointing you to the chunk of code that is the offending code. In practice, this can be a big help.
In the future, it might be possible to try and use indentation to try and narrow down where the missing ‘end’ should be. But for now, every little bit helps.
It’s Snow Leopard day zero, so of course I had to upgrade. All in all, everything is great. (Especially the multiple monitor window migration fix!)
But the #1 thing that annoys me about all OS X releases in the colors in Terminal.app. They’re pretty much unusable on a dark background (especially the blue). For some time, there have been hacks to fix the problem. Well of course these hacks didn’t work on 10.6 anymore.
Never one to shy away from the problem, I dove in. And we have success!
Here’s how to make it work:
- Find Terminal.app in Finder (/Applications/Utilities), right click, “Get Info”
- There is a checkbox “Open in 32-bit mode”, Check it!
- Install SIMBL. Plugsuit was installed on my machine before, it freaks out because of the 10.6 changes. SIMBL silently just works or doesn’t.
- Get My updated TerminalColours SIMBL plugin. See the original post for details on how to install it.
- Restart Terminal.app
- Enjoy your readable colors!
This works because InputManagers still work in 32bit mode, but not 64bit mode. So by forcing Terminal.app to run in 32bit mode, SIMBL can still hook in. I just had to update TerminalColours to swizzle a new method that 10.6 uses to pick colors.
Hope you enjoy!
Update: I’ve changed the tar.gz download link to one that should work better.
Got a new harddrive for my wifes MacBook. Couldn’t find her 10.5 upgrade DVD, so I tried to use the install DVD for my new MacBoor Pro. The DVD promptly told me it would not install (Apple cripples the OEM DVDs to only reinstall on the same make of machine), but it did not exit. So I select Restore from Time Machine Backup from the Utilities menu.
I try a few times, nothing. I give up for a while. Upon returning and seeing it still doesn’t work, I open the Install Log under Window.
I notice there are number of entries listed: Unable to load XIPanel_RestoreIntroduction nib file. Ok, well something is wrong with the Installer.
Terminal to the rescue. Open it up, do find / -name “XIPanel*” and find a number of them in a Resource folder. Ok, so it’s there, this must be a bug in the installer. Now we get serious. If you’ve gotten this, here’s what you do to get the Time Machine Restore to launch:
- Open Terminal
- Run ps ax and find the listing for Mac OS X Installer.app, note the number of the far left for it (the Pid)
- Run kill pid_of_installer
- You should now get a dark grey background, you’re doing great.
- Run export LANG=en_US.UTF-8. I’m not sure if this matters, but I did it, so you should too
- Run cd “/System/Installation/CDIS/Mac OS X Installer.app/Contents/MacOS/”
- Run ./Mac\ OS\ X\ Installer “/System/Installation/Packages/OSUpgrade.pkg”
- The installer should popup and say Welcome and such (likely with no graphics, thats ok)
- Click Yes/Continue enough for the Utilities Menu to appear at the top and select Restore from Time Machine Backup
- With luck, it will load! You can now do the restore!
Thanks for playing! Booo to Apple for having bugs in their Installer, Yay to Apple for leaving Terminal available in the Installer!
NOTE: Be sure to leave the Installer in the foreground while it restores, otherwise it will stall!
We’ve been pretty quiet with Rubinius developments for a while, so I thought I’d bring people up to speed.
The previous year has seen a lot for the project. We were sad a number of developers were laid off the project, but that has only increased our desire to get the project to a usable state.
Some of the highlights include, but are not limited to:
- Rewriting the VM in C++
- Experimenting and building multiple JIT compilers
- Pushing RubySpec completeness and compliance levels
- Getting large scale libraries like Rails and RubyGems running
All those things are available today in our git repo on github.
Recently, Brian Ford and I published a roadmap, laying out the activities of most importance over the next few months. We’re going to try and be more vigilant about updating blogs and roadmaps in the coming months, to keep people more up-to-date.
Finally, a lot of people ask me “How can I help on Rubinius? I don’t have a lot of time.” The answer is simple:
- Download your favorite library
- Try it under Rubinius:
bin/rbx gem install rspec; bin/rbx -S spec my_spec_dir
- Report bugs that you find to our github Issue tracker.
The more people start to report bugs, the more coverage we get over the vastness of the ruby landscape. So while we’re hard and work getting the performance up, you can help out getting the compliance up.
Thanks again to the ruby community for all the patience you have shown the team over the years. Rubinius has been a long road, but I really feel like we’re onto something big.
In the coming months, I’m going to try and post more posts about technical aspects of Rubinius, so look for those.
The last time we checked in, I was delivering the bad news about having to let a bunch of my team go. I received a lot of kind words of encouragement during the hard time, which I want to thank everyone for.
In addition to kind words, a number of people stepped up and indicated they had positions available that my newly unemployed friends would be great fits for.
One such offer was from Daniel Yoder and Charles Hornberger at AT&T Interactive in the R&D department, the makers of the yellowpages.com. I’m extremely happy to announce that Eero Saynatkari (rue on IRC) has recently been hired by them and even given time to continue work on Rubinius!
This development makes me so happy. To see the community pull together in a tough time and even continue to make an external investment in Rubinius.
Thanks again guys! You’re what make me love being a Rubyist.
There have been some sad developments within the Engine Yard Rubinius team that I’d like to address head on.
Earlier today, I had the unfortunate task of reducing the team size to 2 people, which meant laying off the rest of the team.
I’m sure this comes as a shock to many, as it did to my friends to whom I had to give walking papers. This was certainly never a scenario that I had ever hoped to find myself in when Engine Yard offered me this dream job early in 2007.
The reason for the layoffs is not Engine Yard divesting interest in Rubinius,
but rather a necessary reorganization of budget priorities. That’s a fancy way of saying that EY could no longer afford to sustain the large team we had.
This is a sad day for me, one that I’ve been dreading. It stings not only
because of what it means to Rubinius but also because of what it means to my friends with whom I will no longer be working. They’ve put blood, sweat, and tears into Rubinius and their everyday presence will be sorely missed. I hope that they do not think badly of me or Engine Yard.
When Engine Yard gave me the go ahead to hire a team, they did it with the best
intention: to help Rubinius grow. And we have definitely done that. In the
last year, we’ve achieved amazing goals within the project:
- We went from running very little ruby code to running rails.
- We got rubygems up and running well.
- We got a parser entirely in ruby integrated.
- We wrote a whole new VM to build on.
We’ve had our fair share of setbacks, but the team has always rallied.
Rubinius will continue to move forward, continually bolstered by the awesome group of people who give up their free time to help on the project.
Tom Mornini has posted on the EY blog as well; you should read his take.