Debugging rubyspecs


#1

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I
just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.

Pete


#2

The easiest way it appears is to stick a pause in the rubyspec of
interest
and attach to the process while it is waiting. It does totally kill the
computer performance while you are debugging (like minutes to step
through
each line!)

Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I
just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.

Pete


#3

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#4

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works pretty well for me. If the paths are incorrect, feel free to
update the wiki.

Debugging with Visual Studio
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: “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
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
    “supports /i for ignoring case” -fs -V -B
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsub_spec.rb
    Hitting F5 should now run the single RubySpec example under VS

Thanks,
Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#5

Do you pass -D to the ir.exe that runs the specs? The debugging is
better that way, although I admit it is not good at all in any case :frowning:

Tomas

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#6

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am
running the head version directly from rubyspecs github: “d482804 Added
should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius)
for each test run. So there is no point in debugging the initial
process.

Shri, on my machine your instructions below result in “unknown: Unable
to
find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same
problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works
pretty well for me. If the paths are incorrect, feel free to update the
wiki.

Debugging with Visual Studio

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: “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
c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
“supports /i for ignoring case” -fs -V -B
c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsu
b_spec.rb

Hitting F5 should now run the single RubySpec example under VS

Thanks,

Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks
on a call to System::Diagnostics::Debugger when a debugger is attached
to
the app. Unfortunately this breaks in a Ruby method, so you have to jump
up
a couple CLR frames to get to the line directly after the “debugger”
call,
and I’m not sure of a way how to do that automatically. Anyway, this
works
great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest
and attach to the process while it is waiting. It does totally kill the
computer performance while you are debugging (like minutes to step
through
each line!)

Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I
just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.

Pete


#7

The following command runs a single spec, and only launches ir.exe once.
Note that the command launches mspec-run.rb which does not spawn any
processes. The other runners like mspec-ci etc do spawn a new process
for mspec-run.rb.

c:\vsl\Merlin\Main>c:\vsl\Merlin\Main\bin\debug\ir.exe -v -X:Interpret
c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
“caches” -fs -V -B
c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/language/regexp_spec.rb

Also, note that in my previous command line, I had an extra “1.8”. This
was needed for an earlier version of mspec, but should not be used
anymore. I have updated the wiki with the latest instructions that I
have verified work for me and allow me to hit a breakpoint where I
expect.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am running the head version directly from rubyspecs github: “d482804
Added should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius) for each test run. So there is no point in debugging the
initial process.

Shri, on my machine your instructions below result in “unknown: Unable
to find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works pretty well for me. If the paths are incorrect, feel free to
update the wiki.

Debugging with Visual Studio
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: “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
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
    “supports /i for ignoring case” -fs -V -B
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsub_spec.rb
    Hitting F5 should now run the single RubySpec example under VS

Thanks,
Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#8

I am still having problems with this…

D:\dev\ruby\ironruby\current\Merlin\Main>
D:\dev\ruby\ironruby\current\Merlin\Main\bin\debug\ir.exe -v
-X:Interpret
d:/dev/ruby/mspec/bin/mspec-run -e “caches” -fs -V -B “c:/Documents and
Settings/pete/default.mspec” d:/dev/ruby/rubyspec/lang

uage/regexp_spec.rb

unknown: Unable to find a suitable ruby executable. (Exception)

Even this has the same result…

D:\dev\ruby\ironruby\current\Merlin\Main>d:\dev\ruby\ironruby\current\Merlin
\Main\bin\debug\ir.exe -v -X:Interpret d:/dev/ruby/mspec/bin/mspec-run

unknown: Unable to find a suitable ruby executable. (Exception)

Don’t have time to delve into this at the moment but will do so
tomorrow.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Thursday,19 February 19, 2009 18:24
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The following command runs a single spec, and only launches ir.exe once.
Note that the command launches mspec-run.rb which does not spawn any
processes. The other runners like mspec-ci etc do spawn a new process
for
mspec-run.rb.

c:\vsl\Merlin\Main>c:\vsl\Merlin\Main\bin\debug\ir.exe -v -X:Interpret
c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
“caches” -fs -V -B
c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/language/regexp_spe
c.rb

Also, note that in my previous command line, I had an extra “1.8”. This
was
needed for an earlier version of mspec, but should not be used anymore.
I
have updated the wiki with the latest instructions that I have verified
work
for me and allow me to hit a breakpoint where I expect.


#9

All the versions that IronRuby has used, have the outer layer CRuby
process kick off a target implementation process. If you call mspec -fs
core -t “ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For
many of the specs, you can skip the outer layer, and run mspec-run (or
mspec-ci, or mspec-tag) directly. For debugging, this is what Shri is
talking about.

As a side note, I advise not doing it this way in general, since there
are environment variables set via the outer layer runner, which will
affect the operation of Mspec. Until now, it has only been
MSPEC_RUNNER=1, which tells Mspec that the specs are being run by Mspec,
not Rspec. However, Mspec also sets RUBY_EXE and RUBY_OPTIONS, to the
values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command line options (I am adding these right now) use the ruby_exe
helper. This helper starts a new process of the currently running
implementation to run the specified command or file. Using the outer
layer with -t and -T ensures that these specs are run on the proper
implementation and options. I know that the implementation attempts to
be inferred via other means (RUBY_NAME, RUBY_PLATFORM), but the options
are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to get things set up, and if you set things up correctly (using
~/.mspecrc and setting /path/to/mspec/bin in your PATH) you can run a
spec file as easily as mspec ci core/array/pack (to run
core/array/pack_spec.rb). You have to make sure set :target,
“/path/to/ir.exe” and set :prefix, “path/to/rubyspec” are set in
~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am running the head version directly from rubyspecs github: “d482804
Added should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius) for each test run. So there is no point in debugging the
initial process.

Shri, on my machine your instructions below result in “unknown: Unable
to find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works pretty well for me. If the paths are incorrect, feel free to
update the wiki.

Debugging with Visual Studio
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: “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
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
    “supports /i for ignoring case” -fs -V -B
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsub_spec.rb
    Hitting F5 should now run the single RubySpec example under VS

Thanks,
Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#10

I did have to play with a bunch of settings to get mspec to work under
VS, and its possible that I have set some setting that I am now
forgetting, but I do not have RUBY_EXE set, and I don’t seem to have a
.mspecrc file either. Could you please update
http://wiki.github.com/ironruby/ironruby with the exact step you took to
enable you to debug with VS so that others don’t have to go through the
same issues?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Sunday, February 22, 2009 1:29 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

OK so I worked it out.

Mspec-run does indeed run only a single process but it still requires
mspec/lib/mspec/helpers/ruby_exe.rb. This file tries to set a constant
called RUBY_EXE but it is not able to do so: It tries to guess it from
various environment, constant and config settings. Since ir does not
set RUBY_NAME you have to do something like set the environment variable
RUBY_EXE or have a ~/.mspecrc file that specifies the :target => … and
so on.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Thursday,19 February 19, 2009 18:09
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

