Hi I''m considering porting some fixes to CommandEvent and Event that I applied a while ago to HEAD onto the 2.0 stable branch. These fixes do two things: - make inheritance from these classes in Ruby work better, so that Ruby instance variables associated with Event objects persist. At the moment, if you post an event of a Ruby subclass, instance data is lost when the event is handled. - make events more thread-safe. Since Ruby 1.9, threads are real threads, and the so as per Wx, GUI code should only be in a single (normally the main) thread. The correct way to do updates eg from long-running threads is for the worker thread to post an event to the App. However, the current code can segfault when this happens. All current code should continue to work, but I just wanted to check if anyone saw any problems with this. Let me know, otherwise I''ll apply in the next day or two. With a couple of other bugfixes, let''s look to post a v2.0.2 fairly soon. cheers alex
Hey Alex, Sounds good to me. Have you purchased the new version of Mac OS X yet, or is that still in holding? Also, I think for Linux, since so many people have been having problems, that we may need to look at possibly creating 2 builds, one for Dynamically link libraries, and one that has wxWidgets statically compiled, since so many people seem to be having problems doing the compiles themselves. See if this may solve some problems, but I doubt it, if GTK is a different version between Distros. I think that is why we went to Dynamic link, instead of Static Link. I''m just thinking of the possibility, that we need to somehow ease the compilation of wxWidgets, and wxRuby on Linux systems, so as to ensure that the system will properly work between distros. The only thing that I can think of to solve this problem, is to do something similar to the RubyInstaller project, and create a boot strap environment, that will download everything that is needed, and configure / compile wxWidgets then wxRuby. What are your guys thoughts about this? Let me know. On Fri, Oct 30, 2009 at 8:48 AM, Alex Fenton <alex at pressure.to> wrote:> Hi > > I''m considering porting some fixes to CommandEvent and Event that I applied > a while ago to HEAD onto the 2.0 stable branch. These fixes do two things: > > - make inheritance from these classes in Ruby work better, so that Ruby > instance variables associated with Event objects persist. At the moment, if > you post an event of a Ruby subclass, instance data is lost when the event > is handled. > > - make events more thread-safe. Since Ruby 1.9, threads are real threads, > and the so as per Wx, GUI code should only be in a single (normally the > main) thread. The correct way to do updates eg from long-running threads is > for the worker thread to post an event to the App. However, the current code > can segfault when this happens. > > All current code should continue to work, but I just wanted to check if > anyone saw any problems with this. Let me know, otherwise I''ll apply in the > next day or two. With a couple of other bugfixes, let''s look to post a > v2.0.2 fairly soon. > > cheers > alex > > > > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development >-- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20091030/eeea2aca/attachment.html>
Hi Alex, 2009/10/30 Alex Fenton <alex at pressure.to>:> - make inheritance from these classes in Ruby work better, so that Ruby > instance variables associated with Event objects persist. At the moment, if > you post an event of a Ruby subclass, instance data is lost when the event > is handled. > > - make events more thread-safe. Since Ruby 1.9, threads are real threads, > and the so as per Wx, GUI code should only be in a single (normally the > main) thread. The correct way to do updates eg from long-running threads is > for the worker thread to post an event to the App. However, the current code > can segfault when this happens.That''s fine for me. Cheers, Chauk-Mean.
Hi Mario, 2009/10/30 Mario Steele <mario at ruby-im.net>:> Also, I think for Linux, since so many people have been having problems, > that we may need to look at possibly creating 2 builds, one for Dynamically > link libraries, and one that has wxWidgets statically compiled, since so > many people seem to be having problems doing the compiles themselves.? See > if this may solve some problems, but I doubt it, if GTK is a different > version between Distros.? I think that is why we went to Dynamic link, > instead of Static Link.? I''m just thinking of the possibility, that we need > to somehow ease the compilation of wxWidgets, and wxRuby on Linux systems, > so as to ensure that the system will properly work between distros. > > The only thing that I can think of to solve this problem, is to do something > similar to the RubyInstaller project, and create a boot strap environment, > that will download everything that is needed, and configure / compile > wxWidgets then wxRuby.? What are your guys thoughts about this?That seems to be a good idea. Cheers. Chauk-Mean.
Mario Steele wrote:> Sounds good to me. Have you purchased the new version of Mac OS X > yet, or is that still in holding?I haven''t got round to it. The Apple shop near my work is so COOL they don''t have tills, just Apple Geniuses with card machines round their necks that you have to sort of find. I find this so nauseatingly try-hard and irritating too - we Brits love a proper queue - that I''ve twice gone in and given up. I''ll maybe give it another whirl this week, or just buy online.> Also, I think for Linux, since so many people have been having > problems, that we may need to look at possibly creating 2 builds, one > for Dynamically link libraries, and one that has wxWidgets statically > compiled, since so many people seem to be having problems doing the > compiles themselves. See if this may solve some problems, but I doubt > it, if GTK is a different version between Distros. I think that is > why we went to Dynamic link, instead of Static Link. I''m just > thinking of the possibility, that we need to somehow ease the > compilation of wxWidgets, and wxRuby on Linux systems, so as to ensure > that the system will properly work between distros.Thanks for bringing this up. We seem to have had a flurry of problems. I haven''t quite got to what''s at the bottom of it.> The only thing that I can think of to solve this problem, is to do > something similar to the RubyInstaller project, and create a boot > strap environment, that will download everything that is needed, and > configure / compile wxWidgets then wxRuby. What are your guys > thoughts about this?Sounds like a good deal of work. I think the ideal situation is to get people installing through distro packages, but I don''t use or know Linux well enough to get onto this myself. I wonder if providing pre-SWIGged Linux sources that people then build against their distro''s own wx is a better way to go? Maybe we just need to provide clearer instructions about required packages - eg libmesa-dev seems to be tripping people up. a