Bug?

Is this a bug…

C:\dev\ruby\ruby-benchmark-suite\benchmarks\rails\substruct>ir
script/console
Loading development environment (Rails 2.3.2)
IronRuby.Libraries:0:in GetExecutable': irb.bat -r irb/completion -r "C:/dev/ruby/ruby-benchmark-suite/benchmarks/rails/substruct/config/environment" -r console_app -r console_with_helpers --simple-prompt (Errno::ENOENT) from IronRuby.Libraries:0:inCreateProcess’
from
C:/dev/ruby/ruby-benchmark-suite/benchmarks/rails/substruct/vendor/rails/railties/lib/commands/console.rb:45:in
`exec’

Thanks.
-rp

Not a bug, see http://ironruby.net/documentation/rails#console. Do ir
script/console=iirb.bat … Basically it’s an unfortunate side-effect of
how Rails implemented this command (they spawn another ruby process
rather than just using IRB directly. Since we don’t ship with irb.bat,
you need to provide the actual name. You can also do iirb
-rconfig/environment, as that’s all script/console really does anyways.

~Jimmy

Jimmy S. wrote:

Not a bug, see http://ironruby.net/documentation/rails#console. Do ir
script/console=iirb.bat … Basically it’s an unfortunate side-effect of
how Rails implemented this command (they spawn another ruby process
rather than just using IRB directly. Since we don’t ship with irb.bat,
you need to provide the actual name. You can also do iirb
-rconfig/environment, as that’s all script/console really does anyways.

Ok sounds good.
A couple of feedback items for the installer, then:

  1. default to a path without spaces, perhaps
  2. have a checkbox for if we want to install with the i prefix or not on
    pre-installed gems (I know I for one wouldn’t).
    Thanks so much.
    -rp

Ok sounds good.
A couple of feedback items for the installer, then:

  1. default to a path without spaces, perhaps

Does installing to “Program Files” actually cause issues? Other than
needing to quote the path to ir.exe?

  1. have a checkbox for if we want to install with the i prefix or not on pre-
    installed gems (I know I for one wouldn’t).

We don’t preinstall any gems with IronRuby. So what you’re asking is an
option so we remove the “i” from “iri.bat”, “irdoc.bat”, and “igem.bat”
? Keep in mind the actual ruby files are still “ri”, “rdoc”, and “gem”.
For the problem with “ir script/console”, rails should fix this (as in,
JRuby has the same problem as they ship with jirb).

Also, I think there’s a way to tell RubyGems to prefix the bat files it
generates, so installing rails would install irails.bat, to keep things
consistent.

Program Files is a protected directory in Vista and Win7. I have run
into
permission issues in the past.

On Tue, May 18, 2010 at 2:52 PM, Jimmy S. <
[email protected]> wrote:

Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core


“The explanation requiring the fewest assumptions is most likely to be
correct.”

Im thinking more of having IIS executing code out of prog files is a bad
idea.

On Tue, May 18, 2010 at 3:30 PM, Jimmy S. <
[email protected]> wrote:

installed gems (I know I for one wouldn’t).

correct."


Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core


“The explanation requiring the fewest assumptions is most likely to be
correct.”

Yes, installing Gems requires you to run as Administrator, just like
installing a gem on MacOS/Linux requires you do sudo. However, we will
fall back to installing gems to the user-dir. I just think there needs
to be better docs about this.

From: [email protected]
[mailto:[email protected]] On Behalf Of Bobby J.
Sent: Tuesday, May 18, 2010 3:21 PM
To: [email protected]
Subject: Re: [Ironruby-core] bug?

Program Files is a protected directory in Vista and Win7. I have run
into permission issues in the past.
On Tue, May 18, 2010 at 2:52 PM, Jimmy S.
<[email protected]mailto:[email protected]>
wrote:

Ok sounds good.
A couple of feedback items for the installer, then:

  1. default to a path without spaces, perhaps
    Does installing to “Program Files” actually cause issues? Other than
    needing to quote the path to ir.exe?
  1. have a checkbox for if we want to install with the i prefix or not on pre-
    installed gems (I know I for one wouldn’t).
    We don’t preinstall any gems with IronRuby. So what you’re asking is an
    option so we remove the “i” from “iri.bat”, “irdoc.bat”, and “igem.bat”
    ? Keep in mind the actual ruby files are still “ri”, “rdoc”, and “gem”.
    For the problem with “ir script/console”, rails should fix this (as in,
    JRuby has the same problem as they ship with jirb).

Also, I think there’s a way to tell RubyGems to prefix the bat files it
generates, so installing rails would install irails.bat, to keep things
consistent.


Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core


“The explanation requiring the fewest assumptions is most likely to be
correct.”

Doesn’t really matter to me. The browse button in the installer is all I
need.

On Tue, May 18, 2010 at 3:50 PM, Jimmy S. <
[email protected]> wrote:

To: [email protected]
Yes, installing Gems requires you to run as Administrator, just like

[email protected]> wrote:
pre-
consistent.
"The explanation requiring the fewest assumptions is most likely to be


Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core


“The explanation requiring the fewest assumptions is most likely to be
correct.”

Jimmy S. wrote:

Ok sounds good.
A couple of feedback items for the installer, then:

  1. default to a path without spaces, perhaps

Does installing to “Program Files” actually cause issues? Other than
needing to quote the path to ir.exe?

I haven’t run into any. I just saw it mentioned somewhere on a wiki
page that it was advised to not install it to a directory with spaces
since some gems don’t like it.

  1. have a checkbox for if we want to install with the i prefix or not on pre-
    installed gems (I know I for one wouldn’t).

We don’t preinstall any gems with IronRuby.

I thought I came with rake for some reason, it doesn’t though, so no
inconsistency there.

So what you’re asking is an

option so we remove the “i” from “iri.bat”, “irdoc.bat”, and “igem.bat”
? Keep in mind the actual ruby files are still “ri”, “rdoc”, and “gem”.
For the problem with “ir script/console”, rails should fix this (as in,
JRuby has the same problem as they ship with jirb).

At first blush it surprised me to have it differ from jruby.

With jruby, you get jruby.exe, jirb.bat, gem.bat, rake.bat, rdoc.bat,
ri.bat

After using it a few times I got used to using “igem” instead of the
normal gem I was used to…

Thanks!
-rp

Giving read-only access to IIS_IUSRS for “C:\Program Files\IronRuby
1.0\lib” is harmless, no? That’s all it would take to get IronRuby.Rack
to work, for example. Let me know why you don’t feel comfortable doing
that.

From: [email protected]
[mailto:[email protected]] On Behalf Of Bobby J.
Sent: Tuesday, May 18, 2010 3:36 PM
To: [email protected]
Subject: Re: [Ironruby-core] bug?

Im thinking more of having IIS executing code out of prog files is a bad
idea.
On Tue, May 18, 2010 at 3:30 PM, Jimmy S.
<[email protected]mailto:[email protected]>
wrote:
Yes, installing Gems requires you to run as Administrator, just like
installing a gem on MacOS/Linux requires you do sudo. However, we will
fall back to installing gems to the user-dir. I just think there needs
to be better docs about this.

From:
[email protected]mailto:[email protected]
[mailto:[email protected]mailto:[email protected]]
On Behalf Of Bobby J.
Sent: Tuesday, May 18, 2010 3:21 PM

To: [email protected]mailto:[email protected]
Subject: Re: [Ironruby-core] bug?

Program Files is a protected directory in Vista and Win7. I have run
into permission issues in the past.
On Tue, May 18, 2010 at 2:52 PM, Jimmy S.
<[email protected]mailto:[email protected]>
wrote:

Ok sounds good.
A couple of feedback items for the installer, then:

  1. default to a path without spaces, perhaps
    Does installing to “Program Files” actually cause issues? Other than
    needing to quote the path to ir.exe?
  1. have a checkbox for if we want to install with the i prefix or not on pre-
    installed gems (I know I for one wouldn’t).
    We don’t preinstall any gems with IronRuby. So what you’re asking is an
    option so we remove the “i” from “iri.bat”, “irdoc.bat”, and “igem.bat”
    ? Keep in mind the actual ruby files are still “ri”, “rdoc”, and “gem”.
    For the problem with “ir script/console”, rails should fix this (as in,
    JRuby has the same problem as they ship with jirb).

Also, I think there’s a way to tell RubyGems to prefix the bat files it
generates, so installing rails would install irails.bat, to keep things
consistent.


Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core


“The explanation requiring the fewest assumptions is most likely to be
correct.”


Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core


“The explanation requiring the fewest assumptions is most likely to be
correct.”

Jimmy S. wrote:

Ok sounds good.
A couple of feedback items for the installer, then:

  1. default to a path without spaces, perhaps

Does installing to “Program Files” actually cause issues? Other than
needing to quote the path to ir.exe?

C:\dev\digitalarchive_trunk>ir -S gem install faster_rubygems
Building native extensions. This could take a while…
ERROR: Error installing faster_rubygems:
ERROR: Failed to build gem native extension.

“C:/Program Files/IronRuby 1.0v4/bin/ir.exe” mkrf_conf.rb
Installed–thank you for trying out faster_rubygems
recreating all faster_rubygems caches
faster_rubygems: creating caches
.
.

“C:/Program Files/IronRuby 1.0v4/bin/ir.exe” -rubygems C:/Program
Files/IronRuby 1.0v4/lib/ironruby/gems/1.8/gems/rake-0.8.7/bin/rake
RUBYARCHDIR=“C:/Program Files/IronRuby
1.0v4/lib/ironruby/gems/1.8/gems/faster_rubygems-0.9.2/lib”
RUBYLIBDIR=“C:/Program Files/IronRuby
1.0v4/lib/ironruby/gems/1.8/gems/faster_rubygems-0.9.2/lib”
unknown: Could not find file ‘C:\Program’. (Errno::ENOENT)

Gem files will remain installed in C:/Program Files/IronRuby
1.0v4/lib/ironruby/gems/1.8/gems/faster_rubygems-0.9.2 for inspection.
Results logged to C:/Program Files/IronRuby
1.0v4/lib/ironruby/gems/1.8/gems/faster_rubygems-0.9.2/ext/gem_make.out

Jimmy S. wrote:

IronRuby doesn’t support faster_rubygems as it contains a c-based
extension compiled against MRI.

faster_rubygems doesn’t contain a c-based extension, it contains a
mkrf_conf.rb file, which ends up being pure ruby, and works fine with
jruby (which also doesn’t support C extensions), hence my expecting it
to work with IR [1].

Perhaps I am mistaken?

-r
[1]
http://en.wikibooks.org/wiki/Ruby_Programming/RubyGems#How_to_use_a_Rakefile_instead_of_a_Makefile

IronRuby doesn’t support faster_rubygems as it contains a c-based
extension compiled against MRI.

That depends on how the platform is determined by mkrf. Can you verify
what
mkrf is using to determine the platform? Here’s a printout of IronRuby’s
RbConfig:

pp RbConfig::CONFIG
{“MAJOR”=>“1”,
“MINOR”=>“8”,
“TEENY”=>“6”,
“PATCHLEVEL”=>“0”,
“EXEEXT”=>“.exe”,
“ruby_install_name”=>“ir”,
“RUBY_INSTALL_NAME”=>“ir”,
“RUBY_SO_NAME”=>“msvcrt-ruby18”,
“SHELL”=>“$(COMSPEC)”,
“BUILD_FILE_SEPARATOR”=>“\”,
“PATH_SEPARATOR”=>“;”,
“CFLAGS”=>“-MD -Zi -O2b2xg- -G6”,
“CPPFLAGS”=>“”,
“CXXFLAGS”=>“”,
“FFLAGS”=>“”,
“LDFLAGS”=>“”,
“LIBS”=>“oldnames.lib user32.lib advapi32.lib ws2_32.lib “,
“bindir”=>“C:/IronRuby/bin”,
“libdir”=>“C:/IronRuby/lib”,
“DESTDIR”=>“C:”,
“prefix”=>“C:/IronRuby”,
“exec_prefix”=>“C:/IronRuby”,
“sbindir”=>“C:/IronRuby/sbin”,
“libexecdir”=>“C:/IronRuby/libexec”,
“datadir”=>“C:/IronRuby/share”,
“sysconfdir”=>“C:/IronRuby/etc”,
“sharedstatedir”=>“C:/etc”,
“localstatedir”=>“C:/var”,
“includedir”=>“C:/IronRuby/include”,
“infodir”=>“C:/IronRuby/info”,
“mandir”=>“C:/IronRuby/man”,
“rubylibdir”=>“C:/IronRuby/lib/ruby/1.8”,
“sitedir”=>“C:/IronRuby/lib/ruby/site_ruby”,
“oldincludedir”=>”/usr/include”,
“host_cpu”=>“i686”,
“host_os”=>“mswin32”,
“target”=>“dotnet2.0”,
“arch”=>“universal-dotnet2.0”,
“build”=>“universal-dotnet2.0”,
“target_alias”=>“dotnet2.0”,
“target_cpu”=>“i386”,
“target_vendor”=>“pc”,
“target_os”=>“mswin32”,
“CC”=>“cl -nologo”,
“CPP”=>“cl -nologo -E”,
“YACC”=>“byacc”,
“RANLIB”=>“”,
“AR”=>“lib -nologo”,
“ARFLAGS”=>“-machine:x86 -out:”,
“LN_S”=>“”,
“SET_MAKE”=>“”,
“CP”=>“copy > nul”,
“ALLOCA”=>“”,
“DEFAULT_KCODE”=>“”,
“OBJEXT”=>“obj”,
“XCFLAGS”=>
“-DRUBY_EXPORT -I. -IC:/develop/win/ruby/ruby-1.8.6
-IC:/develop/win/ruby/ruby-1.8.6/missing”,
“XLDFLAGS”=>“-stack:0x2000000”,
“DLDFLAGS”=>
“-link -incremental:no -debug -opt:ref -opt:icf -dll $(LIBPATH)
-def:$(DEFFILE) -implib:$(*F:.so=)-universal-dotnet2.0.lib
-pdb:$(*F:.so=)-universal-dotnet2.0.pdb”,
“ARCH_FLAG”=>“”,
“STATIC”=>“”,
“CCDLFLAGS”=>“”,
“LDSHARED”=>“cl -nologo -LD”,
“DLEXT”=>“so”,
“DLEXT2”=>“dll”,
“LIBEXT”=>“lib”,
“STRIP”=>“”,
“EXTSTATIC”=>“”,
“setup”=>“Setup”,
“MINIRUBY”=>“.\miniruby.exe “,
“PREP”=>“miniruby.exe”,
“RUNRUBY”=>
“.\ruby.exe "C:/develop/win/ruby/ruby-1.8.6/runruby.rb"
–extout=".ext" --”,
“EXTOUT”=>”.ext”,
“ARCHFILE”=>“”,
“RDOCTARGET”=>“install-nodoc”,
“LIBRUBY_LDSHARED”=>“cl -nologo -LD”,
“LIBRUBY_DLDFLAGS”=>" -def:msvcrt-ruby18.def",
“rubyw_install_name”=>“rubyw”,
“RUBYW_INSTALL_NAME”=>“rubyw”,
“LIBRUBY_A”=>“msvcrt-ruby18-static.lib”,
“LIBRUBY_SO”=>“msvcrt-ruby18.dll”,
“LIBRUBY_ALIASES”=>“”,
“LIBRUBY”=>“msvcrt-ruby18.lib”,
“LIBRUBYARG”=>“msvcrt-ruby18.lib”,
“LIBRUBYARG_STATIC”=>“msvcrt-ruby18-static.lib”,
“LIBRUBYARG_SHARED”=>“msvcrt-ruby18.lib”,
“SOLIBS”=>“”,
“DLDLIBS”=>“”,
“ENABLE_SHARED”=>“yes”,
“OUTFLAG”=>“-Fe”,
“CPPOUTFILE”=>“-P”,
“LIBPATHFLAG”=>" -libpath:"%s"“,
“RPATHFLAG”=>”“,
“LIBARG”=>”%s.lib",
“LINK_SO”=>
“cl -nologo -LD -Fe$(@) $(OBJS) oldnames.lib user32.lib advapi32.lib
ws2_32.lib $(LOCAL_LIBS) -link -incremental:no -debug -opt:ref -opt:icf
-dll $(LIBPATH) -def:$(DEFFILE)
-implib:$(*F:.so=)-universal-dotnet2.0.lib
-pdb:$(F:.so=)-universal-dotnet2.0.pdb",
“COMPILE_C”=>“cl -nologo $(INCFLAGS) -MD -Zi -O2b2xg- -G6 -c
-Tc$(<:\=/)”,
“COMPILE_CXX”=>“$(CXX) $(INCFLAGS) -c -Tp$(<:\=/)”,
“COMPILE_RULES”=>
“{$(srcdir)}.%s{}.%s: {C:/IronRuby/lib/IronRuby}.%s{}.%s:
{$(hdrdir)}.%s{}.%s: .%s.%s:”,
“RULE_SUBST”=>“{.;$(srcdir);C:/IronRuby/lib/IronRuby;$(hdrdir)}%s”,
“TRY_LINK”=>
“cl -nologo -Feconftest $(INCFLAGS) -I$(hdrdir) -MD -Zi -O2b2xg- -G6
$(src) $(LOCAL_LIBS) oldnames.lib user32.lib advapi32.lib ws2_32.lib
-link
$(LIBPATH) -stack:0x2000000”,
“COMMON_LIBS”=>“m”,
“COMMON_MACROS”=>“WIN32_LEAN_AND_MEAN”,
“COMMON_HEADERS”=>“winsock2.h windows.h”,
“DISTCLEANFILES”=>"vc
.pdb”,
“EXPORT_PREFIX”=>" “,
“configure_args”=>”–with-make-prog=nmake --enable-shared
–with-winsock2",
“ruby_version”=>“1.8”,
“archdir”=>“C:/IronRuby/lib/ruby/1.8/universal-dotnet2.0”,
“sitelibdir”=>“C:/IronRuby/lib/ruby/site_ruby/1.8”,
“sitearchdir”=>“C:/IronRuby/lib/ruby/site_ruby/1.8/$(sitearch)”,
“topdir”=>“C:/IronRuby/lib/IronRuby”}


Will G.
http://hotgazpacho.org/

Will G. wrote:

That depends on how the platform is determined by mkrf. Can you verify
what
mkrf is using to determine the platform? Here’s a printout of IronRuby’s
RbConfig:

mkrf is used by “all platforms” (in this case, it’s pure ruby and
platform independent, so doesn’t actually use rbconfig).
-rp

Ah, I see that there is no C code in the ext directory of the
faster_rubygems code: GitHub - rdp/faster_rubygems: A helper to dramatically speedup the time it takes to run a 'require rubygems'. DEPRECATED shouldn't be necessary with newer versions of rubygems, at least I hope not. If it is message me so I can work on this again

It looks like a problem with spaces in the path to your IronRuby
install.
“C:\Program FIles” is not being properly escaped, and the script chokes.
http://github.com/rdp/faster_rubygems

Will G.
http://hotgazpacho.org/

Actually, faster_rubygems installed fine on IronRuby 1.0 for me, and I
have it installed in a location with spaces, so what is the actual
problem?

C:\windows\system32>ir -S gem install faster_rubygems
Building native extensions. This could take a while…

faster_rubygems installed! see the readme for post-install instructions:

Successfully installed faster_rubygems-0.9.2
1 gem installed
Installing ri documentation for faster_rubygems-0.9.2…
Installing RDoc documentation for faster_rubygems-0.9.2…

C:\windows\system32>where ir
C:\Program Files (x86)\IronRuby 1.0v4\bin\ir.exe
C:\Program Files (x86)\IronRuby 1.0\bin\ir.exe

C:\windows\system32>ir -v
IronRuby 1.0.0.0 on .NET 4.0.30319.1

~js

From: [email protected]
[mailto:[email protected]] On Behalf Of Will G.
Sent: Friday, June 25, 2010 10:12 AM
To: [email protected]
Subject: Re: [Ironruby-core] bug?

Ah, I see that there is no C code in the ext directory of the
faster_rubygems code: GitHub - rdp/faster_rubygems: A helper to dramatically speedup the time it takes to run a 'require rubygems'. DEPRECATED shouldn't be necessary with newer versions of rubygems, at least I hope not. If it is message me so I can work on this again

It looks like a problem with spaces in the path to your IronRuby
install. “C:\Program FIles” is not being properly escaped, and the
script chokes.


Will G.
http://hotgazpacho.org/

On Fri, Jun 25, 2010 at 12:48 PM, Roger P.
<[email protected]mailto:[email protected]> wrote:
Will G. wrote:

That depends on how the platform is determined by mkrf. Can you verify
what
mkrf is using to determine the platform? Here’s a printout of IronRuby’s
RbConfig:
mkrf is used by “all platforms” (in this case, it’s pure ruby and
platform independent, so doesn’t actually use rbconfig).
-rp

Posted via http://www.ruby-forum.com/.


Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

The offending line is auto generated by rubygems for me (1.3.7).
I am unsure how the other poster found success for his, though. That is odd.

IronRuby ships with RubyGems 1.3.5, so try using that first. You can
verify your version of RubyGems by running:

D:> ir -e “require ‘rubygems’; puts Gem::VERSION”
1.3.5

On Tue, May 18, 2010 at 4:52 PM, Jimmy S.
[email protected] wrote:

  1. have a checkbox for if we want to install with the i prefix or not on pre-
    installed gems (I know I for one wouldn’t).

We don’t preinstall any gems with IronRuby. So what you’re asking is an option so we remove the “i” from “iri.bat”, “irdoc.bat”, and “igem.bat” ? Keep in mind the actual ruby files are still “ri”, “rdoc”, and “gem”. For the problem with “ir script/console”, rails should fix this (as in, JRuby has the same problem as they ship with jirb).

Other than for the “ruby” command (i.e. “jruby”), JRuby does not
prefix bin scripts or set up RubyGems to prefix anything, so we still
have the same-named rdoc, ri, irb commands provided in JRuby releases,
and gem binaries install with their non-prefixed name. This was a
pragmatic decision; too many Ruby scripts/libs/apps launch those
scripts by their non-prefixed name and all the tutorials and books in
the world use the non-prefixed names. Plus we wanted JRuby to be a
drop-in replacement as much as possible; all those "j"s would make
that much harder.

We’ve recently debated turning the RubyGems prefixing on, to aid folks
using JRuby plus some other impl…but it would cause a lot of support
stress at this point.

Also FYI:

https://rails.lighthouseapp.com/projects/8994/tickets/2104-scriptconsole-execs-irb-causes-double-process-launch-and-limits-other-impls

I filed that last year in February, and after bouncing around a bit it
was bumped off Rails 2.x series. Now it’s apparently back in for 3.0.
Vote with comments :slight_smile:

JRuby has gotten around this since 2006 by doing two things:

  • We ship “irb” executables
  • Our exec logic scans the command being run for “*ruby” or “*irb” and
    intercepts that by simply spinning up another JRuby instance in the
    same JVM. This was partially to allow rails/console and similar
    re-launchers to work, but also to reduce (somewhat) the
    double-launching startup hit.
  • Charlie

D:> ir -e “require ‘rubygems’; puts Gem::VERSION”
1.3.5

Ok, tried it with “default” rubygems…

Seems to still have said problem…

C:\dev\ruby\faster_rubygems>ir -e “require ‘rubygems’; puts
Gem::VERSION”
1.3.5

C:\dev\ruby\faster_rubygems>ir -S gem install faster_rubygems-0.9.3.gem
Building native extensions. This could take a while…
ERROR: Error installing faster_rubygems-0.9.3.gem:
ERROR: Failed to build gem native extension.

“C:/Program Files/IronRuby 1.0v4/bin/ir.exe” mkrf_conf.rb
Installed–thank you for trying out faster_rubygems
recreating all faster_rubygems caches
faster_rubygems: creating all caches

“C:/Program Files/IronRuby 1.0v4/bin/ir.exe” -rubygems C:/Program
Files/IronRuby 1.0v4/lib/ironruby/gems/1.8/gems/rake-0.8.7/bin/rake
RUBYARCHDIR=“C:/Program Files/IronRuby
1.0v4/lib/ironruby/gems/1.8/gems/faster_rubygems-0.9.3/lib”
RUBYLIBDIR=“C:/Program Files/IronRuby
1.0v4/lib/ironruby/gems/1.8/gems/faster_rubygems-0.9.3/lib”
unknown: Could not find file ‘C:\Program’. (Errno::ENOENT)

Gem files will remain installed in C:/Program Files/IronRuby
1.0v4/lib/ironruby/gems/1.8/gems/faster_rubygems-0.9.3 for inspection.
Results logged to C:/Program Files/IronRuby
1.0v4/lib/ironruby/gems/1.8/gems/faster_rubygems-0.9.3/ext/gem_make.out