All the versions that IronRuby has used, have the outer layer CRuby
process kick off a target implementation process. If you call mspec -fs
core -t “ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For
many of the specs, you can skip the outer layer, and run mspec-run (or
mspec-ci, or mspec-tag) directly. For debugging, this is what Shri is
talking about.

As a side note, I advise not doing it this way in general, since there
are environment variables set via the outer layer runner, which will
affect the operation of Mspec. Until now, it has only been
MSPEC_RUNNER=1, which tells Mspec that the specs are being run by Mspec,
not Rspec. However, Mspec also sets RUBY_EXE and RUBY_OPTIONS, to the
values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command line options (I am adding these right now) use the ruby_exe
helper. This helper starts a new process of the currently running
implementation to run the specified command or file. Using the outer
layer with -t and -T ensures that these specs are run on the proper
implementation and options. I know that the implementation attempts to
be inferred via other means (RUBY_NAME, RUBY_PLATFORM), but the options
are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to get things set up, and if you set things up correctly (using
~/.mspecrc and setting /path/to/mspec/bin in your PATH) you can run a
spec file as easily as mspec ci core/array/pack (to run
core/array/pack_spec.rb). You have to make sure set :target,
“/path/to/ir.exe” and set :prefix, “path/to/rubyspec” are set in
~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am running the head version directly from rubyspecs github: “d482804
Added should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius) for each test run. So there is no point in debugging the
initial process.

Shri, on my machine your instructions below result in “unknown: Unable
to find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works pretty well for me. If the paths are incorrect, feel free to
update the wiki.

Debugging with Visual Studio
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: “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
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
    “supports /i for ignoring case” -fs -V -B
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsub_spec.rb
    Hitting F5 should now run the single RubySpec example under VS

Thanks,
Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#11

OK so I worked it out.

Mspec-run does indeed run only a single process but it still requires
mspec/lib/mspec/helpers/ruby_exe.rb. This file tries to set a constant
called RUBY_EXE but it is not able to do so: It tries to guess it from
various environment, constant and config settings. Since ir does not
set
RUBY_NAME you have to do something like set the environment variable
RUBY_EXE or have a ~/.mspecrc file that specifies the :target => … and
so
on.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Thursday,19 February 19, 2009 18:09
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

All the versions that IronRuby has used, have the outer layer CRuby
process
kick off a target implementation process. If you call mspec -fs core -t
“ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For many of
the
specs, you can skip the outer layer, and run mspec-run (or mspec-ci, or
mspec-tag) directly. For debugging, this is what Shri is talking about.

As a side note, I advise not doing it this way in general, since there
are
environment variables set via the outer layer runner, which will affect
the
operation of Mspec. Until now, it has only been MSPEC_RUNNER=1, which
tells
Mspec that the specs are being run by Mspec, not Rspec. However, Mspec
also
sets RUBY_EXE and RUBY_OPTIONS, to the values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command
line options (I am adding these right now) use the ruby_exe helper. This
helper starts a new process of the currently running implementation to
run
the specified command or file. Using the outer layer with -t and -T
ensures
that these specs are run on the proper implementation and options. I
know
that the implementation attempts to be inferred via other means
(RUBY_NAME,
RUBY_PLATFORM), but the options are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to
get things set up, and if you set things up correctly (using ~/.mspecrc
and
setting /path/to/mspec/bin in your PATH) you can run a spec file as
easily
as mspec ci core/array/pack (to run core/array/pack_spec.rb). You have
to
make sure set :target, “/path/to/ir.exe” and set :prefix,
“path/to/rubyspec”
are set in ~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am
running the head version directly from rubyspecs github: “d482804 Added
should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius)
for each test run. So there is no point in debugging the initial
process.

Shri, on my machine your instructions below result in “unknown: Unable
to
find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same
problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works
pretty well for me. If the paths are incorrect, feel free to update the
wiki.

Debugging with Visual Studio

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: “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
c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
“supports /i for ignoring case” -fs -V -B
c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsu
b_spec.rb

Hitting F5 should now run the single RubySpec example under VS

Thanks,

Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks
on a call to System::Diagnostics::Debugger when a debugger is attached
to
the app. Unfortunately this breaks in a Ruby method, so you have to jump
up
a couple CLR frames to get to the line directly after the “debugger”
call,
and I’m not sure of a way how to do that automatically. Anyway, this
works
great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest
and attach to the process while it is waiting. It does totally kill the
computer performance while you are debugging (like minutes to step
through
each line!)

Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I
just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.

Pete


#12

The convenience of being able to hit F5 in an existing VS session and
getting to the breakpoint you have previously set will be worth the pain
of setting it up for some folks. With mspec and Jimmy’s wrapper (which
is also documented on the wiki), you have to edit the Ruby files you are
debugging (which will require doing “tf edit” first), will launch a new
VS session which can be slow, won’t allow setting conditional
breakpoints easily, wont show unexpected exceptions prior to the
sleep/attach which might be triggering a failure later on, etc. Having
options is a good thing so people can chose whatever works best for
them.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday, February 23, 2009 12:00 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

In my opinion, the most future proof way is going to be using the
standard runner (mspec) and a sleep, or using Jimmy’s debugger wrapper.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Sunday, February 22, 2009 11:09 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I did have to play with a bunch of settings to get mspec to work under
VS, and its possible that I have set some setting that I am now
forgetting, but I do not have RUBY_EXE set, and I don’t seem to have a
.mspecrc file either. Could you please update
http://wiki.github.com/ironruby/ironruby with the exact step you took to
enable you to debug with VS so that others don’t have to go through the
same issues?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Sunday, February 22, 2009 1:29 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

OK so I worked it out.

Mspec-run does indeed run only a single process but it still requires
mspec/lib/mspec/helpers/ruby_exe.rb. This file tries to set a constant
called RUBY_EXE but it is not able to do so: It tries to guess it from
various environment, constant and config settings. Since ir does not
set RUBY_NAME you have to do something like set the environment variable
RUBY_EXE or have a ~/.mspecrc file that specifies the :target => … and
so on.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Thursday,19 February 19, 2009 18:09
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

All the versions that IronRuby has used, have the outer layer CRuby
process kick off a target implementation process. If you call mspec -fs
core -t “ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For
many of the specs, you can skip the outer layer, and run mspec-run (or
mspec-ci, or mspec-tag) directly. For debugging, this is what Shri is
talking about.

As a side note, I advise not doing it this way in general, since there
are environment variables set via the outer layer runner, which will
affect the operation of Mspec. Until now, it has only been
MSPEC_RUNNER=1, which tells Mspec that the specs are being run by Mspec,
not Rspec. However, Mspec also sets RUBY_EXE and RUBY_OPTIONS, to the
values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command line options (I am adding these right now) use the ruby_exe
helper. This helper starts a new process of the currently running
implementation to run the specified command or file. Using the outer
layer with -t and -T ensures that these specs are run on the proper
implementation and options. I know that the implementation attempts to
be inferred via other means (RUBY_NAME, RUBY_PLATFORM), but the options
are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to get things set up, and if you set things up correctly (using
~/.mspecrc and setting /path/to/mspec/bin in your PATH) you can run a
spec file as easily as mspec ci core/array/pack (to run
core/array/pack_spec.rb). You have to make sure set :target,
“/path/to/ir.exe” and set :prefix, “path/to/rubyspec” are set in
~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am running the head version directly from rubyspecs github: “d482804
Added should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius) for each test run. So there is no point in debugging the
initial process.

