Creeping bug (WxSU + SU Tool) SU 7 only
-
Hi all,
I have recently a problem with a tool using WxSU library.
I have created a SU Tool that has a non-modal WxSU dialog associated with it.Everything works well, as long as I won't let SU run idle for a while (say 2 minutes). Once I will do it and invoke the dialog (@dialog.show) it starts to display it and stops half way. SU freezes, WxDialog is unresponsive. No bugsplat or error in the console. Same thing happens when I want to close already opened WxSU widnow.
I have read somewhere that it can be related to GarbageCollector. How can I tackle such a creeping bug?
Tomasz
-
bit of a stab in the dark, but you could try
GC.startto kick the garbage collector in to action. -
I have found an adivce to
GC.disableand check if the error still happens. Will check it. -
GC.disable didn't help.
I have found something else. The bug exists in SU 7.1.6087 (Pro), but the script works without a problem in SU 6.4.112 (Free).
I perform same actions in both programs and only SU7 freezes when opening\closing wxSU window after few minutes of inactivity. SU6 works perfectly.
I presume this is something only Google people could help me with. I think it has something to do with a way SU refreshes a view.
-
After reading that SU uses Ruby 1.8.0 in this thread I have replaced original version with 1.8.6 - officially 'used' version.
The bug is gone. It looks like WxSU has been compiled to suit 1.8.6.
Can someone tell me how the compilation of a Ruby Gem looks like from a source?
@unknownuser said:
== Compilation prerequisites
- A C++ compiler: MSVC or MingW for Windows; gcc (g++) for Linux and OS X
- A recent version of SWIG, especially for Ruby 1.9.
- rake
- A compiled wxWidgets library, either built yourself or installed from
via a package manager
== Setting build options
If you're compiling on Windows, you must set an environment variable
to indicate where the WxWidgets libraries and header files can be found:set WXWIN=C:/path/to/wxMSW-2.8.9
The path should be the top-level directory of the unpacked wxWidgets
tarball; it's recommended that the path does not contain spaces.If you have multiple parallel versions of wxWidgets installed, you may
influence which build is selected by setting or unsetting the
environment variables WXRUBY_DEBUG, WXRUBY_RELEASE, WXRUBY_STATIC and
WXRUBY_DYNAMIC. egexport WXRUBY_DEBUG=1
Forces wxRuby to be built against a -debug version of wxWidgets.
Lastly, you may specifically exclude certain classes; this is most often
useful if a particular class is causing problems:export WXRUBY_EXCLUDE=ThisClass,ThatClass
== Running the compile task
From the top-level directory of the unpacked or downloaded wxRuby
directory, just start the rake build with the command:rake
There is no ./configure step, nor do you need to run ruby
extconf.rb. wxRuby has approaching 300 classes to generate, compile and
link, so the process may take some time.I have MSVC++ compiler, downloaded source, I presume will have to install 1.8.0 Ruby.
The most mysterious thing for me in the instruction is the 'rake' thing. Will it do the whole compilation for me? -
There is another solution. I could replace the original Ruby dll with 1.8.6 in an installer of my plugin, but I am afraid that this could upset other plugins.
Does someone know if any plugin already does that? -
As a user I'd not be too comfortable with plugins that replace files of my SU installation...
-
And the SU developers has said: the Ruby 1.8.0 implementation isn't a standard Ruby packages. Parts has been customized for SU - which is why I'm very hesitant to change it.
-
@thomthom said:
And the SU developers has said: the Ruby 1.8.0 implementation isn't a standard Ruby packages. Parts has been customized for SU
In the thread related to Gem installation Dan compared bit by bit both rubies and they are identical.
@thomthom said:
which is why I'm very hesitant to change it.
I would do that if I would be sure that nothing unexpected occurs, but no-one can predict it.
Advertisement