wxRuby 1.9.6

Desktop wxRuby
1

I’m happy to announce that the latest version of wxRuby is available now
from Rubyforge. This release contains many bugfixes, enhancements and a
few additional features, and it’s a recommended upgrade.

== INSTALLATION ==

The release can be downloaded from:
http://rubyforge.org/frs/?group_id=35&release_id=21668

Or installed via rubygems for Windows, Linux and OS X:
(sudo) gem install wxruby

Note that the upcoming ruby version 1.8.7 is NOT supported (see below)

== WHAT’S NEW ==

This release contained a record number of changes among recent releases;
these are detailed in full in the ChangeLog, but highlights include:

  • New MingW build for Windows (somewhat experimental - see below)
  • Added AboutDialogInfo and AnimationCtrl GUI classes
  • Added ToolBar and Animation helper classes
  • Substantial improvements to Image class such as raw data manipulation
    and reading to IO
  • Minor syntax enhancements and additional methods in existing classes
  • Many fixes to long-standing and newly identified bugs, crashers, and
    memory leaks
  • Additions to the samples and documentation

== PLATFORMS AND RUBY VERSIONS ==
A quick note on where wxRuby is going with regards to ruby versions.

Firstly, the One-Click Installer on Windows is likely to move over to
compiling with MingW (gcc on Windows) instead of the Microsoft
toolchain. This is very good news for wxRuby - we’re currently relying
on old, unsupported and unavailable versions of MSVC. wxRuby under MingW
is also significantly faster, and will make it easier for contributors
on Windows to work on the core library. However at present a few classes
are not available - eg GLCanvas

For more information, see:
http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/4056d40003e05728/5d4ebedd430dec4a

Note that the -mingw build will NOT work with the current OCI - you must
use the gem tagged -mswin32

With regard to ruby versions, 1.8.6 is currently the preferred version,
although recent 1.8.x releases should work. The emerging 1.9.x releases
will be fully supported, although there is a bug in ruby 1.9.0 which
currently breaks important functionality in wxRuby.

The upcoming ruby 1.8.7 version introduces numerous internal and API
changes that are not backwards compatible, and cause a real headache for
library maintainers. There are no plans to support this version at
present.

== BUGS ETC ==
The bugfixes for this release mean that the bug list on Rubyforge is
down to a small list most of which can only be fixed by changes to
wxWidgets. So please do report any crashes or wrong behaviour with this
release to get the final stable release as good as possible.

== THANKS ==
Thank you very much to everyone who contributed patches, bug reports and
code samples to this release. Particular thanks to Mario, who has been
the driving force in getting the MingW build flying.

cheers
alex

2

I’ve run into problems running the 1.9.6. Windows gem on a machine other
than the one I built it on. If you’re getting errors like ‘cannot load
module…’ please post them to the list - or also, if it is working for
you, that would be useful to know.

I think it might be because this latest release has been built with MSVC
8.0 and so depends on msvcp80.dll and msvcr80.dll, but I’m not sure.

A great advert for why the move to MingW will be a good thing!

thanks
aelx

3

Hey Alex,

Yeah, I’ve ran into the same problems, first it not finding MSVCP80.DLL
and
MSVCR80.DLL, then when I grab them off of dll-files.com, to satisfy the
dependencies, and no matter if I put them in C:\Windows\System32 or
C:\Windows\WinSxS or whatever the other important directory, or even
putting
them into the directory that ruby resides in, it comes up with the
cannot
load module… problem.

Definitely one of the things I will not miss when we’re fully MinGW.

Popup Dialog:
Runtime Error!

Program: J:\system\ruby_msvc\bin\ruby.exe

R6034
An application has made an attempt o load the C runtime library
incorrectly. Please contact the application’s support team for more
information.

In the console:

J:/system/ruby_msvc/lib/ruby/gems/1.8/gems/wxruby-1.9.6-x86-mswin32-60/lib/wxruby2.so:
1114: A dynamic link library (DLL) initialization routine failed. -
J:/system/ruby_msvc/lib/ruby/gems/1.8/gems/wxruby-1.9.6-x86-mswin32-60/lib/wxruby2.so
(LoadError)
from
J:/system/ruby_msvc/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in
require' from J:/system/ruby_msvc/lib/ruby/gems/1.8/gems/wxruby-1.9.6-x86-mswin32-60/lib/wx.rb:12 from J:/system/ruby_msvc/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in gem_original_require’
from
J:/system/ruby_msvc/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:32:in
`require’
from wxRIDE.rb:30

It might also be the fact that MSVC version is compiled with a different
version of MSVC (7.1)

4

Jonathan M. wrote:

As far as I know you need to compile extensions in Windows with the
same compiler as Ruby is compiled with (which is most likely MSVC 6).
I ran into exactly the same problem when trying to compile and run
Ripper.

We’ve got by so far compiling wxRuby2 windows releases with MSVC 7.1
against the MSVC 6.0 one-click installer. I’ve personally been using 8.0
for 18 months for debugging builds and it’s worked fine with the
standard OCI installer, but this is the first time I’ve tried to use it
for a release.

The build works fine for me on the machine I used to compile it, but I’m
currently on stuck knowing what extra things I need to ship or link to
to enable the library to work elsewhere. Unfortunately the error message
isn’t at all helpful. I’ll have a further look tomorrow, anyway.

thanks
alex

5

As far as I know you need to compile extensions in Windows with the same
compiler as Ruby is compiled with (which is most likely MSVC 6).
I ran into exactly the same problem when trying to compile and run
Ripper.

Jonathan