Shri, on my machine your instructions below result in “unknown: Unable
to find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works pretty well for me. If the paths are incorrect, feel free to
update the wiki.

Debugging with Visual Studio
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: “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
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
    “supports /i for ignoring case” -fs -V -B
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsub_spec.rb
    Hitting F5 should now run the single RubySpec example under VS

Thanks,
Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#13

In my opinion, the most future proof way is going to be using the
standard runner (mspec) and a sleep, or using Jimmy’s debugger wrapper.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Sunday, February 22, 2009 11:09 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I did have to play with a bunch of settings to get mspec to work under
VS, and its possible that I have set some setting that I am now
forgetting, but I do not have RUBY_EXE set, and I don’t seem to have a
.mspecrc file either. Could you please update
http://wiki.github.com/ironruby/ironruby with the exact step you took to
enable you to debug with VS so that others don’t have to go through the
same issues?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Sunday, February 22, 2009 1:29 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

OK so I worked it out.

Mspec-run does indeed run only a single process but it still requires
mspec/lib/mspec/helpers/ruby_exe.rb. This file tries to set a constant
called RUBY_EXE but it is not able to do so: It tries to guess it from
various environment, constant and config settings. Since ir does not
set RUBY_NAME you have to do something like set the environment variable
RUBY_EXE or have a ~/.mspecrc file that specifies the :target => … and
so on.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Thursday,19 February 19, 2009 18:09
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

All the versions that IronRuby has used, have the outer layer CRuby
process kick off a target implementation process. If you call mspec -fs
core -t “ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For
many of the specs, you can skip the outer layer, and run mspec-run (or
mspec-ci, or mspec-tag) directly. For debugging, this is what Shri is
talking about.

As a side note, I advise not doing it this way in general, since there
are environment variables set via the outer layer runner, which will
affect the operation of Mspec. Until now, it has only been
MSPEC_RUNNER=1, which tells Mspec that the specs are being run by Mspec,
not Rspec. However, Mspec also sets RUBY_EXE and RUBY_OPTIONS, to the
values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command line options (I am adding these right now) use the ruby_exe
helper. This helper starts a new process of the currently running
implementation to run the specified command or file. Using the outer
layer with -t and -T ensures that these specs are run on the proper
implementation and options. I know that the implementation attempts to
be inferred via other means (RUBY_NAME, RUBY_PLATFORM), but the options
are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to get things set up, and if you set things up correctly (using
~/.mspecrc and setting /path/to/mspec/bin in your PATH) you can run a
spec file as easily as mspec ci core/array/pack (to run
core/array/pack_spec.rb). You have to make sure set :target,
“/path/to/ir.exe” and set :prefix, “path/to/rubyspec” are set in
~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am running the head version directly from rubyspecs github: “d482804
Added should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius) for each test run. So there is no point in debugging the
initial process.

Shri, on my machine your instructions below result in “unknown: Unable
to find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works pretty well for me. If the paths are incorrect, feel free to
update the wiki.

Debugging with Visual Studio
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: “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
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
    “supports /i for ignoring case” -fs -V -B
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsub_spec.rb
    Hitting F5 should now run the single RubySpec example under VS

Thanks,
Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#14

I have updated the wiki. Let me know if this doesn’t make sense or
doesn’t
work for someone…

http://wiki.github.com/ironruby/ironruby

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Monday,23 February 23, 2009 08:52
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The convenience of being able to hit F5 in an existing VS session and
getting to the breakpoint you have previously set will be worth the pain
of
setting it up for some folks. With mspec and Jimmy’s wrapper (which is
also
documented on the wiki), you have to edit the Ruby files you are
debugging
(which will require doing “tf edit” first), will launch a new VS session
which can be slow, won’t allow setting conditional breakpoints easily,
wont
show unexpected exceptions prior to the sleep/attach which might be
triggering a failure later on, etc. Having options is a good thing so
people
can chose whatever works best for them.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday, February 23, 2009 12:00 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

In my opinion, the most future proof way is going to be using the
standard
runner (mspec) and a sleep, or using Jimmy’s debugger wrapper.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Sunday, February 22, 2009 11:09 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I did have to play with a bunch of settings to get mspec to work under
VS,
and its possible that I have set some setting that I am now forgetting,
but
I do not have RUBY_EXE set, and I don’t seem to have a .mspecrc file
either.
Could you please update http://wiki.github.com/ironruby/ironruby with
the
exact step you took to enable you to debug with VS so that others don’t
have
to go through the same issues?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Sunday, February 22, 2009 1:29 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

OK so I worked it out.

Mspec-run does indeed run only a single process but it still requires
mspec/lib/mspec/helpers/ruby_exe.rb. This file tries to set a constant
called RUBY_EXE but it is not able to do so: It tries to guess it from
various environment, constant and config settings. Since ir does not
set
RUBY_NAME you have to do something like set the environment variable
RUBY_EXE or have a ~/.mspecrc file that specifies the :target => … and
so
on.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Thursday,19 February 19, 2009 18:09
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

All the versions that IronRuby has used, have the outer layer CRuby
process
kick off a target implementation process. If you call mspec -fs core -t
“ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For many of
the
specs, you can skip the outer layer, and run mspec-run (or mspec-ci, or
mspec-tag) directly. For debugging, this is what Shri is talking about.

As a side note, I advise not doing it this way in general, since there
are
environment variables set via the outer layer runner, which will affect
the
operation of Mspec. Until now, it has only been MSPEC_RUNNER=1, which
tells
Mspec that the specs are being run by Mspec, not Rspec. However, Mspec
also
sets RUBY_EXE and RUBY_OPTIONS, to the values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command
line options (I am adding these right now) use the ruby_exe helper. This
helper starts a new process of the currently running implementation to
run
the specified command or file. Using the outer layer with -t and -T
ensures
that these specs are run on the proper implementation and options. I
know
that the implementation attempts to be inferred via other means
(RUBY_NAME,
RUBY_PLATFORM), but the options are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to
get things set up, and if you set things up correctly (using ~/.mspecrc
and
setting /path/to/mspec/bin in your PATH) you can run a spec file as
easily
as mspec ci core/array/pack (to run core/array/pack_spec.rb). You have
to
make sure set :target, “/path/to/ir.exe” and set :prefix,
“path/to/rubyspec”
are set in ~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am
running the head version directly from rubyspecs github: “d482804 Added
should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius)
for each test run. So there is no point in debugging the initial
process.

Shri, on my machine your instructions below result in “unknown: Unable
to
find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same
problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works
pretty well for me. If the paths are incorrect, feel free to update the
wiki.

Debugging with Visual Studio

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: “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
c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
“supports /i for ignoring case” -fs -V -B
c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsu
b_spec.rb

Hitting F5 should now run the single RubySpec example under VS

