Here’s the link: http://www.infoq.com/news/2010/02/ruby-in-steel-15.

Ruby In Steel ‘Developer Edition’ 1.5 provides integrated edit-and-run capabilities for Ruby 1.8.x, Ruby 1.9.x and JRuby 1.4 including IntelliSense and two integrated debuggers - Cylon for Ruby 1.8.x and the updated JCylon debugger for JRuby 1.4.

Ruby In Steel 1.5 supports named ‘Build Configurations’ to allow developers to test their applications against alternative Ruby interpreters simply by picking a configuration name from a drop-down list. This makes it easy to test an application against (for example) Ruby 1.8.6, Ruby 1.8.7, Ruby 1.9.1 and JRuby 1.4. The two integrated debuggers , Cylon and JCylon, support breakpoints, step-into/out/over and drill-down debugging (to expand complex variables) in multiple windows or in hovering ’debug tips’ in the code editor itself.

A free 60-day evaluation version of Ruby In Steel 1.5 is available for immediate download. Ruby In Steel 1.5 is a free update to existing registered users of any previous version of Ruby In Steel Developer.

More information:

 Overview of Ruby In Steel
 Ruby In Steel Feature List

There will be a few significant additions to the Amethyst Designer - our drag-and-drop user interface layout workplace - in the next edge release. The two most obvious of these are the addition of ‘styles’ and the first public release of the Amethyst ‘Go Live’ Design Mode.

You will be able to apply styles by making selections from the Styles palette (in the same tabbed window as the Properties palette):

This makes it a simple matter to transform a plain design like this...

Into a styled design like this...

Some styles, such text fonts and button rollover colours aren’t normally visible in the Designer. However, our new ‘Go Live’ mode actives the controls to let you interact with them just as you would in a running application. Just pick ‘Go Live’ from the right-click mouse menu...

And suddenly you can enter text, click radio buttons and test out rollovers...

When you’ve finished, disable ‘Go Live’ mode and you are back in the normal design mode so that you can carry on adding, moving, aligning and resizing controls until you are ready to ‘Go Live’ again to test them out...

I’ve recorded a short video to show styles and ;’Go Live’ in action. For best video quality, click the link below to watch it in High definition mode (or full screen) on You Tube:

http://www.youtube.com/watch?v=eJXx...

Alternatively, watch the low definition version below:

Yup, styles...

Up to now, the visual Designer has been restricted to the display of Properties. In the next version it will also let you add Styles such as colours, gradients, images, fonts, borders and drop shadows. You can even turn rectangular components into ovals by setting corner styles.

All you have to do is select the style from a palette in Visual Studio and enter the value you wish to apply or, when dealing with colours, use the pop-up colour picker. You will be able to set styles for individual controls or for the entire application. Watch for more news and tutorials here on the Blog.

This is a feature which will allow Flash or Flex programmers to debug complex applications comprising multiple SWF files all at the same time. In fact, you could even simultaneously debug completely separate applications running in different browsers.

We use this feature ourselves when programming the Amethyst Designer (the Flex drag-and-drop user interface creator which we have seamlessly embedded into Visual Studio) and most of the examples in the screenshots below show us debugging the Designer. But, in principle, we could be debugging any Flash, Flex or AIR applications.

First of all, you can see that I’ve selected a different command from the normal ‘Start Debugging’ command. This is the ‘Listen’ command. When you select this, Visual Studio doesn’t actually launch the SWF in a browser as the normal ‘Start Debugging’ command does. Instead, it activates the Cylon debugger in ‘listen’ mode where it is listening for a startup message from an SWF. Visual Studio is now in debug mode: you can’t edit files, for example, and if you look the Debug menu, you’ll see that the ‘Stop Debugging’ command is enabled. The only real visible indication that something unusual is happening can been seen in the Amethyst Console:

...where a message indicating that the Cylon has been activated can be seen. By the way, the Amethyst Console is also used to display trace messages from ActionScript, so when you say...

    trace('hello world!')

...the text “hello world” will appear in the Amethyst Console tool window. I then start my test program and switch from Code to Design. This loads the Designer SWF which has been compiled with ‘-debug=true’ and the Designer SWF connects to the ‘listening’ Visual Studio which then stops when the breakpoint (in the Designer code) has been hit. The test program is halted at initialization:

...while the Designer code is breakpointed:

So, to summarize, this what I’ve done. I’ve started to debug an external program (here the Amethyst Designer SWF) which was launched externally – here by another copy of Visual Studio – by setting the Cylon debugger into listen mode.

There’s one other thing to note about the Watch window – IntelliSense! With Cylon, you can type ‘x.’ in a Visual Studio Watch window and get the correct completion list for the object under inspection.

