Hey everybody, I''ve made some progress on wxruby-swig, and have some good news and some bad news. The good news is that the MSVC version finally can run all of the samples provided in CVS. I''m using the same solve-by-ignore solution to the GC problem that wxruby uses, so there is far less crashing goin'' on. Depending on the next few weeks, we might be able to approach a 0.1 version in the near future. While not having the number of widgets that wxRuby has, it has a number of features inherit to using SWIG, like being able to override a virtual C++ class''s methods. I don''t have DSL until monday, so it won''t be in CVS until later. The bad news is that, unlike wxruby, it takes a trained expert to get this thing to build. Let me explain. To build the code of a release version, you need wxWidgets 2.4 compiled with RTTI enabled. To do this using the MSVC makefiles requires modifying the wxWidgets makefiles to enable these features (I suppose the VC++ project files only require finding the checkbox, but it''s still non-trivial). I don''t think this is a default in any of the wxWidgets platforms, and will be a major point of contention with new users. To actually do any development with wxruby-swig (add new classes, etc), you need a patched version of SWIG, rake (which won''t work on Ruby 1.6, only 1.8), and in the worst case, NQXML. I know rake still needs some work - it''s confirmed not to work with MSYS, and requires some work in MSVC. Personally, I see this as a real drag in getting volunteer developers. If you can''t figure out the build environment, then you won''t help, end of story. On the other hand, in a few months we may be able to work out some of the oddities (I think wxWidgets is moving towards supporting RTTI, for example). My questions are: 1) Should wxruby-swig focus on stability or being the bleeding-edge? If it should be a bleeding edge project, then maybe the focus should be on getting support for wxWidgets 2.5 (which has much better macintosh support, and is in general considered groovy). It may give a little more time to stablize the build system too. 2) Am I worrying too much about the build system? How important is it to the public to know how to hack on this? Is requiring special builds of wxWidgets an issue? 3) Are there any features not present in wxruby you really want to see in wxruby-swig? get/set methods aliased to accessors? HTML widgets? Other? I''m hoping to generate some discussion on this topic, so feel free to speak up (even the crew of 60 people who download the pre-built OS X version - shout out to my homies!) Later, Nick
Nick wrote:> > Hey everybody, > > I''ve made some progress on wxruby-swig, and have some good news > and some bad > news. > > The good news is that the MSVC version finally can run all of the > samples provided in > CVS. I''m using the same solve-by-ignore solution to the GC > problem that wxruby uses, > so there is far less crashing goin'' on. Depending on the next few > weeks, we might be > able to approach a 0.1 version in the near future. While not > having the number of > widgets that wxRuby has, it has a number of features inherit to > using SWIG, like being > able to override a virtual C++ class''s methods. I don''t have DSL > until monday, so it > won''t be in CVS until later.This is excellent... good work!> The bad news is that, unlike wxruby, it takes a trained expert to > get this thing to build. > Let me explain. To build the code of a release version, you need > wxWidgets 2.4 > compiled with RTTI enabled. To do this using the MSVC makefiles > requires modifying > the wxWidgets makefiles to enable these features (I suppose the > VC++ project files only > require finding the checkbox, but it''s still non-trivial). I > don''t think this is a default in > any of the wxWidgets platforms, and will be a major point of > contention with new users. > To actually do any development with wxruby-swig (add new classes, > etc), you need a > patched version of SWIG, rake (which won''t work on Ruby 1.6, > only 1.8), and in the > worst case, NQXML. I know rake still needs some work - it''s > confirmed not to work with > MSYS, and requires some work in MSVC.Yes, I think this will be a problem. We need to soften the blow as much as possible. At a minimum, a detailed step-by-step procedure for doing a build.> Personally, I see this as a real drag in getting volunteer > developers. If you can''t figure > out the build environment, then you won''t help, end of story. On > the other hand, in a > few months we may be able to work out some of the oddities (I > think wxWidgets is > moving towards supporting RTTI, for example).Agreed.> My questions are: > > 1) Should wxruby-swig focus on stability or being the > bleeding-edge? If it should be a > bleeding edge project, then maybe the focus should be on getting > support for > wxWidgets 2.5 (which has much better macintosh support, and is in > general considered > groovy). It may give a little more time to stablize the build system too.I guess that depends on how anxious Kevin is to have wxruby-swig replace wxruby.> 2) Am I worrying too much about the build system? How important > is it to the public to > know how to hack on this? Is requiring special builds of > wxWidgets an issue?As I said above, I think a clear step-by-step build procedure will go a long way towards mitigating the problem. Curt> 3) Are there any features not present in wxruby you really want > to see in wxruby-swig? > get/set methods aliased to accessors? HTML widgets? Other? > > I''m hoping to generate some discussion on this topic, so feel > free to speak up (even the > crew of 60 people who download the pre-built OS X version - shout > out to my homies!) > > Later, > > Nick
Thanks for the hard work Nick. As for the complexity of compiling wxruby-swig, I don''t think the end user (wxRuby developer) will need to compile from source much, provided that there are builds available that support XRC, OpenGL and ODBC. I find that those are the only things I change when compiling wxWidgets. Also having current prebuilt Windows, Mac OS X and Linux/BSD versions would cut down on the need for the end user to compile. I would only target wxWidgets 2.5 if you think that will be the stable build when wxruby-swig is ready for primetime, by doing this you will help reduce the finger pointing when something goes wrong. My 2 cents Sean Long Nick wrote:> > Hey everybody, > > I''ve made some progress on wxruby-swig, and have some good news and some bad > news. > > The good news is that the MSVC version finally can run all of the samples provided in > CVS. I''m using the same solve-by-ignore solution to the GC problem that wxruby uses, > so there is far less crashing goin'' on. Depending on the next few weeks, we might be > able to approach a 0.1 version in the near future. While not having the number of > widgets that wxRuby has, it has a number of features inherit to using SWIG, like being > able to override a virtual C++ class''s methods. I don''t have DSL until monday, so it > won''t be in CVS until later. > > The bad news is that, unlike wxruby, it takes a trained expert to get this thing to build. > Let me explain. To build the code of a release version, you need wxWidgets 2.4 > compiled with RTTI enabled. To do this using the MSVC makefiles requires modifying > the wxWidgets makefiles to enable these features (I suppose the VC++ project files only > require finding the checkbox, but it''s still non-trivial). I don''t think this is a default in > any of the wxWidgets platforms, and will be a major point of contention with new users. > To actually do any development with wxruby-swig (add new classes, etc), you need a > patched version of SWIG, rake (which won''t work on Ruby 1.6, only 1.8), and in the > worst case, NQXML. I know rake still needs some work - it''s confirmed not to work with > MSYS, and requires some work in MSVC. > > Personally, I see this as a real drag in getting volunteer developers. If you can''t figure > out the build environment, then you won''t help, end of story. On the other hand, in a > few months we may be able to work out some of the oddities (I think wxWidgets is > moving towards supporting RTTI, for example). > > My questions are: > > 1) Should wxruby-swig focus on stability or being the bleeding-edge? If it should be a > bleeding edge project, then maybe the focus should be on getting support for > wxWidgets 2.5 (which has much better macintosh support, and is in general considered > groovy). It may give a little more time to stablize the build system too. > > 2) Am I worrying too much about the build system? How important is it to the public to > know how to hack on this? Is requiring special builds of wxWidgets an issue? > > 3) Are there any features not present in wxruby you really want to see in wxruby-swig? > get/set methods aliased to accessors? HTML widgets? Other? > > I''m hoping to generate some discussion on this topic, so feel free to speak up (even the > crew of 60 people who download the pre-built OS X version - shout out to my homies!) > > Later, > > Nick > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users >
Thanks for getting the ball rolling on this! On Sun, 08 Aug 2004 22:00:42 -0500, Nick <devel@nicreations.com> wrote:> > > Hey everybody, >> Personally, I see this as a real drag in getting volunteer developers. If you can''t figure > out the build environment, then you won''t help, end of story. On the other hand, in a > few months we may be able to work out some of the oddities (I think wxWidgets is > moving towards supporting RTTI, for example).It IS a real drag. I would love to see ruby have a great cross platform UI toolkit, but if I can''t figure out how to build the thing, then I can''t submit patches or delve into the code to help fix bugs. I''m lazy, even for a programmer, and you are right, if I can''t build it then I "just won''t help"> > My questions are: > > 1) Should wxruby-swig focus on stability or being the bleeding-edge? If it should be a > bleeding edge project, then maybe the focus should be on getting support for > wxWidgets 2.5 (which has much better macintosh support, and is in general considered > groovy). It may give a little more time to stablize the build system too.My gut reaction is to support 2.5. Better mac support would be great. I browsed the wxWidgets web site and couldn''t find any sort of time line or release plan. Do you know when it is expected to be released?> 2) Am I worrying too much about the build system? How important is it to the public to > know how to hack on this? Is requiring special builds of wxWidgets an issue?For the vast majority of users, I don''t think it will matter. But for anyone wishing to contribute, it is a big deal.> 3) Are there any features not present in wxruby you really want to see in wxruby-swig? > get/set methods aliased to accessors? HTML widgets? Other?I haven''t played with it enough to say yet.> I''m hoping to generate some discussion on this topic, so feel free to speak up (even the > crew of 60 people who download the pre-built OS X version - shout out to my homies!) > > Later, > > Nick > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users >
Nick wrote:> > Hey everybody, > > I''ve made some progress on wxruby-swig, and have some good news and some bad > news. >Thanks for your work ...> Personally, I see this as a real drag in getting volunteer developers. If you can''t figure > out the build environment, then you won''t help, end of story. On the other hand, in a > few months we may be able to work out some of the oddities (I think wxWidgets is > moving towards supporting RTTI, for example).I''ve tried a couple of times but I''ve never succeeded in compiling a working wxruby-swig with either MingW or the free MSVC. This is also down to my inexperience using compilers on MSW, but does mean that the prospect of being able to contribute swig .i files etc seems a long way off for me, even though I know a bit of SWIG on *nix.> 1) Should wxruby-swig focus on stability or being the bleeding-edge? If it should be a > bleeding edge project, then maybe the focus should be on getting support for > wxWidgets 2.5 (which has much better macintosh support, and is in general considered > groovy). It may give a little more time to stablize the build system too.I guess I''d like to see wxruby-swig get stable and complete enough to replace wxruby-0.4.0 as the default build (and binary release) as soon as possible before tackling 2.5.2 or other extras. Then those who have got the build environment working can contribute what they can without having that work thrown away in a later move to swig. I''ve held off reporting some possible bugs I''ve come across in wxruby because of its status as a dead-end development path. Part of what improves a package is people''s testing and QA, and the sooner wxruby-swig becomes the release version, the more effort we''ll get directed there that''ll be useful in the long run.> 3) Are there any features not present in wxruby you really want to see in wxruby-swig? > get/set methods aliased to accessors? HTML widgets? Other?I''m keen on the introduction of ruby-style accessors, but have a fairly reliable pure ruby solution using alias that allows me to use that style for now. Since you asked :) - my personal Wx wishlist, in descending order: SashWindow, Clipboard, SystemSettings, Unicode, HTML. All that said, WxRuby is mostly good enough for me at the moment, and these things take as long as they take ... cheers alex
Nick wrote:> I''ve made some progress on wxruby-swig, and have some good news and some bad > news.Thanks much, Nick. I have been very frustrated that I have not had much time for wxruby recently, so I am thrilled that you have stepped in and helped out so much.> The good news is that the MSVC version finally can run all of the samples provided in > CVS. I''m using the same solve-by-ignore solution to the GC problem that wxruby uses, > so there is far less crashing goin'' on.We believe the crashing Nick is seeing is because he is using a release version of SWIG, rather than the patched version I have. The required patch has already been checked into SWIG''s cvs tree, so we''re just waiting for them to do a release. Unfortunately, the SWIG project has an eccentric release process.> The bad news is that, unlike wxruby, it takes a trained expert to get this thing to build. > Let me explain. To build the code of a release version, you need wxWidgets 2.4 > compiled with RTTI enabled.Is this due to an inherant SWIG requirement? Is the problem that MSVC defaults to RTTI off, where other compilers default it on?> 1) Should wxruby-swig focus on stability or being the bleeding-edge? If it should be a > bleeding edge project, then maybe the focus should be on getting support for > wxWidgets 2.5 (which has much better macintosh support, and is in general considered > groovy). It may give a little more time to stablize the build system too.My concern is that any time spent on the old wxruby code is wasted effort. The sooner we migrate, the better. Thus, I would lean toward continuing to target wxWindows 2, making wxruby-swig a drop-in replacement for wxruby.> 2) Am I worrying too much about the build system? How important is it to the public to > know how to hack on this? Is requiring special builds of wxWidgets an issue?Honestly, only a handful of people have helped with wxruby coding so far. Most people just want to use it, not hack on it. I think if we have to choose between a robust library that is easy for the core developers to maintain and enhance, or a clumsy orphan technology that theoretically could be hacked by more people, I would choose the former.> 3) Are there any features not present in wxruby you really want to see in wxruby-swig? > get/set methods aliased to accessors? HTML widgets? Other?One big request, which may even be worth putting in wxruby right away (as well as wxruby-swig), is support for generic event handling. That way, events can be handled even if we don''t yet have classes and methods to fully support them. I think this is possible, but haven''t yet done a detailed analysis. One other note: At least until I get back to being able to do heavy development, I really don''t feel like I am the project dictator. At this moment, Nick is leading the development effort, so he (obviously?) has a strong voice in the direction of wxruby and wxruby-swig. Kevin
Quoting Kevin Smith <wxruby@qualitycode.com>:> We believe the crashing Nick is seeing is because he is using a release > version of SWIG, rather than the patched version I have.That was a major one. The last source of crashy-crashy was MSVC''s problems with dynamic_cast (as discussed below).> The required > patch has already been checked into SWIG''s cvs tree, so we''re just > waiting for them to do a release. Unfortunately, the SWIG project has an > eccentric release process.Ok, thats good to hear. Dependancies on patched non-released tools gives me the willies.> > To build the code of a release version, you need wxWidgets 2.4 > > compiled with RTTI enabled. > > Is this due to an inherant SWIG requirement? Is the problem that MSVC > defaults to RTTI off, where other compilers default it on?It''s because of the directors. Doing the director checks requires casting a wxObject to a Swig::Director in a number of places using dynamic_cast, which uses RTTI. I think by default wxWidgets turns RTTI off as it uses wxClassInfo. This may not be as much as an issue as I thought; see below.> My concern is that any time spent on the old wxruby code is wasted > effort. The sooner we migrate, the better. Thus, I would lean toward > continuing to target wxWindows 2, making wxruby-swig a drop-in > replacement for wxruby.I can understand that. The problem is that we''re replacing a battle tested system with a totally different one, which is hard to even in the open source world - see the attempts to get people to migrate to Apache 2. Since the system is out there and people are using it, pretending it never existed will probably result in confusion. Developers who have written anything with wxRuby will probably not want to migrate right away as well. A possible suggestion is to close off feature additions to wxruby and brand it as a 1.0 release. I know we had the discussion of going 1.0 a while back (which I was not an advocate of) it might be better than a denial-of-existence-attack of the current wxRuby, which has grown nicely in the past year. We have been fixing bugs and adding widgets, but I don''t think there have been any major overhauls for the past couple of months except the move to SWIG. If we did go the 1.0 route, developers could play around with 1.0 as we try to get wxruby-swig (wxruby 2.0) up to speed.> Honestly, only a handful of people have helped with wxruby coding so > far. Most people just want to use it, not hack on it. I think if we have > to choose between a robust library that is easy for the core developers > to maintain and enhance, or a clumsy orphan technology that > theoretically could be hacked by more people, I would choose the former.The problem is that at some point people will have a configuration that doesn''t fall in the prebuilt builds and will have to run the extconf file. wxWidgets has a billion compile options, and it''s hard to cover them all. Up until now, the wxRuby releases have been just the ruby extension code. I think we could take a hint from wxPython and include *everything* in our releases: pre-SWIGged source code, the wxWidgets-2.4.2 release, and possibly rake. Our extconf.rb file will build wxWidgets specifically for wxRuby, and then build wxRuby. The SWIG issue will not affect the user, as we will have pre-SWIGged the source, and the RTTI issue won''t cause any problems because we control the wxWidgets build too. A side benefit is that this will make it easier to GEM wxRuby, since everything needed will be bundled into a release.> One big request, which may even be worth putting in wxruby right away > (as well as wxruby-swig), is support for generic event handling. That > way, events can be handled even if we don''t yet have classes and methods > to fully support them. I think this is possible, but haven''t yet done a > detailed analysis.Just so I see if I understand - is this the ability to handle events generically as opposed to capturing only the ones we handle?> One other note: At least until I get back to being able to do heavy > development, I really don''t feel like I am the project dictator. At this > moment, Nick is leading the development effort, so he (obviously?) has a > strong voice in the direction of wxruby and wxruby-swig.Hey, it ain''t my car; I''m just borrowing the keys. ;-) Even if you aren''t leading the charge in development at the moment, your experience and advice is very important. When you''re ready to lead the development charge again, the chair will be where you left it. Nick
devel@nicreations.com wrote:> Quoting Kevin Smith <wxruby@qualitycode.com>: >>>To build the code of a release version, you need wxWidgets 2.4 >>>compiled with RTTI enabled.I just checked in code that replaces the dynamic_cast with an old-style C cast. My hope is that it will avoid the need for RTTI, but will still work correctly. On my linux box, it still works fine. I look forward to hearing whether it works on other platforms.> I can understand that. The problem is that we''re replacing a battle tested > system with a totally different one, which is hard to even in the open source > world - see the attempts to get people to migrate to Apache 2. Since the system > is out there and people are using it, pretending it never existed will probably > result in confusion. Developers who have written anything with wxRuby will > probably not want to migrate right away as well.Interesting. My goal is that wxruby-swig is literally a drop-in replacement. If there is a reason to hesitate switching, then I would argue that wxruby-swig is not yet ready to replace wxruby.> A possible suggestion is to close off feature additions to wxruby and brand it > as a 1.0 release.Interesting idea. I am open to it, partcularly if we can fix all the memory leaks and crashes. I am interested in hearing from wxruby users whether they feel the current wxruby is close to something that could be called 1.0.> The problem is that at some point people will have a configuration that doesn''t > fall in the prebuilt builds and will have to run the extconf file. wxWidgets > has a billion compile options, and it''s hard to cover them all. > > Up until now, the wxRuby releases have been just the ruby extension code. I > think we could take a hint from wxPython and include *everything* in our > releases: pre-SWIGged source code, the wxWidgets-2.4.2 release, and possibly > rake. Our extconf.rb file will build wxWidgets specifically for wxRuby, and > then build wxRuby. The SWIG issue will not affect the user, as we will have > pre-SWIGged the source, and the RTTI issue won''t cause any problems because we > control the wxWidgets build too. A side benefit is that this will make it > easier to GEM wxRuby, since everything needed will be bundled into a release.Hm. Generally, I prefer to release as little as possible. The more packages we distribute, the more we are responsible for updating for bugs and security issues. If it''s necessary, fine, but I would certainly prefer to avoid it. Especially for a cross-platform project like this.> Just so I see if I understand - is this the ability to handle events generically > as opposed to capturing only the ones we handle?Yes, that is the requested feature: connect. Kevin