Thanks,

Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks
on a call to System::Diagnostics::Debugger when a debugger is attached
to
the app. Unfortunately this breaks in a Ruby method, so you have to jump
up
a couple CLR frames to get to the line directly after the “debugger”
call,
and I’m not sure of a way how to do that automatically. Anyway, this
works
great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest
and attach to the process while it is waiting. It does totally kill the
computer performance while you are debugging (like minutes to step
through
each line!)

Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I
just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.

Pete


#15

I made some corrections and added a point:

  •     Mspec doesn't spawn each spec under a new process, just the 
    

mspec-run command. This doesn’t prevent corruption of specs, which is
why there is the conflicts_with guard. It’s also why you should run core
before library specs if you are doing a full run (Complex conflicts with
most Numeric subclasses).

  •     If you are setting RUBY_EXE, you should also set RUBY_FLAGS. 
    

The latter is the options passed to the implementation, and sense you
are suggesting adding -X:Interpret to the command, you’ll want
RUBY_FLAGS set to “-X:Interpret”, so that the specs run under ruby_exe
get the correct runner.

  •     We should also figure out how to debug a spec that uses 
    

ruby_exe and add that to the wiki. It will probably come down to
translating the ruby_exe method into the command line that gets called,
but there might be another way.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Monday, February 23, 2009 6:56 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I have updated the wiki. Let me know if this doesn’t make sense or
doesn’t work for someone…
http://wiki.github.com/ironruby/ironruby

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Monday,23 February 23, 2009 08:52
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The convenience of being able to hit F5 in an existing VS session and
getting to the breakpoint you have previously set will be worth the pain
of setting it up for some folks. With mspec and Jimmy’s wrapper (which
is also documented on the wiki), you have to edit the Ruby files you are
debugging (which will require doing “tf edit” first), will launch a new
VS session which can be slow, won’t allow setting conditional
breakpoints easily, wont show unexpected exceptions prior to the
sleep/attach which might be triggering a failure later on, etc. Having
options is a good thing so people can chose whatever works best for
them.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday, February 23, 2009 12:00 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

In my opinion, the most future proof way is going to be using the
standard runner (mspec) and a sleep, or using Jimmy’s debugger wrapper.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Sunday, February 22, 2009 11:09 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I did have to play with a bunch of settings to get mspec to work under
VS, and its possible that I have set some setting that I am now
forgetting, but I do not have RUBY_EXE set, and I don’t seem to have a
.mspecrc file either. Could you please update
http://wiki.github.com/ironruby/ironruby with the exact step you took to
enable you to debug with VS so that others don’t have to go through the
same issues?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Sunday, February 22, 2009 1:29 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

OK so I worked it out.

Mspec-run does indeed run only a single process but it still requires
mspec/lib/mspec/helpers/ruby_exe.rb. This file tries to set a constant
called RUBY_EXE but it is not able to do so: It tries to guess it from
various environment, constant and config settings. Since ir does not
set RUBY_NAME you have to do something like set the environment variable
RUBY_EXE or have a ~/.mspecrc file that specifies the :target => … and
so on.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Thursday,19 February 19, 2009 18:09
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

All the versions that IronRuby has used, have the outer layer CRuby
process kick off a target implementation process. If you call mspec -fs
core -t “ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For
many of the specs, you can skip the outer layer, and run mspec-run (or
mspec-ci, or mspec-tag) directly. For debugging, this is what Shri is
talking about.

As a side note, I advise not doing it this way in general, since there
are environment variables set via the outer layer runner, which will
affect the operation of Mspec. Until now, it has only been
MSPEC_RUNNER=1, which tells Mspec that the specs are being run by Mspec,
not Rspec. However, Mspec also sets RUBY_EXE and RUBY_OPTIONS, to the
values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command line options (I am adding these right now) use the ruby_exe
helper. This helper starts a new process of the currently running
implementation to run the specified command or file. Using the outer
layer with -t and -T ensures that these specs are run on the proper
implementation and options. I know that the implementation attempts to
be inferred via other means (RUBY_NAME, RUBY_PLATFORM), but the options
are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to get things set up, and if you set things up correctly (using
~/.mspecrc and setting /path/to/mspec/bin in your PATH) you can run a
spec file as easily as mspec ci core/array/pack (to run
core/array/pack_spec.rb). You have to make sure set :target,
“/path/to/ir.exe” and set :prefix, “path/to/rubyspec” are set in
~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am running the head version directly from rubyspecs github: “d482804
Added should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius) for each test run. So there is no point in debugging the
initial process.

Shri, on my machine your instructions below result in “unknown: Unable
to find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works pretty well for me. If the paths are incorrect, feel free to
update the wiki.

Debugging with Visual Studio
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: “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
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
    “supports /i for ignoring case” -fs -V -B
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsub_spec.rb
    Hitting F5 should now run the single RubySpec example under VS

Thanks,
Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#16

Well, mspec takes all the arguments on the command line. I wouldn’t want
to specify all of the options 2x. Once as the runner, and once as
arguments.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Monday, February 23, 2009 10:13 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

That is a comprehensive description!

Its unfortunate it has to be as complex. Ideally, mspec-run will take
all arguments (like the ruby executable) on the command line which will
increase discoverability. But for now, the workarounds will do.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Monday, February 23, 2009 6:56 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I have updated the wiki. Let me know if this doesn’t make sense or
doesn’t work for someone…
http://wiki.github.com/ironruby/ironruby

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Monday,23 February 23, 2009 08:52
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The convenience of being able to hit F5 in an existing VS session and
getting to the breakpoint you have previously set will be worth the pain
of setting it up for some folks. With mspec and Jimmy’s wrapper (which
is also documented on the wiki), you have to edit the Ruby files you are
debugging (which will require doing “tf edit” first), will launch a new
VS session which can be slow, won’t allow setting conditional
breakpoints easily, wont show unexpected exceptions prior to the
sleep/attach which might be triggering a failure later on, etc. Having
options is a good thing so people can chose whatever works best for
them.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday, February 23, 2009 12:00 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

In my opinion, the most future proof way is going to be using the
standard runner (mspec) and a sleep, or using Jimmy’s debugger wrapper.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Sunday, February 22, 2009 11:09 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I did have to play with a bunch of settings to get mspec to work under
VS, and its possible that I have set some setting that I am now
forgetting, but I do not have RUBY_EXE set, and I don’t seem to have a
.mspecrc file either. Could you please update
http://wiki.github.com/ironruby/ironruby with the exact step you took to
enable you to debug with VS so that others don’t have to go through the
same issues?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Sunday, February 22, 2009 1:29 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

OK so I worked it out.

Mspec-run does indeed run only a single process but it still requires
mspec/lib/mspec/helpers/ruby_exe.rb. This file tries to set a constant
called RUBY_EXE but it is not able to do so: It tries to guess it from
various environment, constant and config settings. Since ir does not
set RUBY_NAME you have to do something like set the environment variable
RUBY_EXE or have a ~/.mspecrc file that specifies the :target => … and
so on.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Thursday,19 February 19, 2009 18:09
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

All the versions that IronRuby has used, have the outer layer CRuby
process kick off a target implementation process. If you call mspec -fs
core -t “ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For
many of the specs, you can skip the outer layer, and run mspec-run (or
mspec-ci, or mspec-tag) directly. For debugging, this is what Shri is
talking about.