Of course, you also get the usual hierarchical breakdown of objects, separated out into ‘base’, ‘Non-public members’ and ‘Static members’ (just like C#). I’ve also added two ‘viewers’ for XML data and strings (again like C#).

Attach

Now, so far we’ve got one external SWF debugging in Visual Studio. What happens if another comes along? Assume that I’ve started another SWF via a browser (Firefox or IE – both will work fine). The first thing that you’ll notice is – nothing! The browser will hang – and the reason it’s hanging is that it’s waiting for the go ahead from Visual Studio/Cylon. So start up the Attach to Process... dialog from the Debug menu in Visual Studio and from the Transport drop down combo, pick ‘Cylon’:

Then from the ‘Qualifier’ drop down, pick ‘Adobe Flash Player’. You’ll now see a list of processes that are either ‘attached’ (greyed out) or ‘awaiting manual attach’:

Select a process and click the ‘Attach’ button:

Now if you redisplay the ‘Attach to Process...’ dialog, you’ll see that the SWF process name is set and it’s ‘title’ is ‘attached’. Finally, if you look under Debug | Windows | Processes, you’ll see a list of all attached processes:

At last – Auto-attach!

The whole procedure of using the ‘Attach to Process...’ dialog would be quite time-consuming and tedious if you repeatedly had to do it for every web page, say. So I’ve added an ‘auto-attach’ mechanism that does it all for you. If you select the ‘Auto Attach’ option (it’s actually a toggle) from the Debug menu, then when a debug-enabled SWF starts up, it will be attached and run just as if you had done it manually.

Here’s the result for three activations of the same SWF embedded in a HTML page:

All three SWFs have breakpointed at the same location (they are the same SWF, but running in separate browsers) and if you step, you’ll see the yellow arrow move from process to process as the breakpoint is handled.

It occurred to me that this would be a highly useful thing to be able to do with Flash: when a web page with a Flash SWF embedded is launched it should be able to connect with Visual Studio and you should be able to debug it, just as if you had started by launching the SWF from the Visual Studio end.

This mechanism that allows you to debug a program that you didn’t launch from Visual Studio is called ‘attach’ – and the ability to attach from the web page is known as ‘auto-attach’. When auto attach is enabled, and a web page containing a debuggable SWF is loaded in a browser (or otherwise activated), the SWF sends a message “I’m here” to Visual Studio and Visual Studio replies with an “OK – please continue” message, both of which messages are invisible to the user. It’s only when the SWF encounters a breakpoint that something happens.

It’s taken me some time (and a lot of effort) to get to this point in our Flash Platform IDE, Amethyst. I first started thinking about this about a year ago, but it’s taken till now to get it working smoothly. I realized that first of all, I needed a complete, fresh, ’from the ground up’ implementation of the Adobe Virtual Machine (AVM) debugging protocol to do this, so I set about engineering one in C#. This is the ’Cylon Debugger’. The second part was integrating this into the Visual Studio debug system and in particular figuring out how to get attach and auto-attach to work.

We’ve been using this technique very successfully in house for some months now in debugging our Flex drag-and-drop design environment, The Amethyst Designer. For technical reasons concerned with Microsoft’s COM technology (most of Visual Studio is still written using COM), it isn’t possible to debug the Designer (an SWF application hosted in a COM container) in the same instance of Visual Studio that holds the Designer code (written in ActionScript).

So we’ve been using two instances of Visual Studio to debug the Designer. One instance holds the ActionScript code and builds the Designer while the other runs an Amethyst application that happens to use the Designer. The first application (containing the Designer code itself) is run in ‘Listen’ mode while the user runs the application which uses the Designer in the second instance of Visual Studio.

When a significant event occurs in the running instance of the Designer which is being used in the second application – when a button is moved or resized say - then the ‘listening’ Visual Studio (that’s the one containing the ActionScript code of the Designer) can intercept this via a breakpoint – and now we can use all the debugging features: Watch, Call Stack, Step-into etc. - to debug the Amethyst Designer as it is being used.

In my next Blog post, in a day or two, I’ll explain in detail exactly how we use Amethyst’s auto-attach to debug the Amethyst Designer so that you will be able to use the same tools to debug multiple SWFs simultaneously in your own Flash or Flex applications.

 Auto-attach debugging is available in the current ’edge release’ of Amethyst.

This is the second ‘edge’ release since our last full beta in December. This build contains many of the unique debugging features of the new Amethyst ‘Cylon’ debugger for ActionScript and Flash. Amethyst now has multi-process debugging to enable developers to debug multiple SWFs simultaneously. This extends the ‘listen-and-debug’ capability from the previous edge release to make it possible to ‘attach to process’ either by selecting specific processes or by ‘auto-attaching’ to any executing SWFs.

This latest build (0.810) is designated as an ‘edge’ release which means that it includes features which are still in development and are less thoroughly tested than the features of our full beta releases. The last full beta is still available as an option.

For download details on the current edge release, please see the appropriate thread in the SapphireSteel Software forum.

For information (and a download link) for the last full beta of Amethyst, Beta 7 go to: Amethyst Download Page.

For information on Flash IDE integration which was added in the previous ‘edge’ release see this Blog entry.

We’ll be publishing more guidance to the features of the latest edge release of Amethyst and tutorials explaining how to use them here on the Blog during the coming weeks.

We released this in the very early days of Microsoft’s development of its implementation of the Ruby language for the dynamic language runtime under .NET. Initially we had anticipated a strong demand among .NET users for IronRuby which would have driven the further development of our IronRuby IDE. In fact, it has been our experience that the vast majority of our users continue to use the ‘standard’ version of Ruby (MRI), typically 1.8.x and we have had very little feedback relating to IronRuby.

Recently we opened up a discussion on our blog to try to ascertain whether or not there might be sufficient interest to justify the considerable effort which it would require to bring an IronRuby IDE onto a par with our main Ruby product, Ruby In Steel. While we did receive a few requests for further development, the response was far from overwhelming.

The IronRuby team at Microsoft has now announced plans to develop their own Visual Studio integration for IronRuby. While early indications are that this will not have the same features as our IronRuby IDE (as far as we are aware, there has been no mention of a visual designer or IntelliSense, for example), we nonetheless believe that the IronRuby market is not big enough to support two Visual Studio IDEs. We therefore must conclude that it is not a good use of our resources to commit to ongoing development of an IronRuby-specific IDE. Today we are announcing that there will be no further development of our IronRuby support.

I want to make it quite clear that this does not affect the continued development of our professional Ruby programming environment, Ruby In Steel. In a couple of weeks we shall launch our latest update to Ruby In Steel Developer (version 1.5) which, as before, will be free to all registered users. It is our continued commitment to provide the best editing and debugging environment available for standard Ruby.

Watch for more news here on the blog!

This is an ‘edge’ release of Amethyst, by which I mean it should be regarded as an ‘interim’ build between our major beta releases: its new features are incomplete and are the software is not as fully tested as our full beta releases. As we draw closer to the final version of Amethyst Professional 1.0 we may release several ‘edge’ editions to allow users to try out new or improved features at an early stage and report back to us on any bugs or deficiencies as well as making any feature requests.

If you wish to try out this new edition, please visit the forum to read the release notes and find the download link (which may change when new releases are made). Then read my short guide to Flash IDE integration with Amethyst.

I should again emphasise that the Amethyst Flash IDE integration is still in development and we welcome feedback from interested users.

The current beta of Amethyst already supports a degree of integration to allow you to share the same ActionScript code files between Amethyst and the Flash IDE as explained in a previous tutorial. In our next beta, due out early in 2010, the integration will be greatly enhanced. It will allow you to open Flash projects simply by importing existing .fla files. You will then be able to edit and debug the application’s .as ActionScript code files using Amethyst while continuing to use the Flash IDE to work on graphics and animation.

Here’s a short guide to a few of the Flash IDE integration capabilities which will be in the next beta.

 Convert Flash IDE Project

Our Import/Conversion Wizard will have a new option to let you convert an existing Flash IDE project for use by Amethyst in Visual Studio. No changes are made to your original project files which will now be available for use both in Amethyst and the Flash IDE.

 Copy Resources To Output

If you have data files and resources such as XML or images you can set a property to ensure that all the required files are automatically copied to the same output directory into which the SWF will be compiled.

 Edit With Amethyst

You can now use all the editing features of Amethyst including its extensive code colouring, code folding, configurable code formatting, code navigation, refactoring and IntelliSense.

 Debug With Amethyst

You can also use the Amethyst debugger to debug your Flash projects. First set some breakpoints then press F5 or click ‘Start Debugging’. The Flash IDE will automatically be invoked to publish the SWF and the Amethyst debugger will be started.

 Amethyst and the Flash IDE Working Together

Here you can see we have the original Flash application loaded into the Flash IDE - you can continue working on its design and animation here. Simultaneously the code of the project is open in Amethyst - here you can edit, refactor and debug the application. We are debugging an ImageViewer project from the book, Foundation ActionScript 3.0.

 Step, Watch, Debug

When a breakpoint is hit, you have access to all the advanced features of the Amethyst debugger including drill-down debugging in the code editor (via hovering debug tooltips), watch windows, autos and locals, regular or conditional breakpoints, the ability to step into/over/out of your code and navigate the call stack.

As I said earlier, some of these features are currently in development and will be released in the next major beta of Amethyst. We’ll give more details closer to the release date.