People have been asking us if we’ll be providing support for Rails programming in Steel. The answer, in brief, is: yes! Absolutely. We plan to provide full, integrated support for Rails programming in a future release. We’ll soon be publishing a revised Roadmap to give more detail of features in development and our proposed release schedule.
We’ve made much better progress than we’d anticipated with the Ruby debugger for Visual Studio. Initially we had planned the debugger in 0.6 release of Ruby In Steel to take the form of breakpoints plus a ‘code evaluation’ window. In fact, we have come much further than that. It will now include the following features:
This is still some way short of the complete debugging which we have planned. For example, the 0.6 release won’t have conditional breakpoints, ‘drilling down’ into variables or the ability to change the values of variables while debugging; we’ll be adding these features in a later version. Let’s take a quick run through the features it will have…
Breakpoints
Steel lets you add breakpoints to your Ruby programs by clicking in the margin of selected code lines. You can selectively enable/disable selected (or all) breakpoints in this breakpoints window.
Locals
The Locals window automatically monitors and displays the values of local variables
Watch
You can enter the names of variables (or drag and drop variables from the editor window) in the Watch pane
Call Stack
When your code is running several methods deep you can see this instantly in the Call Stack pane
Debug Console
The interactive console not only display the output from the program you are debugging; it also lets you evaluate expressions – for example, enter the name of an object to inspect it or call a specific method to see the return value.
Beta version 0.6 of Ruby In Steel will be available for download from this site by the end of May.
Ah, it’s such a relief to have some decent debugging at last! We are currently working on beta 0.6 of Ruby In Steel (which will be available for download at the end of May). The big new feature in this version is the debugger. Currently this is still in its very early days, so don’t expect to have all the bells and whistles available in C# (yet). We’ll be bolting on a few more bells and whistles in a later version. For now we are integrating the ’standard’ Ruby debugging features. So far we have point-and-click breakpoints and the ability to trace into and over your code using the usual Visual Studio keystrokes. The debug inspection itself is done at an interactive prompt. So, when you hit a breakpoint you can, for example, print or inspect variables and evaluate expressions. Later on we’ll be adding in the usual Visual Studio inspector windows to let you watch and drill down into variables. There’s still a lot of work to be done to get all those goodies added into the mix. For now, though, I am still on a slight high at being able to do visual debugging and tracing of Ruby programs at all… 
I’ve now got the basic debugger more or less sorted. The next step in to build an ‘expression evaluator’ so that the watch window will work. It doesn’t look too bad, but it’s another half dozen or so COM interfaces to implement. The problem with this stuff is that it’s so low level. But to be honest, I can’t figure out a way Microsoft could have done it and yet retain the flexibility required to cover almost any situation.
For example, breakpoints aren’t just a simple ‘stop here’ sort of thing. You can have many breakpoints coming off one ‘pending’ breakpoint – breakpoints that only fire when a particular condition occurs, say. The these can either be ‘bound’ or in ‘error’. For a simple debugger like my current one, this is overkill, but you still have to abide by the Visual Studio model.
While doing the debugger, I did some research on existing Ruby debuggers. The results were quite interesting. The standard Ruby debugger, debug.rb, apparently executes around 100 times slower than running Ruby code without the debugger. Now that’s simply horrible. I wouldn’t want to debug any serious program with that. Active State have improved on this with their debugger to around 50 times. Better, but still unusable for a large program, I would think. Both of these debuggers use the tracing mechanism built into the Ruby interpreter to get a hook into the evaluator event source. However, it’s a pretty unsatisfactory way to go about things.
The last one I looked at was Arachno Ruby. This seems to have a 50 percent slowdown. That’s more like it! The problem is that Arachno has had to patch the Ruby interpreter to get this to work and patched interpreters are bad news. Not only are they non-standard, but you have to maintain them as well. Arachno currently doesn’t support 1.8.4 for example.
However, I’ve figured out a better way of running the Ruby interpreter in a fast debug mode without patching it. The trouble is, it isn’t at all easy to implement. The current Steel debugger (beta 0.6, not yet released) is just using the original slow debug.rb. The fast debugger will have to wait for the commercial version of Steel.
I had a good look at Arachno. Nice ideas there but there’s something slightly amiss. Say you want to write an IDE for Ruby, Perl, PHP and Python. Ok, ambitious – but doable: Active State have something there along those lines; probably taken them well over 20 man-years at a guess. Now let’s add in the fact that you want to be able to run it on Windows, Linux and Mac OS. Hmm, that’s challenging: making things portable is hard – just look at the work that’s gone into Ruby. So what do you chose to write it in: GNU Eiffel and some open source graphics package?? Now, that’s the heroic school of programming. The result (I’m guessing really) seems to have been that Arachno has spent a fair bit of time getting these wonderful open source things to work properly. That’s great if you have the time, money and inclination (personally I don’t). Still, I wish Arachno well.
Building an IDE of any sort is a big job (far more than one person can reasonably undertake). That’s why I’ve decided to stick firmly to Visual Studio – and that’s difficult enough. It does limit the scope to Ruby on Windows, but I’m happy with that for two reasons. First, I think it’s doable by two people in a reasonable timeframe. And secondly, there doesn’t seem to be any money in Linux products. Over and over again, I’ve seen companies produce stuff for Linux (Borland with Kylix is a notable example) only to withdraw after a short while. It’s true that a number of people have made money out of support for open source products. But I don’t know of many that have made money out of the raw product itself.
The first public beta of the Steel IDE for programming Ruby in Visual Studio 2005 is now available for download. Ruby In Steel 0.5.12 provides syntax sensitive code colouring and collapsing; a fully integrated interactive console which can be docked within the Visual Studio environment; integrated syntax error handling - click on the error message to locate the problem line in your source code; automatic bracket highlighting; bracket matching to move your cursor between brackets; a project management pane in which you can arrange groups of Ruby projects as branches in a tree; auto-commenting and uncommenting of Ruby code; plus many of the same editing features you would expect in any Visual Studio project such as multi-level undo/redo, split-window editing; toggle-bookmark and find/replace with regular expressions.
From now on, we shall be issuing regularly updated beta versions of Ruby In Steel (at one or two monthly intervals) with new features added in each release.
In most programming languages, strings are pretty dull things. Ruby’s strings are a whole lot more interesting, however. They let you do anything from evaluating program code to launching external applications. They also come in a bewildering variety which, to be frank, is pretty damn’ confusing to a newcomer to the language.
The latest article in the Bitwise Guide To Ruby cuts through the confusion of Ruby strings. If you are new to Ruby, I hope you’ll find it useful.
Meanwhile, for the benefit of anyone who’s keen to know when we’ll finally be putting online a version of the Ruby In Steel IDE for Visual Studio Studio 2005. Well, we’ve already committed ourselves to a first public beta before the end of April - and that commitment stands. We’re mid-way through April at the moment, so that gives us a couple more weeks to smooth out the wrinkles and iron out the bugs. ;)
Keep an eye on this site for more news…
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.