I’m just finishing the next release of Steel. We’ve put quite a lot of work into this one – Rails support, mainly. But underlying that is a whole raft of things which we’ll be using in future versions. Underpinning the Rails work is the extensive use of MSBuild. Now, initially, it wasn’t clear to me how you can build a project that uses an interpreter. For example, in a C++ or C# project you take a source file and produce an output file of some sort – you compile it. But Ruby?
So I had a good look at ‘rake’ the make of the Ruby world. And a very nice tool it is too. You specify a series of transformations from an input to an output. The examples I looked at seemed largely to do with extracting documentation from input files, but I can see how you can do much more.
The problem is of course that rake isn’t that useful for Visual Studio. Visual Studio not only uses MSBuild to construct outputs but incorporates MSBuild XML files into the way projects are laid out in the Solution Explorer. Clearly, the way forward is to incorporate rake type transformations into MSBuild and get MSBuild to do what rake does.
For example, in this version of Steel, when you build a project, the syntax of both Ruby files and Rails files is checked (via a rather nice HTML utility called Tidy). Syntax errors are reported back into the Error pane as you would with a C build. In addition, you can run both before build and after build tasks, so that Watir, for example, could be run to do even more checking. I’ll add more tasks as I think of them.
One of the things I really liked about rake was the way you could apply a Ruby script to a set of inputs. I’ve seen one example of something similar to that somewhere using C#, but it’s not really what C# is for – it’s a bit clumsy to compile it and then execute it in an MSBuild task. But with Ruby it’s easy. All you need to do is add a simple script to a MSBuild property and get your MSBuild task to run it. I don’t think I’ll be able to get that into the upcoming release, but it will be there for the next one.
As I mentioned, we’ve put quite a lot of work into incorporating Rails into Visual Studio. We’ve got RHTML/Ruby color coding functioning (the RHTML looks like the HTML you get in Visual Studio and Ruby looks like Ruby. The RHTML also has collapsible outlining. It certainly makes for nicer looking and more maintainable Rails code. On the database side, we support MySQL and SQLServer (with Oracle to come). If you stick with SQL Server you’ll get a better integration with Visual Studio, though I note that MySQL has signed up for the VSIP program now, so we’ll hopefully be able to improve on the MySQL ODBC connection in the future.
Of course, we’ve fixed a few bugs and improved the general Visual Studio ‘look-and-feel’ as I’ve got more familiar with the VS SDK – this will continue as I get round to implementing them. For example, Show All Files now works – pretty useful for seeing all the other stuff in a Rails project that isn’t in the MSBuild XML, such as log files and the like.
After this release, the next big things look like being code completion and the fast debugger. I should be able to link this into Rails debugging as well. From my limited experience of Rails so far, I’d say that’s the one area over anything else that could do with some help. Rails diagnostic messages aren’t just bad – they’re dire.
When I wrote The Little Book Of Ruby I, naturally, hoped that some people might find it useful. But I must admit that I had no idea it would generate this much interest.
The Little Book only went online last Saturday and one week later it has been downloaded more than 2,000 times (2,005 at this very moment)!
If you haven’t already got a copy, you can grab one now over on the download page. While the Little Book starts with the very basic features of Ruby, so is suitable for ‘absolute beginners’, the later chapters also delve into some of the twisty little highways and byways of Ruby programming - so I hope that even more experienced programmers may find a few items of interest…
Anyway, The Little Book Of Ruby is free, so you can’t really lose… ;-)
Development on beta 0.7 of Steel is making good progress.
So far we have a Rails wizard to let you start a new project and add all the Rails-generated directories and files to the Visual Studio Solution Explorer; we also have menus and dialog boxes to let you run scripts to generate controllers and views and add all the new items to the existing solution; another menu lets you start a web server; and we’ve begun work on syntax colouring for rhtml files.
We’re aiming to have this version available for download some time in July. In the meantime, if you have any ideas for useful Rails development features to add to Steel, there is already an active discussion HERE so please feel free to contribute.
If you haven’t already downloaded Steel, you can get version 0.6 – which includes Ruby editing and integrated debugging from our Download Page.
I came across a debugger peculiarity reported by a user of Steel 0.6 recently. The symptom was a rather strange error message appended to the result of querying a database using DBI.
At the end of the dataset, the text
“C:\Program Files\SapphireSteel\Steel\v1.0\Ruby\xdebug.rb:141: warning: (...) interpreted as grouped expression” popped up. The Ruby expression in question was the line:
catch (:error) do
Strangely, the warning went away if I changed the line to
catch :error do
Notice that I’ve just deleted the space character between
catch and the opening bracket in the last version above.
After a bit of head scratching, I tracked this down to the first line of the script that was being debugged. It was this:
#!/usr/bin/env ruby -w
Removing the –w caused the warning to disappear. So, it seems that Ruby was reading the first line of the text (under Windows don’t forget, not Unix) and turning on warnings. This then triggered the warning on the
catch line. I don’t know if Ruby is supposed to look at comment lines like this in Windows, but it certainly looks as if it did.
But (even more weirdly) altering the line to remove the space before the opening bracket caused the warning to go away: why should removing a space do that?
This illustrates one of the problems in trying to work with Ruby from a tools perspective – it just does unpredicatable things. Trying to parse error messages is hit and miss. All I can do is apply some heuristics to try and get sense out of most of the error messages most of the time...
I’ve just been finalizing – in more ways than one - the 0.6 beta of Steel. It’s been “nearly done” for about a week or so now, but there have been a couple of problems, now hopefully fixed.
The main one was the interesting habit of Steel zapping your desktop when a Ruby debugging session ended. It didn’t happen very often, but occasionally - ZAP!! - when you once had Word, Excel, Outlook, Visual Studio, etc., all up and running, all that remained was a virgin desktop. It took me some time to track this one down, and it’s all down to one of the most undesirable ‘features’ of Windows I’ve ever come across.
It’s to do with terminating a process ‘tree’. To be tidy, I thought it was a good idea to clean up any potential sub-processes that a Ruby program had created while I was debugging it. No problem – just find the Windows KillTree API. Except that there isn’t one. It seems that you have to do it the hard way and figure out which process is a child of the main Ruby process. OK – a little strange that Microsoft hadn’t provided an API for the job when there are over 80,000 of the things to do everything from formatting your hard disk to cleaning the fluff out of the keyboard. And stranger, there didn’t seem to be any documentation on how to do it; normally, there’s an MSDN article on stuff like that. At this point, alarm bells should have been ringing. But a quick search of Google came up with a technique which seemed to work fine. Most of the time.
It turns out that a process does indeed have a reference to its parent process (the process that created it).This is the parent Process ID (PID). However, the parent PID can have exited without killing off its child. Worse, far worse, Windows reuses PIDs! So not only can the parent of a process be a non-existent process (not too bad) – it can also point to a perfectly good process that isn’t its parent!
In my case, occasionally, just occasionally, the ‘parent’ of the desktop Explorer was my Ruby process. So killing the sub-tree of processes supposedly created by Ruby zapped the desktop Explorer and all its child processes – Outlook, Word, Visual Studio, etc. Baaaah...!!!
On reflection, I can’t see an absolutely safe way of killing a process tree in Windows because of this PID re-use. There just isn’t a cast-iron guarantee that the ‘parent’ of a given process really is the parent. I haven’t found any reference to this ’feature’ on the web anywhere. It seems that the issue of PID re-use is reasonably widely known, but the basic fact that you can’t build a good KillTree isn’t.
We’re in the last stages of testing and debugging Ruby In Steel 0.6 at the moment. But, hey! the sun was shining, the birds were singing and so, yesterday, we decided to take a day off to explore the countryside...
But, no matter where we go, it seems we just can’t get away from Ruby. Here’s a photograph to prove it. This is Steel lead developer, Dermot Hogan, on a forest walk close to the Sapphire In Steel offices here in Devon, South-west England. Well, we hadn’t realised that the Forestry Commission took a keen interest in programming. Anyway, it’s nice to know that they are as keen on Ruby as we are.
Ah well, the sun is still shining, the birds are still singing, but here we are once again, back indoors, crouched over our PCs, slaving away over the next version of Steel. Coming your way soon, folks...
We’ve just managed to sneak in one extra feature for Ruby In Steel 0.6 - a point-and-click Error List!
- Syntax Errors shown in list beneath the editor
If you’ve used Steel 0.5 you’ll know that you can already find syntax errors in your code by clicking any error messages in the console window. While this works, it doesn’t really work in a Visual Studio way. We’ve improved upon this in the forthcoming 0.6 release. This will now gather together any syntax errors in the familiar VS Error List pane. This shows each error message, the name of the file in which it occurs and the line on which Ruby believes the syntax error to have occurred.
I say on which Ruby "believes" as, to be honest, its guesses are not always all that good. Currently we are reliant upon Ruby to indicate the position and nature of any syntax errors and so we are working within those limitations.
For those of you who liked the old (0.5) way of finding syntax errors, we’ll continue to provide clickable console error messages as an alternative.
Just a couple of weeks away now from the next public beta (0.6) of Ruby In Steel. We thought you might like to see a preview of the debugging features in this version so I just recorded a short Flash movie illustrating a few of its capabilities. The movie is about 6 minutes long and is around 2.5Mb in size. It gives you a quick tour of breakpoints, locals, the auto window, step-into, step-over, evaluating expressions in the interactive console and the call stack.
If you’ve visited the Sapphire In Steel site previously, you may notice that things have changed a bit! Well, quite a lot, actually…
But before I explain what’s been going on, let’s get the important little details out of the way first. We are making good progress on the next version of Steel which will include Ruby debugging integrated with Visual Studio 2005.
- Beta 0.6 of Steel
There will be breakpoints and watch points, a locals window, an interactive debug console and tracing with step-into and step-over. However, I don’t want to repeat all the details here as I’ve already written about the new features (with lots of screen shots) over in the old Sapphire/Steel development blog.
Here are two important links:
The Old Blog (no longer active. link removed)
Ah yes, the blog. That used to be the first thing you saw when you logged onto this site. Not any longer. It is still there but its days are, I’m sorry to say, numbered. There’s a good reason for this. The old blog runs under WordPress, which is one of the most popular open source blogging systems. It’s not a bad piece of software if all you want to write is a blog (though, for the record, my favourite blogging software is Pivot). If, on the other hand, you want to create a highly structured site with one section about the current state of development of your software, another section about programming in general and yet another one for opinion pieces – not forgetting various pages on using the software, downloading it, installing it and so on – well, WordPress is far from being the ideal tool for the job…
After a great deal of research and testing of various systems for creating and maintaining a complex web site, we eventually decided to use the SPIP CMS. This is an excellent piece of software which is widely used in its native France but is undeservedly little known elsewhere.
First, a terrible admission: SPIP is not written in Ruby. In common with most CMS systems it is coded in PHP. There are some promising Ruby-based CMS systems currently in development such as Typo and Radiant. Who knows, maybe one day we’ll change to using one of those. For the time being, however, that isn’t an option since our web host, Hostgator, doesn’t support Ruby or Rails. When we asked them about this they told us that they had reservations about various features related to FastCGI or SCGI and Rails’ poor integration with Apache. In any case, while it would have given us a nice, rosy glow to be using a Ruby CMS, frankly, I have to say that SPIP is a hard act to follow.
SPIP was developed specifically for the publication of a French language online magazine, UZine. Accordingly it organises everything, in a magazine-like format, with well-defined sections and subsections. To a large extent, this makes keywords redundant. In many Blog/CMS systems, keywords or ’tags’ provide the primary way of grouping articles by theme. So, for example, in our WordPress blog whenever we wrote an article about Ruby programming we added two tags – ’ruby’ and ’programming’. If you wanted to read other articles about ’ruby’ or about ’programming’, you could click the relevant tag and WordPress would go off and find some.
In SPIP, on the other hand, if I write an article about Ruby programming I will put it into the Ruby subsection of the Programming section. This is a bit like grouping articles in subsections (the Football subsection, say) of the main sections (such as the Sports section) in a newspaper. Or, to be more prosaic, it’s like grouping files into directories and subdirectories. SPIP has keywords too, which can be used to add finer levels of categorisation. And if you still can’t find what you are looking for, there is the Search tool.
One of the other benefits of SPIP is that it has built in ‘comment forums’. This means that, if you want to leave a message or a question about a specific article, you can do so by either replying to the article itself or by replying to an earlier reply. The comments are threaded and replies-to-replies are indented for clarity.
For more guidance to getting around this site, see How To Use This Site.
One final word of caution, however: as with Steel itself, this web site is very much in the ‘beta’ stage. We’ve tried to configure it as as well as we can. But even so, it is pretty certain that some things won’t work as expected or that certain features just aren’t quite ‘right’. We’ll try and fix any faults and make improvements over time. So please, stick with us till we get it right…!
More Blog Posts...... | 330 | 340 | 350 | 360 | 370 | 380 | 390 | 400 | 410 | 420