As a side note, I advise not doing it this way in general, since there
are environment variables set via the outer layer runner, which will
affect the operation of Mspec. Until now, it has only been
MSPEC_RUNNER=1, which tells Mspec that the specs are being run by Mspec,
not Rspec. However, Mspec also sets RUBY_EXE and RUBY_OPTIONS, to the
values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command line options (I am adding these right now) use the ruby_exe
helper. This helper starts a new process of the currently running
implementation to run the specified command or file. Using the outer
layer with -t and -T ensures that these specs are run on the proper
implementation and options. I know that the implementation attempts to
be inferred via other means (RUBY_NAME, RUBY_PLATFORM), but the options
are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to get things set up, and if you set things up correctly (using
~/.mspecrc and setting /path/to/mspec/bin in your PATH) you can run a
spec file as easily as mspec ci core/array/pack (to run
core/array/pack_spec.rb). You have to make sure set :target,
“/path/to/ir.exe” and set :prefix, “path/to/rubyspec” are set in
~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am running the head version directly from rubyspecs github: “d482804
Added should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius) for each test run. So there is no point in debugging the
initial process.

Shri, on my machine your instructions below result in “unknown: Unable
to find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works pretty well for me. If the paths are incorrect, feel free to
update the wiki.

Debugging with Visual Studio
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: “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
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
    “supports /i for ignoring case” -fs -V -B
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsub_spec.rb
    Hitting F5 should now run the single RubySpec example under VS

Thanks,
Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#17

That is a comprehensive description!

Its unfortunate it has to be as complex. Ideally, mspec-run will take
all arguments (like the ruby executable) on the command line which will
increase discoverability. But for now, the workarounds will do.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Monday, February 23, 2009 6:56 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I have updated the wiki. Let me know if this doesn’t make sense or
doesn’t work for someone…
http://wiki.github.com/ironruby/ironruby

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Monday,23 February 23, 2009 08:52
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The convenience of being able to hit F5 in an existing VS session and
getting to the breakpoint you have previously set will be worth the pain
of setting it up for some folks. With mspec and Jimmy’s wrapper (which
is also documented on the wiki), you have to edit the Ruby files you are
debugging (which will require doing “tf edit” first), will launch a new
VS session which can be slow, won’t allow setting conditional
breakpoints easily, wont show unexpected exceptions prior to the
sleep/attach which might be triggering a failure later on, etc. Having
options is a good thing so people can chose whatever works best for
them.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday, February 23, 2009 12:00 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

In my opinion, the most future proof way is going to be using the
standard runner (mspec) and a sleep, or using Jimmy’s debugger wrapper.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Sunday, February 22, 2009 11:09 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I did have to play with a bunch of settings to get mspec to work under
VS, and its possible that I have set some setting that I am now
forgetting, but I do not have RUBY_EXE set, and I don’t seem to have a
.mspecrc file either. Could you please update
http://wiki.github.com/ironruby/ironruby with the exact step you took to
enable you to debug with VS so that others don’t have to go through the
same issues?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Sunday, February 22, 2009 1:29 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

OK so I worked it out.

Mspec-run does indeed run only a single process but it still requires
mspec/lib/mspec/helpers/ruby_exe.rb. This file tries to set a constant
called RUBY_EXE but it is not able to do so: It tries to guess it from
various environment, constant and config settings. Since ir does not
set RUBY_NAME you have to do something like set the environment variable
RUBY_EXE or have a ~/.mspecrc file that specifies the :target => … and
so on.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Thursday,19 February 19, 2009 18:09
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

All the versions that IronRuby has used, have the outer layer CRuby
process kick off a target implementation process. If you call mspec -fs
core -t “ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For
many of the specs, you can skip the outer layer, and run mspec-run (or
mspec-ci, or mspec-tag) directly. For debugging, this is what Shri is
talking about.

As a side note, I advise not doing it this way in general, since there
are environment variables set via the outer layer runner, which will
affect the operation of Mspec. Until now, it has only been
MSPEC_RUNNER=1, which tells Mspec that the specs are being run by Mspec,
not Rspec. However, Mspec also sets RUBY_EXE and RUBY_OPTIONS, to the
values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command line options (I am adding these right now) use the ruby_exe
helper. This helper starts a new process of the currently running
implementation to run the specified command or file. Using the outer
layer with -t and -T ensures that these specs are run on the proper
implementation and options. I know that the implementation attempts to
be inferred via other means (RUBY_NAME, RUBY_PLATFORM), but the options
are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to get things set up, and if you set things up correctly (using
~/.mspecrc and setting /path/to/mspec/bin in your PATH) you can run a
spec file as easily as mspec ci core/array/pack (to run
core/array/pack_spec.rb). You have to make sure set :target,
“/path/to/ir.exe” and set :prefix, “path/to/rubyspec” are set in
~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am running the head version directly from rubyspecs github: “d482804
Added should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius) for each test run. So there is no point in debugging the
initial process.

Shri, on my machine your instructions below result in “unknown: Unable
to find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works pretty well for me. If the paths are incorrect, feel free to
update the wiki.

Debugging with Visual Studio
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: “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
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
    “supports /i for ignoring case” -fs -V -B
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsub_spec.rb
    Hitting F5 should now run the single RubySpec example under VS

Thanks,
Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#18

Sadly I don’t think that mspec-run looks at the standard command line
options for specifying the target implementation. I tried specifying
set
:target, … in my ~/.mspecrc file but it didn’t help.

To be honest, this is really a bug in mspec-run. It should not actually
require ruby_exe.rb at all as it doesn’t use it. It should only really
be
used when it is spawning off new processes.

There is an alternative solution which requires a change to the
rbconfig.rb
file inside the standard libraries. The ruby_exe.rb file will look into
this configuration class and pull out the following to calculate the
path to
the ruby exectuble.

  bin = Config::CONFIG["RUBY_INSTALL_NAME"] ||

Config::CONFIG[“ruby_install_name”]

  bin << (Config::CONFIG['EXEEXT'] || Config::CONFIG['exeext'] || 

‘’)

  File.join(Config::CONFIG['bindir'], bin)

If the version of rbconfig.rb that is shipped with IronRuby was
correctly
set up then this would work automatically for everyone. This is exactly
how
the standard MRI version works when it requires ruby_exe.rb.

Currently the version of rbconfig.rb that is included via the
ir.exe.config
is found in Merlin/Main/Languages/Ruby/Libs/rbconfig.rb and specifies
the
following:

TODO: Temporary hack to locate where we are based on relative MERLIN

layout paths. We will replace this with just the path to this file

when

we build out the Ruby/libs directory to contain our own private copy

of

the Ruby libraries

Note that this symbol should be redefined by the packaging script

for
binary

layouts TOPDIR = File.dirname(FILE) +

‘/…/…/…/…/External/languages/ruby/ruby-1.8.6/’

CONFIG[“prefix”] = (TOPDIR || DESTDIR + “”)

CONFIG[“exec_prefix”] = “$(prefix)”

