Forum: wxRuby wxRuby and Rubinius

85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-12-17 13:04
(Received via mailing list)
-----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-----
06f6780c99d4a8dd71f2b474082ea9ce?d=identicon&s=25 Alex Fenton (Guest)
on 2011-12-19 19:58
(Received via mailing list)
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
E7f3cbcb69beec85643d1ecc54121460?d=identicon&s=25 David Beswick (davidbeswick)
on 2011-12-20 01:20
(Received via mailing list)
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
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-12-20 21:09
(Received via mailing list)
-----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-----
85991f138ede6236f35eb98da22b7b01?d=identicon&s=25 Marvin Gülker (quintus)
on 2011-12-22 16:54
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17.12.2011 12:37, Quintus wrote:
> 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-----
This topic is locked and can not be replied to.