http://www.sapphiresteel.com/Steel-Download-and-Change-Log

Please note that this Blog and its RSS Feed are no longer up to date. For the latest information on Sapphire In Steel, use the main site at: http://www.sapphiresteel.com and subscribe to our new RSS feed: http://www.sapphiresteel.com/backend.php3

It also has threaded ‘comment forums’ which should make it much easier to leave feedback.

From now on we won’t be using this WordPress blog though we’ll leave it online for now just in case you want to browse through older posts. However, if you want to keep up to date with the development of Sapphire and Ruby In Steel, please be sure to log onto the main site:
http://www.sapphiresteel.com
and subscribe to our new RSS feed:
http://www.sapphiresteel.com/backend.php3

best wishes
Huw

The simple fact of the matter is that we tried out something like a dozen different CMS (Content Management Systems) scripts and decided that SPIP was by far the best for our requirements. Gradually we’ll be moving most (or all) of the content of this site into SPIP. For the time being, you can carry on referring to this Blog for any news. Naturally we’ll let you know when the Blog itself will be ready to migrate to SPIP.

Incidentally, for those of you who have subscribed to our RSS feed, I’m afraid that, due to the fact that we’ve had to move WordPress into a new directory, the direct link to its RSS feed is now broken. Apologies for that but WordPress provides no (obvious) way of maintaining the directory structure to a feed when the software itself is moved. At any rate, we’ll have a new Feed online soon when SPIP is up and running.

• breakpoints
• locals  window
• drag-and-drop watch variables
• call stack
• tracing with step into / step over
• interactive debugging console

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…

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.

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.

Download Ruby In Steel

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…

The main problem with the debugger is that to build a simple (let alone one that lets you ‘edit and run’, say) you have to implement about ten COM interfaces. Then you have to build some sort of state machine on it’s own thread - plus any worker threads to handle the input and output to the Ruby interpreter itself. Each of the COM interface names starts with ‘IDebug’ so there’s IDebugProcess, IDebugProgram, IDebugProgramNode - and so on. Damned confusing. Then each interface has about ten methods and while they don’t all need coding, they need to be considered. It’s not a small job - and that’s before you get to any Ruby stuff.

One thing that struck me as I was doing the C# bits after the C++ tutorial, was how much faster it is to code in C#. Even with the ATL wizard, it still takes a lot longer than implementing the same interfaces with C#. I have to say that I’m coming round to the idea that Microsoft has done a reasonable job with COM and C#.

In passing, I found a tricky problem with the basic  IDE. The Steel splash icon had vanished (this appears on the Visual Studio startup splash screen along with C#, VB, etc.). The thing was, it had been visible in the past - but no longer! It turns out that the splash icons and menu commands are installed when you do a ‘devenv /setup’ command. But setup works differently from when you just run the IDE. In particular, the DTE automation isn’t initialised. The IDE setup sequence calls the package ‘Initialize’ command before the splash icon is loaded. If you try to access automation in the package Initialise, an exception is thrown and the icon loading is never called! Worse, nothing tells you this interesting fact. You have to turn logging on and look in the log file. The solution is to test for a null DTE in Initialize: if you are running setup, this is null, otherwise it’s set to something sensible.

I’m a big fan of VSIP, but it sure isn’t simple. There’s just a lot of stuff to learn.