CONFIG[“bindir”] = “$(exec_prefix)/bin”

TODO: change back to ironruby

CONFIG[“ruby_install_name”] = “ruby”

CONFIG[“RUBY_INSTALL_NAME”] = “ruby”

END TODO:

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday,23 February 23, 2009 19:00
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Well, mspec takes all the arguments on the command line. I wouldn’t want
to
specify all of the options 2x. Once as the runner, and once as
arguments.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Monday, February 23, 2009 10:13 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

That is a comprehensive description!

Its unfortunate it has to be as complex. Ideally, mspec-run will take
all
arguments (like the ruby executable) on the command line which will
increase
discoverability. But for now, the workarounds will do.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Monday, February 23, 2009 6:56 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I have updated the wiki. Let me know if this doesn’t make sense or
doesn’t
work for someone…

http://wiki.github.com/ironruby/ironruby

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Monday,23 February 23, 2009 08:52
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The convenience of being able to hit F5 in an existing VS session and
getting to the breakpoint you have previously set will be worth the pain
of
setting it up for some folks. With mspec and Jimmy’s wrapper (which is
also
documented on the wiki), you have to edit the Ruby files you are
debugging
(which will require doing “tf edit” first), will launch a new VS session
which can be slow, won’t allow setting conditional breakpoints easily,
wont
show unexpected exceptions prior to the sleep/attach which might be
triggering a failure later on, etc. Having options is a good thing so
people
can chose whatever works best for them.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday, February 23, 2009 12:00 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

In my opinion, the most future proof way is going to be using the
standard
runner (mspec) and a sleep, or using Jimmy’s debugger wrapper.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Sunday, February 22, 2009 11:09 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I did have to play with a bunch of settings to get mspec to work under
VS,
and its possible that I have set some setting that I am now forgetting,
but
I do not have RUBY_EXE set, and I don’t seem to have a .mspecrc file
either.
Could you please update http://wiki.github.com/ironruby/ironruby with
the
exact step you took to enable you to debug with VS so that others don’t
have
to go through the same issues?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Sunday, February 22, 2009 1:29 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

OK so I worked it out.

Mspec-run does indeed run only a single process but it still requires
mspec/lib/mspec/helpers/ruby_exe.rb. This file tries to set a constant
called RUBY_EXE but it is not able to do so: It tries to guess it from
various environment, constant and config settings. Since ir does not
set
RUBY_NAME you have to do something like set the environment variable
RUBY_EXE or have a ~/.mspecrc file that specifies the :target => … and
so
on.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Thursday,19 February 19, 2009 18:09
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

All the versions that IronRuby has used, have the outer layer CRuby
process
kick off a target implementation process. If you call mspec -fs core -t
“ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For many of
the
specs, you can skip the outer layer, and run mspec-run (or mspec-ci, or
mspec-tag) directly. For debugging, this is what Shri is talking about.

As a side note, I advise not doing it this way in general, since there
are
environment variables set via the outer layer runner, which will affect
the
operation of Mspec. Until now, it has only been MSPEC_RUNNER=1, which
tells
Mspec that the specs are being run by Mspec, not Rspec. However, Mspec
also
sets RUBY_EXE and RUBY_OPTIONS, to the values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command
line options (I am adding these right now) use the ruby_exe helper. This
helper starts a new process of the currently running implementation to
run
the specified command or file. Using the outer layer with -t and -T
ensures
that these specs are run on the proper implementation and options. I
know
that the implementation attempts to be inferred via other means
(RUBY_NAME,
RUBY_PLATFORM), but the options are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to
get things set up, and if you set things up correctly (using ~/.mspecrc
and
setting /path/to/mspec/bin in your PATH) you can run a spec file as
easily
as mspec ci core/array/pack (to run core/array/pack_spec.rb). You have
to
make sure set :target, “/path/to/ir.exe” and set :prefix,
“path/to/rubyspec”
are set in ~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am
running the head version directly from rubyspecs github: “d482804 Added
should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius)
for each test run. So there is no point in debugging the initial
process.

Shri, on my machine your instructions below result in “unknown: Unable
to
find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same
problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works
pretty well for me. If the paths are incorrect, feel free to update the
wiki.

Debugging with Visual Studio

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: “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
c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
“supports /i for ignoring case” -fs -V -B
c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsu
b_spec.rb

Hitting F5 should now run the single RubySpec example under VS

Thanks,

Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks
on a call to System::Diagnostics::Debugger when a debugger is attached
to
the app. Unfortunately this breaks in a Ruby method, so you have to jump
up
a couple CLR frames to get to the line directly after the “debugger”
call,
and I’m not sure of a way how to do that automatically. Anyway, this
works
great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest
and attach to the process while it is waiting. It does totally kill the
computer performance while you are debugging (like minutes to step
through
each line!)

Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I
just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.

Pete


#19

Yeah, that is correct. -t and -T, and set :target are used by MSpec, not
mspec-run (and it’s sibling scripts).

As for not using ruby_exe, it is used in various specs, and all of the
command line specs I am writing. It’s not directly required by
mspec-run, it gets required during the loading of the rest of mspec. I
feel that ruby_exe is part of MSpec, just like should, the matchers, and
the other helpers.

I agree that it would be nice to get rbconfig set up correctly, in
addition to RUBY_NAME. However, it does appear that RUBY_NAME is set to
RUBY_ENGINE if RUBY_NAME isn’t defined.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Monday, February 23, 2009 12:34 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Sadly I don’t think that mspec-run looks at the standard command line
options for specifying the target implementation. I tried specifying
set :target, … in my ~/.mspecrc file but it didn’t help.

To be honest, this is really a bug in mspec-run. It should not actually
require ruby_exe.rb at all as it doesn’t use it. It should only really
be used when it is spawning off new processes.

There is an alternative solution which requires a change to the
rbconfig.rb file inside the standard libraries. The ruby_exe.rb file
will look into this configuration class and pull out the following to
calculate the path to the ruby exectuble.

  bin = Config::CONFIG["RUBY_INSTALL_NAME"] || 

Config::CONFIG[“ruby_install_name”]
bin << (Config::CONFIG[‘EXEEXT’] || Config::CONFIG[‘exeext’] ||
‘’)
File.join(Config::CONFIG[‘bindir’], bin)

If the version of rbconfig.rb that is shipped with IronRuby was
correctly set up then this would work automatically for everyone. This
is exactly how the standard MRI version works when it requires
ruby_exe.rb.

Currently the version of rbconfig.rb that is included via the
ir.exe.config is found in Merlin/Main/Languages/Ruby/Libs/rbconfig.rb
and specifies the following:

TODO: Temporary hack to locate where we are based on relative MERLIN

layout paths. We will replace this with just the path to this file

when

we build out the Ruby/libs directory to contain our own private copy

of

the Ruby libraries

Note that this symbol should be redefined by the packaging script

for binary

layouts TOPDIR = File.dirname(FILE) +

‘/…/…/…/…/External/languages/ruby/ruby-1.8.6/’
CONFIG[“prefix”] = (TOPDIR || DESTDIR + “”)
CONFIG[“exec_prefix”] = “$(prefix)”
CONFIG[“bindir”] = “$(exec_prefix)/bin”

