similar to: Progress on wxruby-swig

REMINDER: wxruby-swig is an experimental rewrite of wxRuby, using SWIG. It is not yet useful. The official wxRuby is still at 0.2.1. The 0.0.3 release of wxruby-swig is able to run the "minimal.rb" sample, which includes menu event handling. As always, it is available at: http://qualitycode.com/repos/wxruby-swig/ I also created a tarball this time, so you can just download that and

In case you missed the earlier thread, I am exploring using SWIG as part of the wxRuby build process. So far, wxruby-swig is purely experimental, and supports almost no wx classes or methods. I just pushed wxruby-swig 0.0.2 up to my public darcs repo: http://qualitycode.com/repos/wxruby-swig/ As always, you can use wget if you don''t have darcs. If you really need a tarball

I have a minimal working version of a SWIG-based wxRuby that can bring up an empty Frame with a title. On my system, it crashes on exit. I suspect this is the same problem that I mentioned months ago when I first upgraded to wxWindows 2.4.2. The problem mysteriously vanished at some point, but now it is back. I fiddled with this new code for several frustrating hours, and couldn''t

REMINDER: This news is about the swig-based prototype. The main wxRuby release is still current at 0.3.0. I just pushed the latest wxruby-swig code to: http://qualitycode.com/repos/wxruby-swig Thanks to Nick for reminding me about the Window#paint method that wxRuby 0.3 supports. I had forgotten all about it. There may be other features that we manually added to wxRuby that I will need to

I''ve checked a number of new .i files into the wxruby-swig tree. Not all of them are fully tested, but I thought it would be better for them to be there than to have somebody start duplicating the work. I''ve also added the ''caret'' and ''image'' samples, as well as the generic etc/test.rb. These need the unreleased SWIG-1.3.22. The current

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

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

Hi everyone, As Kevin has just announced, wxruby-swig has been moved into CVS as a toplevel project. It still is not in a "releasable" form yet, but it now builds on more systems than it doesn''t, and is moving towards stability. Because of the complexity of the build environment, we''re using rake (http://rake.rubyforge.org) as a build system instead of the standard

As I have mentioned on this list before, my goal is to switch entirely away from CVS for managing the wxRuby source code. CVS is fundamentally broken in several ways, including: - Each developer needs write access to contribute effectively - Tagging and branching are weak - Checkins are file-based instead of patchset-based - Moving files or directories loses the history For me, the first one

At each step, I think I am past most of the big hurdles. At each step, I find another one. I''m sharing these development stories on the list for a few reasons: 1. Perhaps some of you will find the stories interesting 2. To preserve my lessons in the list archives so I, or someone else, can (re)learn from them later 3. As a record of tangible progress 4. To vent some frustration

It has been a frustrating couple days. I have been tracking down the bug where any wxruby-swig app will crash/segfault upon exit. Yesterday, I fixed the problem where the App object was being freed twice. Today, after several hours of debugging, I discovered that the Frame object is also being deleted twice (for a different reason). I have asked Lyle Johnson for some guidance, because it is

Nick wrote: > > I''m assuming you''ve installed ruby 1.8 over the Mac default? Yep, I installed 1.8 over the Debian default. I''m running Debian Linux atm, my Mac box is the next in line for me to get going. Zach > > Nick > > Zach Dennis wrote: > >> Nick wrote: >> >>> >>> What version of Swig do you have? Make sure it

Tonight, I generated a full set of almost 400 swiggable .h files, one for each wxWidgets class. I used the big xml file that I mentioned earlier, which itself was (apparently) scraped from the wxWidgets html help files. Several interesting notes: 1. REXML took forever to parse the 2.5 meg xml file. I didn''t want to do stream processing, and hoped to stay with a pure-ruby solution,

> Great news!! So is the swig-version going to be first released with 2.5 > support? The documentation I''m working on parses the 2.4 xml file. Will > the original parser create a xml file in the same format for 2.5 ? Thankfully, the XML hasn''t changed - I''m using the same file and removing the stripped methods. > I think a while back there was some talk

Greetings all, Over the last few months, while I have been busy on other projects, Nick and other folks have built wxruby-swig up to where it now supports about 120 classes, compared to the 139 in wxruby 0.6. When you include the fact that wxruby 0.6 had a few classes that really weren''t needed (because non-wx ruby versions work fine), it looks like wxruby-swig is actually very

I just checked in some good fixes. You can see the (full) Changelog here: http://qualitycode.com/repos/wxruby/ChangeLog Notable items: - Added shanko''s grid sample (thanks!) - Added support for ComboBox#get_value - Fixed *all* the known crashing bugs. The way I "fixed" the problems with get_client_data was to remove the set_client_data and get_client_data implementations. I

Feature Requests item #17477, was opened at 2008-01-25 01:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=17477&group_id=35 Category: None Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: wxruby fails with SWIG 1.3.33 Initial Comment: Using SourceMage GNU/Linux. Stable recently upgraded to

Good news and bad news. First he good news. wxruby-swig now compiles on Linux, Mac, and Windows using wxWidgets 2.5. I just patched a bug with the paint method today, but it''s getting very close to the first release of wxruby. With a little more cleanup, I think we''re getting ready to do a first release of it, which will hopefully replaced wxruby. Of course, the debug spew

I just pushed a new wxruby-swig, which includes the known MSWin rakefile changes. It also has some significant internal improvements that will make it easier to add classes, and it includes support for one new class (wxEvent). wxruby-swig is now licensed under the "MIT license". wxRuby will remain under the wxWindows license as long as we are releasing the old code base. When we

In trying to add wxTextCtrl to wxruby-swig, I''ve been running into a problem with the argument conversion that appears to be a SWIG director bug. It is tied to multiple inheritance, and is related to SWIG specifically making director''s ''initialize'' take a first argument, but because ''initialize'' is static there isn''t a self value