I managed to compile wxRuby 2.0.1 against the current Rubinius master
using both Rubinius’ 1.8 and 1.9 mode on my 64bits Arch Linux system.
Here’s the used Rubinius version:
Basic things work quite well (I was surprised!), but as soon as it
comes to complex things, e.g. running most sub-demos of the bigdemo,
Rubinius crashes with:
$ /opt/rubies/rubinius/bin/rbx -X19 bigdemo.rb
Thread deadlock in ::lock()!
Aborted
Rubinius uses real concurrent threads, something I’ve always missed on
MRI (and I was hoping it would resolve the
wxRuby-and-threads-problem), but appearantly wxRuby isn’t that
thread-safe. Has there been any consideration of supporting Rubinius
for wxRuby?
Regarding the build process itself, I wanted to share my experiences.
Surprisingly, with a few adjustments wxRuby compiles flawlessly.
Here’s what I did:
Set up a working MRI Ruby 1.9 (1.8 should work as well), install
g++, wxWidgets and SWIG 1.3.38 as well as LLVM 2.8.
Build and install Rubinius (ensure it is in your PATH afterwards):
$ ./configure --prefix=/opt/rubies/rubinius
rake install
Download wxRuby’s sources and unpack them, then change into the
resulting directory
Edit rake/rakeconfigure.rb in wxRuby’s sources:
4a) If you want to compile wxRuby for Ruby 1.8, change line 47 from
$ruby_includes = " -I. -I " + Config::CONFIG[“archdir”]
to
$ruby_includes = " -I. -I " + Config::CONFIG[“archdir”] + ’
-I/opt/rubies/rubinius/18/include’
(or whereever your Rubinius is installed)
4b) If you want to compile for Ruby 1.9, change line 45 from
$ruby_includes = " -I. -I " + includes.join(’ -I ‘)
to
$ruby_includes = " -I. -I " + includes.join(’ -I ') + ’
-I/opt/rubies/rubinius/19/include’
(or whereever your Rubinius is installed)
Ensure Rubinius is run in the correct mode.
5a) If you want to build for Ruby 1.8, nothing needs to be done.
5b) If you want to build for Ruby 1.9, make Rubinius use 1.9 mode:
$ export RBXOPT=-X19
Check with:
$ rbx --version
Install the rake gem (note `sudo’ may reset environment
variables such as RBXOPT which will cause you to install the
gem into Rubinius’ 1.8 mode which is not desired for 1.9!):
gem install rake
Start the build:
$ rake
Strip the library:
$ strip -x lib/wxruby2.so
Build the RubyGem:
$ rake gem
Install the gem.
10a) If you built for Ruby 1.8:
# gem install --local wxruby-2.0.1-x86_64-linux.gem
10b) The gem generated for 1.9 is unusable. Trying to install it
results in the following error message:
ERROR: While executing gem … (Errno::ENOENT)
No such file or directory -
/opt/rubies/rubinius/gems/1.9/cache/wxruby-ruby19-2.0.1-x86_64-linux.gem
You therefore have to fall back to non-gem usage or 'manually'
install the gem by unpacking the .gem file and placing the
files in the correct directories.
Valete,
Marvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
I managed to compile wxRuby 2.0.1 against the current Rubinius master using
both Rubinius’ 1.8 and 1.9 mode on my 64bits Arch Linux system.
Here’s the used Rubinius version:
That is interesting to know. In a way, as both Wx and Rubinius are
strongly C++ based they are a good fit.
but as soon as it comes to
complex things, e.g. running most sub-demos of the bigdemo, Rubinius
crashes with:
$ /opt/rubies/rubinius/bin/rbx -X19 bigdemo.rb Thread deadlock in ::lock()!
Aborted
Rubinius uses real concurrent threads, something I’ve always missed on MRI
(and I was hoping it would resolve the wxRuby-and-threads-problem), but
appearantly wxRuby isn’t that thread-safe. Has there been any
consideration of supporting Rubinius for wxRuby?
I’m not sure if wxRuby itself has anything not thread-safe in the API
wrapping. But at the moment Ruby code can (ab)use the Wx API in ways
that would not be thread safe if Ruby 1.8 threads were “real”. E.g. you
can make GUI API calls from subordinate threads, rather than
message-passing.
I haven’t ever looked into supporting non-MRI ruby platforms myself. It
sounds like rubinius would be a good candidate.
Regarding the build process itself, I wanted to share my experiences.
Surprisingly, with a few adjustments wxRuby compiles flawlessly.
thank you very much for documenting this for others
I’d also venture that garbage collection can be a hidden culprit. My
program dynamically creates and destroys a lot of windows, which may
differ
from a typical wxruby app. I had some issues with random crashes or
hangs
on 1.9 and my debugging pointed to these occuring during destruction of
wxruby objects. Some wxWidgets destructors call windowing system
functions
to get information required during the destruction. I think wxMenu was
one
of these. This was an issue that would occur in 1.9 but not 1.8, becase
1.9
also uses native threads and Win32 doesn’t like calls to windowing
functions outside of the message loop thread (as far as I know.) Even
with
1.9’s GIL, just the fact that the call was coming from a different
thread
to the message loop caused issues. I’m on Linux now so I haven’t thought
about this Windows issue further.
So potential issues also lie with wxWidget and
windowing-system-dependent
implementation. Something to think about for the future.
I’d also venture that garbage collection can be a hidden culprit.
My program dynamically creates and destroys a lot of windows, which
may differ from a typical wxruby app. I had some issues with random
crashes or hangs on 1.9 and my debugging pointed to these occuring
during destruction of wxruby objects.
I experienced this once or twice as well (using MRI 1.9 on Windows).
If I remember correctly, Ruby aborts with a message like
[BUG] Object allocation during garbage collection phase
But I always could work around the problem by changing my code.
Additionally, a brute-force solution to the problem was to disable
Ruby’s GC while wxRuby tries to do unusual things:
GC.disable
Do bad things…
GC.enable
This always worked, but can be considered a hack that should not be
used.
Vale,
Marvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
install the gem by unpacking the .gem file and placing the files in
the correct directories.
I just wanted to note that this was caused by a bug in Rubinius’
FileUtils module (see FileUtils.cp in 1.9 mode doesn’t work · Issue #1458 · rubinius/rubinius · GitHub
) that is now fixed along with another bug in File that doesn’t have a
ticket as far as I can see (File.identical? crashed if one of the
tested files didn’t exist). This means, the generated gem can now be
installed without problems.