TODO: change back to ironruby

CONFIG[“ruby_install_name”] = “ruby”
CONFIG[“RUBY_INSTALL_NAME”] = “ruby”

END TODO:

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday,23 February 23, 2009 19:00
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Well, mspec takes all the arguments on the command line. I wouldn’t want
to specify all of the options 2x. Once as the runner, and once as
arguments.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Monday, February 23, 2009 10:13 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

That is a comprehensive description!

Its unfortunate it has to be as complex. Ideally, mspec-run will take
all arguments (like the ruby executable) on the command line which will
increase discoverability. But for now, the workarounds will do.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Monday, February 23, 2009 6:56 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I have updated the wiki. Let me know if this doesn’t make sense or
doesn’t work for someone…
http://wiki.github.com/ironruby/ironruby

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Monday,23 February 23, 2009 08:52
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The convenience of being able to hit F5 in an existing VS session and
getting to the breakpoint you have previously set will be worth the pain
of setting it up for some folks. With mspec and Jimmy’s wrapper (which
is also documented on the wiki), you have to edit the Ruby files you are
debugging (which will require doing “tf edit” first), will launch a new
VS session which can be slow, won’t allow setting conditional
breakpoints easily, wont show unexpected exceptions prior to the
sleep/attach which might be triggering a failure later on, etc. Having
options is a good thing so people can chose whatever works best for
them.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday, February 23, 2009 12:00 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

In my opinion, the most future proof way is going to be using the
standard runner (mspec) and a sleep, or using Jimmy’s debugger wrapper.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Sunday, February 22, 2009 11:09 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I did have to play with a bunch of settings to get mspec to work under
VS, and its possible that I have set some setting that I am now
forgetting, but I do not have RUBY_EXE set, and I don’t seem to have a
.mspecrc file either. Could you please update
http://wiki.github.com/ironruby/ironruby with the exact step you took to
enable you to debug with VS so that others don’t have to go through the
same issues?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Sunday, February 22, 2009 1:29 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

OK so I worked it out.

Mspec-run does indeed run only a single process but it still requires
mspec/lib/mspec/helpers/ruby_exe.rb. This file tries to set a constant
called RUBY_EXE but it is not able to do so: It tries to guess it from
various environment, constant and config settings. Since ir does not
set RUBY_NAME you have to do something like set the environment variable
RUBY_EXE or have a ~/.mspecrc file that specifies the :target => … and
so on.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Thursday,19 February 19, 2009 18:09
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

All the versions that IronRuby has used, have the outer layer CRuby
process kick off a target implementation process. If you call mspec -fs
core -t “ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For
many of the specs, you can skip the outer layer, and run mspec-run (or
mspec-ci, or mspec-tag) directly. For debugging, this is what Shri is
talking about.

As a side note, I advise not doing it this way in general, since there
are environment variables set via the outer layer runner, which will
affect the operation of Mspec. Until now, it has only been
MSPEC_RUNNER=1, which tells Mspec that the specs are being run by Mspec,
not Rspec. However, Mspec also sets RUBY_EXE and RUBY_OPTIONS, to the
values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command line options (I am adding these right now) use the ruby_exe
helper. This helper starts a new process of the currently running
implementation to run the specified command or file. Using the outer
layer with -t and -T ensures that these specs are run on the proper
implementation and options. I know that the implementation attempts to
be inferred via other means (RUBY_NAME, RUBY_PLATFORM), but the options
are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to get things set up, and if you set things up correctly (using
~/.mspecrc and setting /path/to/mspec/bin in your PATH) you can run a
spec file as easily as mspec ci core/array/pack (to run
core/array/pack_spec.rb). You have to make sure set :target,
“/path/to/ir.exe” and set :prefix, “path/to/rubyspec” are set in
~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am running the head version directly from rubyspecs github: “d482804
Added should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius) for each test run. So there is no point in debugging the
initial process.

Shri, on my machine your instructions below result in “unknown: Unable
to find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works pretty well for me. If the paths are incorrect, feel free to
update the wiki.

Debugging with Visual Studio
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: “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
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
    “supports /i for ignoring case” -fs -V -B
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsub_spec.rb
    Hitting F5 should now run the single RubySpec example under VS

Thanks,
Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete


#20

So something that does what mspec does, without the new process? I
wonder if we could just make mspec not spawn a new process if the
running Ruby is the same as the target ruby. We would still need to pass
-T and -t, thus specifying the args 2x, but I think that it is better
than maintaining a separate script if something changes in MSpec.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Monday, February 23, 2009 11:21 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Oops yeah I forgot that ruby_exe is probably used in some of the
rubyspecs. How about we knock up a small ruby file that sets everything
up and passes through to mspec-run that we can just run directly without
any command line arguments from VS debugger?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday,23 February 23, 2009 22:29
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Yeah, that is correct. -t and -T, and set :target are used by MSpec, not
mspec-run (and it’s sibling scripts).

As for not using ruby_exe, it is used in various specs, and all of the
command line specs I am writing. It’s not directly required by
mspec-run, it gets required during the loading of the rest of mspec. I
feel that ruby_exe is part of MSpec, just like should, the matchers, and
the other helpers.

I agree that it would be nice to get rbconfig set up correctly, in
addition to RUBY_NAME. However, it does appear that RUBY_NAME is set to
RUBY_ENGINE if RUBY_NAME isn’t defined.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Monday, February 23, 2009 12:34 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Sadly I don’t think that mspec-run looks at the standard command line
options for specifying the target implementation. I tried specifying
set :target, … in my ~/.mspecrc file but it didn’t help.

To be honest, this is really a bug in mspec-run. It should not actually
require ruby_exe.rb at all as it doesn’t use it. It should only really
be used when it is spawning off new processes.

There is an alternative solution which requires a change to the
rbconfig.rb file inside the standard libraries. The ruby_exe.rb file
will look into this configuration class and pull out the following to
calculate the path to the ruby exectuble.

  bin = Config::CONFIG["RUBY_INSTALL_NAME"] || 

Config::CONFIG[“ruby_install_name”]
bin << (Config::CONFIG[‘EXEEXT’] || Config::CONFIG[‘exeext’] ||
‘’)
File.join(Config::CONFIG[‘bindir’], bin)

If the version of rbconfig.rb that is shipped with IronRuby was
correctly set up then this would work automatically for everyone. This
is exactly how the standard MRI version works when it requires
ruby_exe.rb.

Currently the version of rbconfig.rb that is included via the
ir.exe.config is found in Merlin/Main/Languages/Ruby/Libs/rbconfig.rb
and specifies the following:

TODO: Temporary hack to locate where we are based on relative MERLIN

layout paths. We will replace this with just the path to this file

when

we build out the Ruby/libs directory to contain our own private copy

of

the Ruby libraries

Note that this symbol should be redefined by the packaging script

for binary

layouts TOPDIR = File.dirname(FILE) +

‘/…/…/…/…/External/languages/ruby/ruby-1.8.6/’
CONFIG[“prefix”] = (TOPDIR || DESTDIR + “”)
CONFIG[“exec_prefix”] = “$(prefix)”
CONFIG[“bindir”] = “$(exec_prefix)/bin”

