Hi, What about releasing a new version shortly ? This is a long-awaited request from several users especially for recent ruby-1.9.1 versions on MinGW. Cheers. Chauk-Mean.
+1 ;-) But please, review and apply the patches I sent some while ago. Some bugs are concerned and some enhancements (under ''patches'' in the tracker). Cheers, Pascal Chauk-Mean Proum a ?crit :> Hi, > > What about releasing a new version shortly ? > This is a long-awaited request from several users especially for > recent ruby-1.9.1 versions on MinGW. > > Cheers. > Chauk-Mean. > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development > >
Hi Pascal, 2009/9/3 Pascal Hurni <pascal_hurni at fastmail.fm>:> +1 ;-) > > But please, review and apply the patches I sent some while ago. > Some bugs are concerned and some enhancements (under ''patches'' in the > tracker).Enhancements are not really appropriate for a minor or bug fix release like 2.0.1. Conversely, I''ve already intended to look at bug [#26981] BookCtrlBase badly swig''ed: several methods missing from subclasses (like Choicebook#get_current_page). Could you provide a sample script that makes use of the missing methods ? Cheers. Chauk-Mean.
Chauk-Mean Proum wrote:> Conversely, I''ve already intended to look at bug [#26981] BookCtrlBase > badly swig''ed: several methods missing from subclasses (like > Choicebook#get_current_page).Pascal - thank you for this debugging and the patch. Like you say, a classic late-night error, and one I spent a lot of time chasing around when it turns out it was mainly the missing ''public'' statement. It is compiles fine for me and testing with the wxNotebook.rbw sample within bigdemo confirms that get_current_page was broken in 2.0.0 and fixed with this patch. I also needed to add a missing %nodirector for get_page_count in shared/bookctrls.i. I''ve committed this, assuming that it looks OK on MingW and Linux. One more puzzling thing is that Listbook appears to inherit from Control instead of BookCtrlBase - this should also be fixed before 2.0.1 alex
Chauk-Mean Proum wrote:> What about releasing a new version shortly ? > This is a long-awaited request from several users especially for > recent ruby-1.9.1 versions on MinGW.Sorry I''ve been slow. I''ve now fixed the major blocker for me which was that the latest update to Apple''s version of g++ couldn''t compile against current wxWidgets 2.8.10. I just found the answer on the wx-dev list and have committed a workaround. I''m now working OK on ruby 1.8 but still having problems with 1.9 with GLCanvas. I''m sure I''m compiling against the same installation of wxWidgets but I''m getting a SWIG warning then a compiler error, below. I know you did some work on correcting the GLCanvas constructors, is there anything that jumps out? Thanks alex __ swig/classes/include/wxGLCanvas.h:26: Warning(509): Overloaded method wxGLCanvas::wxGLCanvas(wxWindow *,wxWindowID,wxPoint const &,wxSize const &,long,wxString const &,int *,wxPalette const &) is shadowed by wxGLCanvas::wxGLCanvas(wxWindow *,wxWindowID,int *,wxPoint const &,wxSize const &,long,wxString const &,wxPalette const &) at swig/classes/include/wxGLCanvas.h:17. swig/classes/include/wxGLCanvas.h:34: Warning(509): Overloaded method wxGLCanvas::wxGLCanvas(wxWindow *,wxGLCanvas *,wxWindowID,wxPoint const &,wxSize const &,long,wxString const &,int *,wxPalette const &) is shadowed by wxGLCanvas::wxGLCanvas(wxWindow *,wxWindowID,int *,wxPoint const &,wxSize const &,long,wxString const &,wxPalette const &) at swig/classes/include/wxGLCanvas.h:17. swig/classes/include/wxGLCanvas.h:43: Warning(509): Overloaded method wxGLCanvas::wxGLCanvas(VALUE,wxWindow *,wxGLContext *,wxWindowID,wxPoint const &,wxSize const &,long,wxString const &,int *,wxPalette const &) is shadowed by wxGLCanvas::wxGLCanvas(wxWindow *,wxWindowID,int *,wxPoint const &,wxSize const &,long,wxString const &,wxPalette const &) at swig/classes/include/wxGLCanvas.h:17. Class: GLCanvas : Window class wxGLCanvas src/GLCanvas.cpp: In constructor ?SwigDirector_wxGLCanvas::SwigDirector_wxGLCanvas(VALUE, wxWindow*, wxWindowID, int*, const wxPoint&, const wxSize&, long int, const wxString&, const wxPalette&)?: src/GLCanvas.cpp:2349: error: no matching function for call to ?wxGLCanvas::wxGLCanvas(wxWindow*&, wxWindowID&, int*&, const wxPoint&, const wxSize&, long int&, const wxString&, const wxPalette&)? /usr/local/include/wx-2.8/wx/mac/carbon/glcanvas.h:71: note: candidates are: wxGLCanvas::wxGLCanvas(wxWindow*, const wxGLCanvas*, wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&, int*, const wxPalette&) /usr/local/include/wx-2.8/wx/mac/carbon/glcanvas.h:67: note: wxGLCanvas::wxGLCanvas(wxWindow*, const wxGLContext*, wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&, int*, const wxPalette&) /usr/local/include/wx-2.8/wx/mac/carbon/glcanvas.h:63: note: wxGLCanvas::wxGLCanvas(wxWindow*, wxWindowID, const wxPoint&, const wxSize&, long int, const wxString&, int*, const wxPalette&) /usr/local/include/wx-2.8/wx/mac/carbon/glcanvas.h:58: note: wxGLCanvas::wxGLCanvas(const wxGLCanvas&)
Pascal Hurni wrote:> I may ask the question in another way: Is there a release plan for > 2.1.0 in terms of approximate date and/or new features ?The best guide to what might be in a future development release is here: http://wxruby.rubyforge.org/wiki/wiki.pl?DevelopmentRoadmap There''s a good case for an incremental 2.1/2.2 release based on wxWidgets 2.8 and the current codebase, and also for a more drastic revision based on wxWidgets 3.0, possibly for Ruby 1.9 only. But as far as I know, neither of these options is being actively developed right at the moment, so there''s no date planned. best alex
Hi Alex, 2009/9/4 Alex Fenton <alex at pressure.to>:> I''m now working OK on ruby 1.8 but still having problems with 1.9 with > GLCanvas. I''m sure I''m compiling against the same installation of wxWidgets > but I''m getting a SWIG warning then a compiler error, below. I know you did > some work on correcting the GLCanvas constructors, is there anything that > jumps out?rev-2085 builds and works fine for me with ruby-1.9.1 on both Linux and MinGW. Do you have this problem on OSX ? Anyway, I will rebuild the latest trunk on MinGW and Linux and let you know. Cheers. Chauk-Mean
Chauk-Mean Proum wrote:> rev-2085 builds and works fine for me with ruby-1.9.1 on both Linux and MinGW. > Do you have this problem on OSX ? >Yes, but only with Ruby 1.9, which is strange.> Anyway, I will rebuild the latest trunk on MinGW and Linux and let you know.Thanks, please update SVN as I''ve committed fixes for several bugs from the tracker this afternoon. a
I tried to build wxRuby on MinGW (with 1.8.6 and 1.9.1) and because I had SWIG 1.3.36 the script told me to upgrade. So I downloaded the latest SWIG which is 1.3.40, ran rake and boom. The fixmodule.rb script complains for missing swig class. I downloaded SWIG 1.3.37 and everything ran okay. Maybe the max compatible version number for SWIG should be re-enabled in the script. Cheers, Pascal Alex Fenton a ?crit :> > Sorry I''ve been slow. I''ve now fixed the major blocker for me which > was that the latest update to Apple''s version of g++ couldn''t compile > against current wxWidgets 2.8.10. I just found the answer on the > wx-dev list and have committed a workaround. > > I''m now working OK on ruby 1.8 but still having problems with 1.9 with > GLCanvas. I''m sure I''m compiling against the same installation of > wxWidgets but I''m getting a SWIG warning then a compiler error, below. > I know you did some work on correcting the GLCanvas constructors, is > there anything that jumps out? > >
2009/9/4 Pascal Hurni <pascal_hurni at fastmail.fm>:> I tried to build wxRuby on MinGW (with 1.8.6 and 1.9.1) and because I had > SWIG 1.3.36 the script told me to upgrade. > So I downloaded the latest SWIG which is 1.3.40, ran rake and boom. The > fixmodule.rb script complains for missing swig class. > > I downloaded SWIG 1.3.37 and everything ran okay. > > Maybe the max compatible version number for SWIG should be re-enabled in the > script.The SWIG_MAXIMUM_VERSION is already defined to 1.3.38. This is the version I''m using. Cheers. Chauk-Mean.
2009/9/4 Alex Fenton <alex at pressure.to>:>> Anyway, I will rebuild the latest trunk on MinGW and Linux and let you >> know. > > Thanks, please update SVN as I''ve committed fixes for several bugs from the > tracker this afternoon. >So I''ve rebuilt wxRuby latest revision (revision 2094) : - for ruby-1.9.1-p243 - with wxWidgets-2.8.10 - both on mingw32 with gcc-3.4.5 and on Ubuntu Linux 32 bits with (Ubuntu) gcc-4.4.3 There was no problem during the builds and wxRuby samples work fine (including OpenGL samples). Your problem seems to be OS X specific. Cheers. Chauk-Mean.
Hi all, 2009/9/5 Mario Steele <mario at ruby-im.net>:> The thing that jumps out at me about this, is the definition of the > Overloaded method defers from the Virtual method defined in the wxWidgets > library: > >> swig/classes/include/wxGLCanvas.h:26: Warning(509): Overloaded method >> wxGLCanvas::wxGLCanvas(wxWindow *,wxWindowID,wxPoint const &,wxSize const >> &,long,wxString const &,int *,wxPalette const &) is shadowed by >> wxGLCanvas::wxGLCanvas(wxWindow *,wxWindowID,int *,wxPoint const &,wxSize >> const &,long,wxString const &,wxPalette const &) at >> swig/classes/include/wxGLCanvas.h:17.There are 4 constructors (I''ve just added the first one which is now the recommended one - see wxWidgets docs). In swig/classes/include/wxGLCanvas.h : wxGLCanvas(wxWindow *parent, wxWindowID id = wxID_ANY, int* attribList = 0, const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = 0, const wxString& name = wxT("GLCanvas"), const wxPalette& palette = wxNullPalette); wxGLCanvas(wxWindow* parent, wxWindowID id = wxID_ANY, const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = 0, const wxString& name = wxT("GLCanvas"), int* attribList = 0, const wxPalette& palette = wxNullPalette) ; wxGLCanvas(wxWindow* parent, wxGLCanvas* sharedCanvas = NULL, wxWindowID id = wxID_ANY, const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = 0, const wxString& name = wxT("GLCanvas"), int* attribList = 0, const wxPalette& palette = wxNullPalette); wxGLCanvas(wxWindow* parent, wxGLContext* sharedContext = NULL, wxWindowID id = wxID_ANY, const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = 0, const wxString& name = wxT("GLCanvas"), int* attribList = 0, const wxPalette& palette = wxNullPalette); SWIG only "recognizes" the first constructor. The 3 other constructors are "shadowed". Thus, I have the same 3 warnings both on MinGW and Linux : swig/classes/include/wxGLCanvas.h:26: Warning(509): Overloaded method wxGLCanvas::wxGLCanvas(wxWindow *,wxWindowID,wxPoint const &,wxSize const &,long,wxString const &,int *,wxPalette const &) is shadowed by wxGLCanvas::wxGLCanvas(wxWindow *,wxWindowID,int *,wxPoint const &,wxSize const &,long,wxString const &,wxPalette const &) at swig/classes/include/wxGLCanvas.h:17. swig/classes/include/wxGLCanvas.h:34: Warning(509): Overloaded method wxGLCanvas::wxGLCanvas(wxWindow *,wxGLCanvas *,wxWindowID,wxPoint const &,wxSize const &,long,wxString const &,int *,wxPalette const &) is shadowed by wxGLCanvas::wxGLCanvas(wxWindow *,wxWindowID,int *,wxPoint const &,wxSize const &,long,wxString const &,wxPalette const &) at swig/classes/include/wxGLCanvas.h:17. swig/classes/include/wxGLCanvas.h:43: Warning(509): Overloaded method wxGLCanvas::wxGLCanvas(VALUE,wxWindow *,wxGLContext *,wxWindowID,wxPoint const &,wxSize const &,long,wxString const &,int *,wxPalette const &) is shadowed by wxGLCanvas::wxGLCanvas(wxWindow *,wxWindowID,int *,wxPoint const &,wxSize const &,long,wxString const &,wxPalette const &) at swig/classes/include/wxGLCanvas.h:17. But the compilation of GLCanvas.cpp succeeds both on MinGW and Linux. I''ve looked at wxWidgets glcanvas.h for OS X (wx/mac/carbon/), and the first constructor is not defined which is the reason why the build fails. It''s a cross-platform issue of wxWidgets and it''s really a pity. To workaround this wxWidgets issue (and before a fix be available for OS X), we can disable the first constructor for OS X. But then on OS X, the GLCanvas initializer will not support keyword parameters and I will have to modify the OpenGL samples accordingly. What do you think about that ? But I still don''t understand why the build succeeds with ruby-1.8. Alex, are you really sure of your build environment ? Cheers. Chauk-Mean.
Hi Pascal Pascal Hurni wrote:> Maybe the max compatible version number for SWIG should be re-enabled > in the script.I re-enabled the test for SWIG_MAXIMUM_VERSION a few months ago (SVN:2063). Maybe you are looking at HEAD rather than the 2_0_stable branch in SVN? We haven''t yet merged all the fixes on the branch onto HEAD. cheers alex
Hi Alex, Have you taken a look at my following post ? http://rubyforge.org/pipermail/wxruby-development/2009-September/001664.html The summary : I''ve looked at wxWidgets glcanvas.h for OS X (wx/mac/carbon/), and the first constructor is not defined which is the reason why the build fails. It''s a cross-platform issue of wxWidgets and it''s really a pity. Cheers. Chauk-Mean.
Hi Chauk-Mean Chauk-Mean Proum wrote:> There are 4 constructors (I''ve just added the first one which is now > the recommended one - see wxWidgets docs)....> SWIG only "recognizes" the first constructor. The 3 other constructors > are "shadowed". > Thus, I have the same 3 warnings both on MinGW and Linux : >Can we %ignore the unused ones so they don''t produce warnings and document the correct form in the interface file?> But the compilation of GLCanvas.cpp succeeds both on MinGW and Linux. > > I''ve looked at wxWidgets glcanvas.h for OS X (wx/mac/carbon/), and the > first constructor is not defined which is the reason why the build > fails. It''s a cross-platform issue of wxWidgets and it''s really a > pity. >And it seems it''s fixed in wxWidgets 2.9 but won''t be backported to 2.8: http://trac.wxwidgets.org/ticket/11006#comment:1> To workaround this wxWidgets issue (and before a fix be available for > OS X), we can disable the first constructor for OS X. But then on OS > X, the GLCanvas initializer will not support keyword parameters and I > will have to modify the OpenGL samples accordingly. What do you think > about that ? >It''s not desirable, I agree. GLCanvas should have kword constructors. How important is the ability to explicitly set the GLContext, and not have it created implicitly? I see the wxWidgets docs recommend it "for future compatibility and flexibility" but does it actually allow wxRuby users to do anything they couldn''t otherwise? GLContext doesn''t seem to have any methods. Could we dispense with the fourth constructor that isn''t available on OS X, and have kword args apply to one of the others? If it is important, then I guess what we should do is code around it in Ruby. We ignore the fourth constructor and the missing SetCurrent(xxx) call for OS X, but allow those calls in Ruby but they do nothing on OS X. The most important thing is that Ruby code written on one platform will work on the others without the user having to test which OS they''re coding on. You understand this much better so I''ll leave it to you to decide which should become the canonical constructor for wxRuby.> But I still don''t understand why the build succeeds with ruby-1.8. > Alex, are you really sure of your build environment ?Yes, I should have double-checked. Unfortunately it was that my 1.8 tree was out of date. I updated and the build fails there now too with the same errors (the missing constructor, and the missing call to SetCurrent(const wxGLContext&) ) alex
Hi Chauk-Mean Alex Fenton wrote:> The most important thing is that Ruby code written on one platform > will work on the others without the user having to test which OS > they''re coding on. You understand this much better so I''ll leave it to > you to decide which should become the canonical constructor for wxRuby.I thought of another option, if you haven''t already considered this and decided which you prefer. We could make one of the old not-recommended-but-fully-supported options the standard ''new'' method, and provide the new fully-recommended-but-not-supported constructor as an alternate class method, eg ''new_without_context'' (I realise this name is ugly). Keyword parameters could then apply to both, and we would document that ''new_without_context'' is the future way, but won''t currently work on OS X. alex
Hi Alex, 2009/9/7 Alex Fenton <alex at pressure.to>:> I thought of another option, if you haven''t already considered this and > decided which you prefer.The first "non recommended" constructor is very close to the "recommended one" except the position of the attribList parameter : wxGLCanvas(wxWindow* parent, wxWindowID id = wxID_ANY, const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = 0, const wxString& name = wxT("GLCanvas"), int* attribList = 0, const wxPalette& palette = wxNullPalette) ; I was thinking about two options : 1/ the easy option : Support only this constructor (with keyword parameters). The recommended constructor will only be supported when we will switch to wxWidgets 2.9+. 2/ the ideal option : At the ruby level, the initializer (with also keyword parameters) will follow the previous constructor but with an additional parameter create_context = true. The idea is to create at the ruby level something like the following C++ constructor : wxGLCanvas(wxWindow* parent, wxWindowID id = wxID_ANY, const wxPoint& pos = wxDefaultPosition, const wxSize& size = wxDefaultSize, long style = 0, const wxString& name = wxT("GLCanvas"), int* attribList = 0, const wxPalette& palette = wxNullPalette, boolean create_context = true) ; By default, the GLContext is created and the ruby initializer will delegate to the previous C++ constructor. But in the future, if the create_context parameter is set to false (e.g. via the corresponding keyword parameter), then the ruby initializer will delegate to the recommended C++ constructor. This option has the benefit of providing a ruby initializer that is ready for a future support of the recommended C++ constructor. But I don''t know at the moment what is the best way to do that. Any idea ? What do you think about that ? Cheers. Chauk-Mean.
Hi Chauk-Mean Chauk-Mean Proum wrote:> I was thinking about two options : > 1/ the easy option : Support only this constructor (with keyword parameters). > The recommended constructor will only be supported when we will switch > to wxWidgets 2.9+. >I would be inclined to go with this, unless wxRuby users can do something useful with GLContext. Forward-compatibility is good, but not if wxWidgets doesn''t make it cross-platform compatible.> 2/ the ideal option : > At the ruby level, the initializer (with also keyword parameters) will > follow the previous constructor but with an additional parameter > create_context = true.I would do this by %renaming each of the two preferred constructors to something like ''new_with_context'' and ''new_without_context''. Then in Ruby we write a ''new'' method that checks for the create_context parameter and then hands off to the correct version. But honestly, I think this is only worth doing if providing GLContext enables significant additional functionality now. alex
2009/9/7 Alex Fenton <alex at pressure.to>:>> >> I was thinking about two options : >> 1/ the easy option : Support only this constructor (with keyword >> parameters). >> The recommended constructor will only be supported when we will switch >> to wxWidgets 2.9+. > > I would be inclined to go with this, unless wxRuby users can do something > useful with GLContext. Forward-compatibility is good, but not if wxWidgets > doesn''t make it cross-platform compatible. >OK. I''ve just committed the changes. Can you check the changes on OS X ? Cheers. Chauk-Mean.
Chauk-Mean Proum wrote:> OK. I''ve just committed the changes. > Can you check the changes on OS X ?Thanks. I checked and GLCanvas is fine, but GLContext fails on the standard constructor and the SetCurrent method, because they aren''t supported on OS X. Sorry to undo your work on this, but I thought this class is redundant b/c of the recent tweaks, so I removed it. Things are looking OK for me for a release (I''ve also briefly compiled and tested mswin32). Let me know if you think this is not the best we can do for now with GL. For the 2.0.1 ChangeLog I was going to delete everything previous to 2.0.0. The file is pretty large and not that interesting, I think. alex
Hi Alex, 2009/9/8 Alex Fenton <alex at pressure.to>:> > Things are looking OK for me for a release (I''ve also briefly compiled and > tested mswin32). Let me know if you think this is not the best we can do for > now with GL. > > For the 2.0.1 ChangeLog I was going to delete everything previous to 2.0.0. > The file is pretty large and not that interesting, I think.That''s fine for me. Let''s go for the release ! Cheers. Chauk-Mean.
Chauk-Mean Proum wrote:> That''s fine for me. Let''s go for the release !Thanks. It''s tagged, building now. If you''re finished first, please create the release on Rubyforge. http://wxruby.rubyforge.org/svn/tags/wxruby2/2.0.1/ cheers alex
2009/9/8 Alex Fenton <alex at pressure.to>:> Thanks. It''s tagged, building now. If you''re finished first, please create > the release on Rubyforge.I''ve uploaded the source tarball and the mingw32 gem for ruby-1.9.1 (p243). I''m building right now the mingw32 gem for ruby-1.8.6 (p369). Do you want me to build the x86 Linux gem ? Chauk-Mean.
Chauk-Mean Proum wrote:> I''ve uploaded the source tarball and the mingw32 gem for ruby-1.9.1 (p243). > I''m building right now the mingw32 gem for ruby-1.8.6 (p369). > > Do you want me to build the x86 Linux gem ?That would be great, thanks, if you have that build environment up-to-date. I''ve done Mac Ruby 1.9, 1.8 is building now. I''ll do mswin32 tomorrow. Just realised a funny side-effect of your doing the release on Rubyforge, that the announcement then goes out in French:> Le projet "wxRuby" (''wxruby'') a > publi? une nouvelle version du paquet ''wxRuby 2.0''. > Vous recevez ce courrier car vous avez demand? ? ?tre pr?venu lorsque de > nouvelles versions du paquet seraient publi?es. Si vous ne souhaitez plus ?tre > averti, allez sur RubyForge et cliquez sur le lien > <http://rubyforge.org/frs/monitor.php?filemodule_id=450&group_id=35&stop=1> .cheers alex
2009/9/9 Alex Fenton <alex at pressure.to>:>> Do you want me to build the x86 Linux gem ? > > That would be great, thanks, if you have that build environment up-to-date. >Done.> I''ve done Mac Ruby 1.9, 1.8 is building now. I''ll do mswin32 tomorrow.I''ll do the MinGW installer (with ruby-opengl and rmagick) this evening.> Just realised a funny side-effect of your doing the release on Rubyforge, > that the announcement then goes out in French:That''s the French touch :-) Chauk-Mean.