tsuraan wrote:
I did notice in that function that the inner program being invoked is
ruby, rather than jruby; is that on purpose?
Ok, so it made it to the compiled tests this time. My change is:
I think this may have changed the meaning of the test slightly, but I
don't think it's a major change. Normally I would have expected the
inner "ruby" process to still be run in-process, but perhaps that's been
broken at some point, or it's not working on Solaris/Sparc correctly.
That may very well be the source of the slowness during the
JRubyTestSuite, since there are a few tests that spin "ruby" or "jruby"
commands expecting them to run in-process.
Could you link 'jruby' to 'ruby' and see if this passes? If so, I think
we have a bug in how we determine whether to launch a "ruby" command
in-process.
- Charlie
Index: test/org/jruby/util/ShellLauncherTest.java
===================================================================
--- test/org/jruby/util/ShellLauncherTest.java (revision 7871)
+++ test/org/jruby/util/ShellLauncherTest.java (working copy)
@@ -52,7 +52,7 @@
public void testCanLaunchShellsFromInternallForkedRubyProcess() {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
RubyString cmd = RubyString.newString(runtime,
- "jruby -e \"system(%Q[ruby -e 'system %q(echo hello)
; puts %q(done)'])\"");
+ "jruby -e \"system(%Q[jruby -e 'system %q(echo
hello); puts %q(done)'])\"");
int result = ShellLauncher.runAndWait(runtime, new
IRubyObject[]{cmd}, baos);
assertEquals(0, result);
String msg = baos.toString();
Basically, I replaced the call to ruby with a call to jruby. Seems
sensible, I think.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