TODO: change back to ironruby

CONFIG[“ruby_install_name”] = “ruby”
CONFIG[“RUBY_INSTALL_NAME”] = “ruby”

END TODO:

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday,23 February 23, 2009 19:00
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Well, mspec takes all the arguments on the command line. I wouldn’t want
to specify all of the options 2x. Once as the runner, and once as
arguments.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Monday, February 23, 2009 10:13 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

That is a comprehensive description!

Its unfortunate it has to be as complex. Ideally, mspec-run will take
all arguments (like the ruby executable) on the command line which will
increase discoverability. But for now, the workarounds will do.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Monday, February 23, 2009 6:56 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I have updated the wiki. Let me know if this doesn’t make sense or
doesn’t work for someone…
http://wiki.github.com/ironruby/ironruby

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Monday,23 February 23, 2009 08:52
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The convenience of being able to hit F5 in an existing VS session and
getting to the breakpoint you have previously set will be worth the pain
of setting it up for some folks. With mspec and Jimmy’s wrapper (which
is also documented on the wiki), you have to edit the Ruby files you are
debugging (which will require doing “tf edit” first), will launch a new
VS session which can be slow, won’t allow setting conditional
breakpoints easily, wont show unexpected exceptions prior to the
sleep/attach which might be triggering a failure later on, etc. Having
options is a good thing so people can chose whatever works best for
them.

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Monday, February 23, 2009 12:00 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

In my opinion, the most future proof way is going to be using the
standard runner (mspec) and a sleep, or using Jimmy’s debugger wrapper.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Sunday, February 22, 2009 11:09 PM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

I did have to play with a bunch of settings to get mspec to work under
VS, and its possible that I have set some setting that I am now
forgetting, but I do not have RUBY_EXE set, and I don’t seem to have a
.mspecrc file either. Could you please update
http://wiki.github.com/ironruby/ironruby with the exact step you took to
enable you to debug with VS so that others don’t have to go through the
same issues?

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Sunday, February 22, 2009 1:29 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

OK so I worked it out.

Mspec-run does indeed run only a single process but it still requires
mspec/lib/mspec/helpers/ruby_exe.rb. This file tries to set a constant
called RUBY_EXE but it is not able to do so: It tries to guess it from
various environment, constant and config settings. Since ir does not
set RUBY_NAME you have to do something like set the environment variable
RUBY_EXE or have a ~/.mspecrc file that specifies the :target => … and
so on.

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jim D.
Sent: Thursday,19 February 19, 2009 18:09
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

All the versions that IronRuby has used, have the outer layer CRuby
process kick off a target implementation process. If you call mspec -fs
core -t “ir.exe”, it becomes a call to ir.exe mspec-run -fs core. For
many of the specs, you can skip the outer layer, and run mspec-run (or
mspec-ci, or mspec-tag) directly. For debugging, this is what Shri is
talking about.

As a side note, I advise not doing it this way in general, since there
are environment variables set via the outer layer runner, which will
affect the operation of Mspec. Until now, it has only been
MSPEC_RUNNER=1, which tells Mspec that the specs are being run by Mspec,
not Rspec. However, Mspec also sets RUBY_EXE and RUBY_OPTIONS, to the
values of the -t and -T flags.

Now that ir -e works (I will be pushing the new revision today), these
variables will affect the operation of the specs. Many of the specs that
test top level code, depend on testing a fresh process, or test the
command line options (I am adding these right now) use the ruby_exe
helper. This helper starts a new process of the currently running
implementation to run the specified command or file. Using the outer
layer with -t and -T ensures that these specs are run on the proper
implementation and options. I know that the implementation attempts to
be inferred via other means (RUBY_NAME, RUBY_PLATFORM), but the options
are not as easily taken care of.

The wiki (http://wiki.github.com/ironruby/ironruby/rubyspec) tells how
to get things set up, and if you set things up correctly (using
~/.mspecrc and setting /path/to/mspec/bin in your PATH) you can run a
spec file as easily as mspec ci core/array/pack (to run
core/array/pack_spec.rb). You have to make sure set :target,
“/path/to/ir.exe” and set :prefix, “path/to/rubyspec” are set in
~/.mspecrc, from there it should just work.

Let me know if you have more questions on any of this.

JD

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Thursday, February 19, 2009 6:21 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Hi Shri and Jimmy,

Thanks for the suggestions. What version of mspec are you running? I
am running the head version directly from rubyspecs github: “d482804
Added should have_constant matcher.”

In my version, the initial ruby process kicks off a new ruby process
(potentially a completely different implementation, like JRuby or
Rubinius) for each test run. So there is no point in debugging the
initial process.

Shri, on my machine your instructions below result in “unknown: Unable
to find a suitable ruby executable. (Exception)”, which I guess is mspec
telling me it couldn’t load ir.exe or equivalent as a sub-process for
executing the spec.

Jimmy, how do you attach to the mspec process in the first place? The
same problem as above is true for just debugging mspec run …

Pete

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Shri B.
Sent: Wednesday,18 February 18, 2009 17:59
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

Here is what I added to http://wiki.github.com/ironruby/ironruby. This
works pretty well for me. If the paths are incorrect, feel free to
update the wiki.

Debugging with Visual Studio
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: “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
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/mspec/bin/mspec-run -e
    “supports /i for ignoring case” -fs -V -B
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/default.mspec
    c:/vsl/Merlin/External/Languages/IronRuby/mspec/rubyspec/1.8/core/string/gsub_spec.rb
    Hitting F5 should now run the single RubySpec example under VS

Thanks,
Shri

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Jimmy
Schementi
Sent: Wednesday, February 18, 2009 8:52 AM
To: removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

You can pass the spec file to mspec itself like:

mspec run core/io/popen_close

Then I make a call to “debugger” http://gist.github.com/61605, which
breaks on a call to System::Diagnostics::Debugger when a debugger is
attached to the app. Unfortunately this breaks in a Ruby method, so you
have to jump up a couple CLR frames to get to the line directly after
the “debugger” call, and I’m not sure of a way how to do that
automatically. Anyway, this works great.

~js

From: removed_email_address@domain.invalid
[mailto:removed_email_address@domain.invalid] On Behalf Of Pete Bacon
Darwin
Sent: Wednesday, February 18, 2009 8:11 AM
To: ‘Pete Bacon D.’; removed_email_address@domain.invalid
Subject: Re: [Ironruby-core] Debugging rubyspecs

The easiest way it appears is to stick a pause in the rubyspec of
interest and attach to the process while it is waiting. It does totally
kill the computer performance while you are debugging (like minutes to
step through each line!)
Pete

From: Pete Bacon D. [mailto:removed_email_address@domain.invalid]
Sent: Wednesday,18 February 18, 2009 15:19
To: ‘removed_email_address@domain.invalid’
Subject: Debugging rubyspecs

Anybody know how to run rubyspecs under the Visual Studio debugger? If
I just set the rubyspec file as the command line argument in the debug
properties in VS then it just asks me to install mspec as a gem.
Pete