Bugfixes and updates
I’ve been working on the ‘bug-fix’ release over the last couple of days. There are couple areas that came up with a few non-serious bugs while I was testing. The first was the debugger watch window – where you drag a variable onto a Watch window and you can ‘drill down’ into it. The second is IntelliSense. One other thing that emerged was a problem on Vista...
The Vista fix was the first one I worked on. When a Solution was opened under Vista, this odd error message popped up: value cannot be null. parameter name: sp
It took a while to figure out what was wrong here (we certainly hadn’t deliberately built in any Vista-incompatibilities). Eventually I tracked it down to a subtle change in the .NET function Encoding.UTF8.GetBytes. This returns a different array of bytes under Vista than XP. Not a big deal, in the normal course of things - but enough to cause this strange problem for Ruby In Steel. These kinds of problems are not hard to fix - but they are hard to track down. Anyway, that one is now sorted out so the forthcoming update should run fine on Vista.
Next, I turned to the problem with the watch window. The watch window is tricky because Ruby doesn’t exactly co-operate in making the data available. You can get it easily enough by doing an inspect from within the Ruby component of the debugger. The main problem is that Ruby is a little cavalier about what it quotes and what it doesn’t. The second problem is that the format of the inspector output isn’t written down anywhere. I had to indulge in more than a little ‘forensic’ programming to figure out an Antlr grammar that would do the trick. I’ve now improved the grammar and the watch window functionality quite a bit and I think it will cope with most complex expressions – but I’m still really trying things out to see if I can break it.
I’ve fixed several small problems with IntelliSense that I noted as I was working my way through my diagnostics suite. I deliberately didn’t fix the minor bugs in our first release because (a) IntelliSense is tricky: fixing one thing can have unforeseen consequences and that’s not something you want when you are about to release; and (b) IntelliSense work needs time for a bit of quiet reflection: a commodity in short supply near a launch.
For example, in the syntax x = C where C is a class, x now gets the correct methods. In fact this did work at one time, but it didn’t work very consistently. It now does because I’ve figured out the underlying mechanism: it’s different from the way that the Ruby interpreter does it. One of the mistakes I made when I first started on the IntelliSense was to think that the IntelliSense engine would be similar to, but simpler than, the Ruby interpreter. In fact, it is quite different in operation and a good deal more complex. In the future, it’s going to get even more complicated as I extend it to reach into the interior of Rails as well.
One of the consequences of this is that I’m now quite close to being able to generate Ruby code (both compiled and interpreted) for .NET. However, I don’t want to do that just yet. One reason is that I’m not sure that there’s currently any commercial demand for Ruby on .NET and anyway there are others that are doing much the same (JRuby for Java and Gardens Point for .NET). The second reason is that it would distract me from doing the next phases we’ve outlined in the roadmap: there’s only one of me! A third reason is that a lot of the C code in the Ruby interpreter is ‘auxiliary’ methods like capitalize – it’s a heap of work to translate that stuff.
However, if Matz doesn’t get a move on with Ruby 2, the temptation to just to get on and do it will become overwhelming. I’ve a feeling that there’s serious trouble brewing here - we’re a year off 1.9 and Ruby 2 and the "Blessed Virtual Machine" is sometime never as far as I can see. Commercial Ruby desparately needs something better than the current interpreter.
Anyway, back to the subject in hand. We’re planning a 4-6 week bug fix before releasing 1.1 and we will release one or more interim versions before that. We intend to be pretty responsive to bug reports and try to fix them asap. The same applies to usability – if there’s a feature that’s not working well, we’ll try and come up with something better.
I dunno if there’s commercial demand for generating IL from Ruby but I’d use it. And Microsoft are funding the Queensland proecjt, aren’t they? (I couldn’t get it to run any of my code). And don’t forget John Lam’s Ruby CLR (http://www.rubyclr.com/) - he started work at Microsoft in the CLR team last month...
It’s going to happen. The world will be a (slightly) better place when it does.
There are a lot of potentially interesting things going on in the area of Ruby and .NET. It still remains to be seen what additional support for dynamic languages will be forthcoming from Microsoft. It’s very tempting to use the technology which we already have in Ruby In Steel in order to support the CLR. However, currently the demand seems to be mainly for Ruby and Rails. If people clamour for IL support, our views on the subject may change ;-)