Home

Welcome to the IronRuby Developer Wiki! Everything here will help you contribute to IronRuby. If you are interested in just using IronRuby, please see the main website at http://ironruby.net.

Getting the sources

dev.bat

Building

Building (Visual Studio (Profession or Express), command line, Mono)

RubySpec

Debugging with VS

Modifying the sources

Contributing

h3. Debugging with Visual Studio

Using Visual Studio allows you to use an IDE to set breakpoints, step into code, etc. This works very well for debugging the IronRuby runtime. Debugging Ruby code is a work in progress.

Debugging C# code

In the Debug tab of the Project properties for Ruby.Console.csproj, set the fields as follows:

• Start Action:
  For Ruby.Console.csproj, “Start project” should be enabled.

For any other project, “Start external program:” should be enabled and set to “c:\vsl\Merlin\Main\Bin\Debug\ir.exe”

• Start Options:
  You can leave “Command line arguments” empty to get the REPL loop, or set it to the path to some .rb file to run the .rb file. Hitting F5 should now run the .rb file under VS, and allows you to set breakpoints as you would expect in IronRuby.dll and IronRuby.Libraries.dll (ie. in C# source code).

Debugging Ruby code

If you want to put breakpoints in Ruby code, make sure to remove the -X:Interpret option and instead add the -D option (which will cause IronRuby to use the debuggable System.Reflection.Emit.AssemblyBuilder instead of the non-debuggable System.Reflection.Emit.DynamicMethod).

If you want to have a ruby-debug-like-debugger method to insert a VS breakpoint via Ruby code

h4. Debugging a single RubySpec example

The most common way of running a rubyspec is to use the “rake mspec” task. Unfortunately this runs “mspec ci”, which spawns a new process to run the actual specs – this allows mspec can be run under one ruby implementation, while the rubyspec in question is executed by another. This makes it difficult to debug because the VS debugger attaches to the initial “mspec ci” process rather than the one that is actually executing the spec.

It is possible to pause the execution of the rubyspec, by modifying its code (with a call to gets for example) and then attaching the VS debugger to the spawned rubyspec process.

A better solution is to use the mspec-run command, since this does not spawn new processes. Despite this the mspec-run command still needs to know the location of a ruby implementation since it reuses code from the standard mspec command. (This is inside the mspec/lib/mspec/helpers/ruby_exe.rb file if you are interested). This file tries to ascertain under which ruby implementation we are running the rubyspec. The code that does this is not very IronRuby friendly (although it tries to be). The easiest way to ensure that mspec can find the ir.exe executable is to create an environment variable:

SET RUBY_EXE=/path/to/your/ir.exe

If you are running ir.exe with options e.g. -X:Interpret, you also need to set another variable:

 SET RUBY_FLAGS="-options"

I haven’t checked but I am pretty sure RUBY_EXE will be happier if you use forward slashes.

Once you have done this you can test whether mspec-run is going to work…

c:/path/to/mspec/bin:>/path/to/ir.exe mspec-run

If all is well you will get a usage message from mspec. If not then you will get a message saying that it could not find a suitable ruby executable.

Finally set up VS to run the mspec-run command as follows:

“Command line arguments” should be set to the following for running the “supports /i for ignoring case” example of string\gsub_spec.rb:

-v -X:Interpret
/path/to/mspec/bin/mspec-run

-e “supports /i for ignoring case” -fs -V -B 

/path/to/default.mspec

/path/to/rubyspec/core/string/gsub_spec.rb 

Hitting F5 should now run the single RubySpec example under VS.