Sapphire In Steel

As you may well imagine, Dermot and I have been pretty much immersed in Ruby this year. Dermot has had to grapple with the outer limits of Ruby’s syntax in order to build a Ruby lexer, parser and various Ruby support tools for the Steel IDE. Meanwhile, I am writing a Ruby programming tutorial and reference guide so I too have been delving into some of the twistier little highways and byways of the language.

Many times, both Dermot’s mood and mine have varied from high elation (“Wow! Come and look at this! Isn’t this great!”) to low desperation (“Grrrr… Of all the stupid things a language could do…!”)

In the end, we’ve both come to the conclusion that the good things about Ruby by far outweigh the bad (otherwise we wouldn’t be working on this project at all!). However, we’ve also had to be realistic. In order to get Steel up and running, we’ve had to live with - and work around - some pretty curious little oddities in the Ruby language. Anyway, we got together and talked over some of our feelings about Ruby in the lead feature in this month’s Bitwise.

See if you agree…

Just to bring you up to date on the progress of the Ruby In Steel programming IDE for Visual Studio 2005, here are a couple of pictures of the current beta…

This shows a few features of the Steel IDE. As you can see you can group your individual Ruby programs inside ‘projects’ (top right) and Solutions. These are organisational aids and are slightly different from, say C# projects and solutions, as Ruby In Steel is not a .NET programming tool. Notice that the editor has syntax sensitive Ruby colour coding and code collapsing. The pane down at the bottom of the screen is the integrated Ruby console. This lets you run the currently selected program in the Ruby interpreter and interact with it from within the Visual Studio environment (you don’t have to pop up a command prompt window - though this is also provided as an option). 

This picture shows the integrated syntax error trapping. Double-click an error message in order to highlight the problem line in the editor. Oh, and to run the program, just press F5 or click the Visual Studio ‘Run’ icon…

We announced the Ruby In Steel project on March 1st 2006. We shall be releasing the first public beta before the end of April. Keep visiting the site (or subscribe to our RSS feed) to keep up to date

I’ve decided to take backups seriously at last. I must be getting old.

So enter one new server from Novatech (a good company to buy from – never had any trouble, the stuff is pretty cheap and they are fast). Then comes the tedious job of installing Windows 2003 server and all the other bits. I’ve decided to try the new Microsoft Team Foundation Server so that I can take advantage of the ‘changeset’ features in the new Visual SourceSafe. I’ve never thought very much of VSS, but the ability to get a set of software files out as a ‘transaction’ looks to get good, so I’ll try it out.

Installation hasn’t gone smoothly: I’m on my second complete re-format of the hard disk. Some of the problems were mine – (RTFM!!), but some seem to be due to the fact that TFS need everything to be just so, or it gives up with inscrutable error messages. The real problem is that it relies on IIS, SQL Server, .NET and SharePoint – all of which have to be configured absolutely correctly with the correct accounts and correct priviledges. Unless you follow the instructions exactly, this is likely to be zero.

Anyway, after a meticulously performed re-installation with all service packs, hot fixes, etc. everything  worked and I’m ready to start. Just goes to show – never go near any software until the first service pack comes out. Also, the licensing restricts the number of users to 5 for the Workgroup edition. It gets expensive after that, but if you’ve got more than five developers then your spending serious money anyway

A further point: Visual Studio goes a lot better with 1GB of memory. I snaffled a ½ GB from the server to see if this would improve my workstation. It did and so I’m going to get a further 1GB for the server. It seems you can’t have too much memory.

On another note, I’ve finally got bracket highlighting & matching to work in Steel. The Ruby def…end type of things now also collapse correctly, though there seems to be a problem with the IDE ‘remembering’ outlines from a previous version. God knows where its getting them.

It took me a day or so hacking through Microsoft’s class library source to fix a couple of bugs that were preventing the outlining working ok. All seems reasonably fine now. Again one of the delights of using freshly released software – though Microsoft’s is quite a bit better than a lot of stuff (including mine).

So – the next job is adding Ruby debugging into the Visual Studio IDE. Should be fun!

I’ve finally got a LL(2) parser built for Ruby. It’s taken me about a month to do this from  knowing zilch about parsing and less about Ruby.

I had a couple of false starts. I started off by using Flex to build a component for Visual Studio colourising, but decided against using Bison and the existing YACC Ruby module since it tied me into using C/C++ for the syntax analysis; that wasn’t a direction I wanted to go.

I then tried using a free C# YACC toolset. That had a number of problems. It didn’t produce the same grammar as Bison and was slow to compile. I also learnt the hard way about the grief you can get when you have to try and debug a YACC style grammar: state tables might be fast, but finding out what’s wrong is a nightmare.

Then I came across Antlr. Magic! Absolute magic!! It produces easy to debug code – you can see what’s going on – and it has intelligible diagnostic messages. I love Terrence Parr’s sense of humour too – “Why program by hand in five days what you can spend five years of your life automating?”. A man after my own heart.

Ruby isn’t easy to fit into an LL(2) scheme, but it can be done - with one exception that I’ve come across so far. I’ve managed to parse nearly all the Ruby test modules so things are looking good. The next step is to bolt it into the Visual Studio/Steel IDE.

Parsing is quite fast for the most part. The main problems come where I’ve had to use predicates to resolve ambiguous Ruby syntax. Syntax-wise, Ruby simply sucks.

Newcomers to Ruby programming may be interested to take a look at the series of tutorials I’m writing for Bitwise Magazine. In Part Two, which has just gone online, I cover the basics of creating user-defined class hierarchies, dealing with instance and class variables and creating attribute accessors. Part One, which went online last month, is a gentle introduction to Ruby, covering simple string handling, maths, class creation, methods and so on. This series will continue over the next few months and all the source code is available for download.

We shall shortly be releasing a free Ruby IDE (Ruby In Steel) for Visual Studio 2005. More information will be announced in Bitwise Magazine shortly. In the meantime, here is a screenshot of the current beta…