Forum: JRuby error when running system("jruby ...") twice within jirb?

Within a jruby project, if I open jirb and do the following

>> system("jruby -S spec plugins/edit_view/spec/edit_view/document_spec.rb --backtrace")
>> system("jruby -S spec plugins/edit_view/spec/edit_view/document_spec.rb --backtrace")

The first one succeeds and the second system call (and any subsequent)
fail like


...cannot link Java class org.eclipse.swt.widgets.Button, probable
missing dependency: no swt-win32-3555 or swt-win32 in swt.library.path,
java.lib

http://pastie.org/832951

Anybody know what might be going on here?

When I run it from MRI, like

>> system("e:\\dev\\ruby\\downloads\\jruby\\bin\\jruby.EXE -S spec plugins/edit_view/spec/edit_view/document_spec.rb --backtrace")

>> system("e:\\dev\\ruby\\downloads\\jruby\\bin\\jruby.EXE -S spec plugins/edit_view/spec/edit_view/document_spec.rb --backtrace")

it seems to work fine.

Thanks.
-rp

On Fri, Feb 19, 2010 at 11:07 AM, Roger Pack <lists@ruby-forum.com> 
wrote:
> missing dependency: no swt-win32-3555 or swt-win32 in swt.library.path,
> java.lib
>
> http://pastie.org/832951
>
> Anybody know what might be going on here?

This is almost certainly due to our being "clever" and trying to avoid
spinning up a new JVM for #system calls that start with 'jruby'.
Instead, we run them in the same JVM, and I would guess SWT doesn't
like being treated this way. It looks like it's trying to load the
native libraries again, which won't work.

You may be able to fix this by putting SWT in the global system
CLASSPATH (env var or JRuby's lib dir), which should cause it to be
loaded once at a higher level, rather than multiple times for jruby
"subprocesses". Alternatively, you can specify the
jruby.launch.inproc=false property on initial startup to force all
#system calls to spin up a full new process.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

> loaded once at a higher level, rather than multiple times for jruby
> "subprocesses". Alternatively, you can specify the
> jruby.launch.inproc=false property on initial startup to force all
> #system calls to spin up a full new process.

The more I think about this the more I lean towards having the inproc
property be false by default. I've got bitten by this twice.  In each
case I was expecting a full new JVM.  the inproc = true seems more
like an optimization to me.  Has anyone else asked that?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Hi Jay,

Lots of things would break if we switch the default. For example,
running test/rspec from jruby-complete.jar would break.
Various things when non-jruby-aware libs execute 'ruby' would also
execute ruby, not jruby, if the inproc option is disabled.

But yeah, first time I saw it, I also felt that this probably should
be off by default, but I'm not sure it is a good idea to switch it at
this moment.
Some problems would go away, but we get fresh ones :)

Thanks,
  --Vladimir

On Tue, Mar 2, 2010 at 9:11 PM, Jay McGaffigan <hooligan495@gmail.com> 
wrote:
>> loaded once at a higher level, rather than multiple times for jruby
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

On Tue, Mar 2, 2010 at 3:02 PM, Vladimir Sizikov <vsizikov@gmail.com> 
wrote:
> Hi Jay,
>
> Lots of things would break if we switch the default. For example,
> running test/rspec from jruby-complete.jar would break.
> Various things when non-jruby-aware libs execute 'ruby' would also
> execute ruby, not jruby, if the inproc option is disabled.

This isn't even the worst case; Rake, among other libraries, launches
subprocesses to run groups of tests. So the current slow test times
for Rake/Rails users would get much, much worse.

I don't claim to have any answers. The in-proc stuff is absolutely
crucial to keeping JRuby working nicely and reasonably quickly with
the way Rubyists have wired all those bits together. If Rubyists had
more of an eye for how JRuby does things, they probably wouldn't do
"system 'ruby ...'" or launch a million subprocesses all the time. We
can try to fix all those cases in the wild, but for now they exist and
there's not a lot we can do about them.

- Charlie

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

ok.  That makes a ton of sense.  I withdraw my observation :)



On Wed, Mar 3, 2010 at 8:23 AM, Charles Oliver Nutter
<headius@headius.com> wrote:
> for Rake/Rails users would get much, much worse.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

Charles Nutter wrote:
> On Fri, Feb 19, 2010 at 11:07 AM, Roger Pack <lists@ruby-forum.com> 
> wrote:
>> missing dependency: no swt-win32-3555 or swt-win32 in swt.library.path,
>> java.lib
>>
>> http://pastie.org/832951
> "subprocesses". Alternatively, you can specify the
> jruby.launch.inproc=false property on initial startup to force all
> #system calls to spin up a full new process.

Appears that adding this
--no-sub-jruby
to jruby accomplishes the same?

-r

> Appears that adding this
> --no-sub-jruby
> to jruby accomplishes the same?

Oops my bad--appears this was an application specific thing, not for 
jruby :)
-rp