-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
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:
rubinius 2.0.0dev (1.9.3 bb60dc9a yyyy-mm-dd JI)
[x86_64-unknown-linux-gnu]
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:
0. 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.
1. Clone Rubinius’ master:
$ git clone https://github.com/rubinius/rubinius.git
2. Build and install Rubinius (ensure it is in your PATH afterwards):
$ ./configure --prefix=/opt/rubies/rubinius
# rake install
3. Download wxRuby’s sources and unpack them, then change into the
resulting directory
4. 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)
5. 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
6. 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
7. Start the build:
$ rake
8. Strip the library:
$ strip -x lib/wxruby2.so
9. Build the RubyGem:
$ rake gem
10. 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/
iQEcBAEBAgAGBQJO7H7xAAoJELh1XLHFkqhadaoIAKhRGCzZwu0SSQ1Cy1+b7+c5
OXW9Xco4a3zBJe40jEdlmt2nf7IT5w7VUu3zqpl5ngXItUMJi6zL5SUOtqjbRwqE
pCE+7P9cAoiL0VvkoRNWoGxX1BAxaNtQiY1IclXhPDnfRFLvw6R6dHmo+U4MdeCk
0svIgOkWSo2r9JD+zMwy7HSDqJ6nyvn8ncRj3QY/M5S3SoiVMStlH6JuKMWdGrGt
6C5CmVT9XLMwEemv6SwQyUQ8fxok02GKljFyZMs0RcVy0Xsb3XWRSdEeIkLA6g76
8p2ilMUlNTqrFqP2nHOiVR8QtAmBKYSODHjJ4h9/J/jnxIm2c5GFgItRYPPezj0=ljp1
-----END PGP SIGNATURE-----
_______________________________________________
wxruby-users mailing list
wxruby-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/wxruby-users
Hi Quintus> 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: > > rubinius 2.0.0dev (1.9.3 bb60dc9a yyyy-mm-dd JI) [x86_64-unknown-linux- > gnu] > > Basic things work quite well (I was surprised!)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.<snip> thank you very much for documenting this for others Cheers alex
Hi all, 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. David On Mon, Dec 19, 2011 at 11:25 PM, Alex Fenton <alex at pressure.to> wrote:> Hi Quintus > > > 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: > > > > rubinius 2.0.0dev (1.9.3 bb60dc9a yyyy-mm-dd JI) [x86_64-unknown-linux- > > gnu] > > > > Basic things work quite well (I was surprised!) > > 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. > > <snip> thank you very much for documenting this for others > > Cheers > alex > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-users/attachments/20111220/7b0c3438/attachment-0001.html>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 20.12.2011 00:44, David Beswick wrote:> Hi all, > > 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/ iQEcBAEBAgAGBQJO8OcBAAoJELh1XLHFkqhayroIAKPqPICnLvqR7gqvUrDW0r87 CMf9U3XpzMKnjM0emjaykONCax00J+zYAqtjhOICxXJghe45Fs8WJ9G1Z6OTLSZm BeiG/RxAkv/kbSN+iO/KLqwDGmFfXpkVREFl6XvWkkGwcuU0keQmt6uvszblK+Y0 7g/LJTSHQDEyZ2J40l/sT+T+MCOVvVelO9zhBIbjnE4Cmv52gcLlQA3R7UmFnXiJ Gf9ESDcdIgf8aQ0AeOY8qhTkjH38+l7IB97i3IfqLDF8S7emwk4lwnJM5H80pmUZ YgM9W2zjvDnreFwnCy8XmVCcV2MMY58PiFKP6yWzoOmpJ0HSidJCdjCPKYlBw8A=pOvG -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 17.12.2011 12:37, Quintus wrote:> 10. 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.I just wanted to note that this was caused by a bug in Rubinius? FileUtils module (see https://github.com/rubinius/rubinius/issues/1458 ) 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. :-) The Rubinius version I used this time was: rubinius 2.0.0dev (1.9.3 2ad0c747 yyyy-mm-dd JI) [x86_64-unknown-linux-gnu] Valete, Marvin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO80qXAAoJELh1XLHFkqhaYdgH/0X1rclnYHDwH15PWOB6xGnl OekHeyR+ahYYXfiY1XH2bIdGUa01LdusPgnk+h3w+fKPsn1wNx7J4/USfQbWlaKO PZfOPPAXbg4844cDZtFQhOBq7/jhTpHXlZsyG+uaBLXvViyoHSKY7jC/pZQ5QO93 HJwlhx+d+agDFxC+yJFK4T8DGWx7LpahW9iSPXeK7WwZzH4eGDHZx+PJUika5a1L TLQf1I2t2LCXrv3JKdlx9bf0MnQ9SWT/RWHB7+Q2f/2P4Z30Wk5fvqpUo7sL4ZYe K81zCfer2OAwdMDsmCX6V1OUqdmKcKVNf/bJp6LzzhXLCGk9gXhwlYbZGXAjARk=Xjr5 -----END PGP SIGNATURE-----