A few days ago, someone asked me why I am using wxpp instead of SWIG. The question prompted me to revisit and re-evaluate SWIG, and I now believe it would be best to convert wxRuby to SWIG. SWIG has greatly improved its C++ support since the last time I looked at it, and I think its Ruby support has improved quite a bit as well. Also, now that I have written wxpp, I understand the nature of what SWIG is trying to accomplish, so it is easier to understand the examples and documentation. Using SWIG should make it easier for more people to add support for additional classes and methods. It already has several features that I would hope to add to wxpp soon, and has others that would probably be difficult to add to wxpp. Essentially, SWIG seems to be a very mature, well-supported version of what wxpp could be. FXRuby and wxPython, which I consider to be close "cousins" of ours, both use SWIG. As an experiment, in an empty directory, I created a SWIG file that wraps a minimal Wx::App. I wrote a tiny ruby app that creates a Wx::App object, and calls set_vendor_name and get_vendor_name on it. It all works, and is pretty straightforward. (Note that main_loop is not there yet!) If we are going to switch, now is the perfect time. Instead of creating a .t file for each class, we can create a SWIG file for each class. Either way is about the same amount of work, but I believe the benefits of going with SWIG are compelling. The biggest drawback of going with SWIG is that I don''t think I can mix SWIG files and existing code. I''ll probably have to convert everything to SWIG before I can do a release. I would probably release 0.3 with the existing fixes and features, and then jump to a 0.5 SWIG release. Thoughts? Concerns? Agreement? Kevin
When I first looked at wxRuby, my first question was, "Why aren''t they using SWIG?" I''ve known about SWIG for a long time, and thought it was a great tool. I think that using SWIG would be a big win, even if it means tweaking/extending SWIG a bit - because then those features also get folded back into SWIG, and every other project that uses it. Also, if wxPython already uses SWIG, then the wxRuby team can collaborate with them, and get really good wxWidgets SWIG bindings, making it easier to support for other languages that SWIG supports. I realize that there would probably be a period of frustration in the beginning, but I also think it''s really important for open source projects to take advantage of tools like this, rather than re-inventing the wheel. It happens way too often in projects like this, and in the end more time is spent extending the home-grown tool than actually working on the project. Just my two cents, H On Tuesday 30 March 2004 08:45, Kevin Smith wrote:> A few days ago, someone asked me why I am using wxpp instead of SWIG. > The question prompted me to revisit and re-evaluate SWIG, and I now > believe it would be best to convert wxRuby to SWIG. > > SWIG has greatly improved its C++ support since the last time I looked > at it, and I think its Ruby support has improved quite a bit as well. > Also, now that I have written wxpp, I understand the nature of what SWIG > is trying to accomplish, so it is easier to understand the examples and > documentation. > > Using SWIG should make it easier for more people to add support for > additional classes and methods. It already has several features that I > would hope to add to wxpp soon, and has others that would probably be > difficult to add to wxpp. Essentially, SWIG seems to be a very mature, > well-supported version of what wxpp could be. FXRuby and wxPython, which > I consider to be close "cousins" of ours, both use SWIG. > > As an experiment, in an empty directory, I created a SWIG file that > wraps a minimal Wx::App. I wrote a tiny ruby app that creates a Wx::App > object, and calls set_vendor_name and get_vendor_name on it. It all > works, and is pretty straightforward. (Note that main_loop is not there > yet!) > > If we are going to switch, now is the perfect time. Instead of creating > a .t file for each class, we can create a SWIG file for each class. > Either way is about the same amount of work, but I believe the benefits > of going with SWIG are compelling. > > The biggest drawback of going with SWIG is that I don''t think I can mix > SWIG files and existing code. I''ll probably have to convert everything > to SWIG before I can do a release. I would probably release 0.3 with the > existing fixes and features, and then jump to a 0.5 SWIG release. > > Thoughts? Concerns? Agreement? > > Kevin > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users
Kevin, I agree with you. Going with Swig is probably the best thing to do at this point. Robert _________________________________________________________________ All the action. All the drama. Get NCAA hoops coverage at MSN Sports by ESPN. http://msn.espn.go.com/index.html?partnersite=espn
Hunter Kelly (hkelly@newbay.com) wrote:> I realize that there would probably be a period of frustration in the > beginning, but I also think it''s really important for open source projects > to take advantage of tools like this, rather than re-inventing the wheel. > It happens way too often in projects like this, and in the end more time > is spent extending the home-grown tool than actually working on the project.Fully agree. Nicely said. One more for SWIG. Sincerely, Gour -- Gour gour@mail.inet.hr Registered Linux User #278493
Hunter Kelly wrote:> Also, if wxPython already uses SWIG, then the wxRuby team can > collaborate with them, and get really good wxWidgets SWIG bindings, > making it easier to support for other languages that SWIG supports. > > On Tuesday 30 March 2004 08:45, Kevin Smith wrote: > > The biggest drawback of going with SWIG is that I don''t think I can mix > > SWIG files and existing code. I''ll probably have to convert everything > > to SWIG before I can do a release. I would probably release 0.3 with the > > existing fixes and features, and then jump to a 0.5 SWIG release. > > > > Thoughts? Concerns? Agreement?Go for it! At the time that you rescued wxRuby from my inability to devote much bandwidth to the wxRuby project I had, in fact, cloned the wxPython SWIG files and was proceeding to cut out the Python specific stuff as a starting point for wxRuby. Only you could assess whether or not this would be a good strategy at this point -- your knowledge of the problem domain might allow you do to a better job from scratch. But I mention it just in case. Curt --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.610 / Virus Database: 390 - Release Date: 3/3/2004
The thing I really like about wxpp is that it makes wxruby a pure ''ruby'' project - you don''t need a secondary tool to build it. That been said, I think SWIG is a pretty amazing tool and think it would be great to use it. One question: is there any plans to change the name mapping conventions from wxpp (MyMethod => my_method) when moving to SWIG? I''d like to leave that as-is, if possible. Nick Kevin Smith wrote:> A few days ago, someone asked me why I am using wxpp instead of SWIG. > The question prompted me to revisit and re-evaluate SWIG, and I now > believe it would be best to convert wxRuby to SWIG. > > SWIG has greatly improved its C++ support since the last time I looked > at it, and I think its Ruby support has improved quite a bit as well. > Also, now that I have written wxpp, I understand the nature of what > SWIG is trying to accomplish, so it is easier to understand the > examples and documentation. > > Using SWIG should make it easier for more people to add support for > additional classes and methods. It already has several features that I > would hope to add to wxpp soon, and has others that would probably be > difficult to add to wxpp. Essentially, SWIG seems to be a very mature, > well-supported version of what wxpp could be. FXRuby and wxPython, > which I consider to be close "cousins" of ours, both use SWIG. > > As an experiment, in an empty directory, I created a SWIG file that > wraps a minimal Wx::App. I wrote a tiny ruby app that creates a > Wx::App object, and calls set_vendor_name and get_vendor_name on it. > It all works, and is pretty straightforward. (Note that main_loop is > not there yet!) > > If we are going to switch, now is the perfect time. Instead of > creating a .t file for each class, we can create a SWIG file for each > class. Either way is about the same amount of work, but I believe the > benefits of going with SWIG are compelling. > > The biggest drawback of going with SWIG is that I don''t think I can > mix SWIG files and existing code. I''ll probably have to convert > everything to SWIG before I can do a release. I would probably release > 0.3 with the existing fixes and features, and then jump to a 0.5 SWIG > release. > > Thoughts? Concerns? Agreement? > > Kevin > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > >
Nick wrote:> > The thing I really like about wxpp is that it makes wxruby a pure ''ruby'' > project - you don''t need a secondary tool to build it. That been said, I > think SWIG is a pretty amazing tool and think it would be great to use it.Interesting point. One way to help with this is to have two different source distributions available. One would be "from bare metal", and would require you to have SWIG. The other would contain all the .cpp files that SWIG generated, so you could build wxRuby "from source", but not completely "from scratch".> One question: is there any plans to change the name mapping conventions > from wxpp (MyMethod => my_method) when moving to SWIG? I''d like to leave > that as-is, if possible.I think we have to leave the naming as it is today. SWIG can do it if you manually write a rule for each and every method. I''m going to try to find a way to automate that, but am skeptical that I will be able to. Kevin
Kevin Smith wrote:> > Nick wrote: > > > One question: is there any plans to change the name mapping conventions > > from wxpp (MyMethod => my_method) when moving to SWIG? I''d like > to leave > > that as-is, if possible. > > I think we have to leave the naming as it is today. SWIG can do it if > you manually write a rule for each and every method. I''m going to try to > find a way to automate that, but am skeptical that I will be able to.Lyle distributes FXRuby in its post-SWIG incarnation, but also includes the SWIG files. This gives you the best of both worlds while maintaining only a single distribution. I would suggest that we do the same. Actually, I currently do the analogous equivalent in the binary installer of wxRuby for Windows. Even though it is a binary distribution, I still include the source in a "src" subdirectory. Curt --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.610 / Virus Database: 390 - Release Date: 3/3/2004
Pardon me for quoting the wrong section of the original emails... :-( But, I''m sure you got the intended message anyway. Curt> -----Original Message----- > From: wxruby-users-bounces@rubyforge.org > [mailto:wxruby-users-bounces@rubyforge.org]On Behalf Of Curt Hibbs > Sent: Tuesday, March 30, 2004 10:25 AM > To: Kevin Smith; Wxruby developers'' list > Subject: RE: [Wxruby-users] Big question: Move to SWIG? > > > Kevin Smith wrote: > > > > Nick wrote: > > > > > One question: is there any plans to change the name mapping > conventions > > > from wxpp (MyMethod => my_method) when moving to SWIG? I''d like > > to leave > > > that as-is, if possible. > > > > I think we have to leave the naming as it is today. SWIG can do it if > > you manually write a rule for each and every method. I''m going to try to > > find a way to automate that, but am skeptical that I will be able to. > > Lyle distributes FXRuby in its post-SWIG incarnation, but also > includes the > SWIG files. This gives you the best of both worlds while > maintaining only a > single distribution. I would suggest that we do the same. > > Actually, I currently do the analogous equivalent in the binary > installer of > wxRuby for Windows. Even though it is a binary distribution, I > still include > the source in a "src" subdirectory. > > Curt > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.610 / Virus Database: 390 - Release Date: 3/3/2004 > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.610 / Virus Database: 390 - Release Date: 3/3/2004 >--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.610 / Virus Database: 390 - Release Date: 3/3/2004
Nick wrote:> > One question: is there any plans to change the name mapping conventions > > from wxpp (MyMethod => my_method) when moving to SWIG? I''d like to leave > > that as-is, if possible.Then, Kevin wrote:> I think we have to leave the naming as it is today. SWIG can do it if > you manually write a rule for each and every method. I''m going to try to > find a way to automate that, but am skeptical that I will be able to.Maybe this would be of interest....I just noticed some notes about how the wxPython folk(s) use SWIG and a little script to automate name changes the wxPython 2.5 release (released in just the last few days). "A few notes about how all of this was accomplished might be interesting... SWIG is now run twice for each module that it is generating code for. The first time it outputs an XML representaion of the parse tree, which can be up to 20MB and 300K lines in size! That XML is then run through a little Python script that creates a file full of SWIG %rename directives that take the wx off of the names, and also generates the Python compatibility file described above that puts the wx back on the names. SWIG is then run a second time to generate the C++ code to implement the extension module, and uses the %rename directives that were generated in the first step." (Reference:http://wxpython.org/migrationguide.php) Dan Teitsort -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20040406/937c32bc/attachment.htm
(Sorry for the reformat/repost. Hopefully this one is better. -- Dan) Nick wrote:> > One question: is there any plans to change the name mapping conventions > > from wxpp (MyMethod => my_method) when moving to SWIG? I''d like toleave> > that as-is, if possible.Then, Kevin wrote:> I think we have to leave the naming as it is today. SWIG can do it if > you manually write a rule for each and every method. I''m going to try to > find a way to automate that, but am skeptical that I will be able to.Maybe this would be of interest....I just noticed some notes about how the wxPython folk(s) use SWIG and a little script to automate name changes the wxPython 2.5 release (released in just the last few days). "A few notes about how all of this was accomplished might be interesting... SWIG is now run twice for each module that it is generating code for. The first time it outputs an XML representaion of the parse tree, which can be up to 20MB and 300K lines in size! That XML is then run through a little Python script that creates a file full of SWIG %rename directives that take the wx off of the names, and also generates the Python compatibility file described above that puts the wx back on the names. SWIG is then run a second time to generate the C++ code to implement the extension module, and uses the %rename directives that were generated in the first step." (Reference:http://wxpython.org/migrationguide.php) Dan Teitsort
Dan Teitsort wrote:> > Nick wrote: > > > > One question: is there any plans to change the name mapping > conventions > > > from wxpp (MyMethod => my_method) when moving to SWIG? I''d like to > leave > > > that as-is, if possible. > > > Then, Kevin wrote: > > > I think we have to leave the naming as it is today. SWIG can do it if > > you manually write a rule for each and every method. I''m going to try to > > find a way to automate that, but am skeptical that I will be able to. > > Maybe this would be of interest....I just noticed some notes about how the > wxPython folk(s) use SWIG and a little script to automate name changes the > wxPython 2.5 release (released in just the last few days). > > "A few notes about how all of this was accomplished might be > interesting... > SWIG is now run twice for each module that it is generating code for. The > first time it outputs an XML representaion of the parse tree, which can be > up to 20MB and 300K lines in size! That XML is then run through a little > Python script that creates a file full of SWIG %rename directives > that take > the wx off of the names, and also generates the Python compatibility file > described above that puts the wx back on the names. SWIG is then run a > second time to generate the C++ code to implement the extension > module, and > uses the %rename directives that were generated in the first step." > (Reference:http://wxpython.org/migrationguide.php)This is very interesting. Perhaps some part of the code that generates the renames could also be used to automatically (or semi-automatically) create documentation by reading the wxWidgets docs and performing the same rename transformations. Curt
Curt Hibbs wrote:> This is very interesting. Perhaps some part of the code that generates the > renames could also be used to automatically (or semi-automatically) create > documentation by reading the wxWidgets docs and performing the same rename > transformations.It is interesting. Thanks, Dan, for letting us know how wxPython is handling it. At first, I thought their approach seemed needlessly complex, but if they are getting documentation as well, it might be worth it. Right now, I am just hard-coding each rename, but that is already becoming too tedious and error-prone. My plan had been to have a program post-process the .cpp SWIG output files to perform at least the mechanical renames (remove wx, ConvertMixedCase to ruby_style_naming). I am already forced to post-process the SWIG output due to limitations of the Ruby code generation in SWIG, so this additional step would be pretty easy. I''ll take a look at the wxPython stuff to see if it can be reused. So far, whenever I have looked at wxPython they seem to be doing things in odd, non-standard ways. They are probably effective, but are very hard for an outsider to understand, and may be hard for a different project to reuse. But Robin (Mr. wxPython) is a good guy, so I should check with him. Thanks, Kevin