Hi I''d like to see if we can release 1.9.6 in the next week or so. I''m concerned that 1.9.5 and the current stable ruby don''t get on well. What we have left on the bug list is either trivial or things we can''t fix in wxRuby. Sean/Mario - how are you fixed at the moment re Windows builds on MSVC and MingW? Anyone - any testing time you can give to the samples on SVN HEAD would be great thanks alex
Hey Alex, On Tue, Apr 22, 2008 at 5:26 PM, Alex Fenton <alex at pressure.to> wrote:> Sean/Mario - how are you fixed at the moment re Windows builds on MSVC > and MingW?If you give me the week, I''ll try going with patchlevel 114, since I''ve been working SVN Versions of Ruby Core with our builds. If 114 turns out to be a drop in the wrong direction, I''ll down to 111, and see if I can get it to work there. I should hopefully have something for you by weeks end. And I''ll do a fresh checkout of SVN, to ensure that I''m using the latest HEAD, without any modifications. Anyone - any testing time you can give to the samples on SVN HEAD would> be greatI also will be running through these to, and fixing them up as I go, as far as the problems that were discussed before in regards to the begin, require, rescue, begin, require, load, end, end stuff that we have at the top of the examples. L8ers, -- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080423/c11cbe56/attachment.html
Hi Mario Mario Steele wrote:> > If you give me the week, I''ll try going with patchlevel 114, since > I''ve been working SVN Versions of Ruby Core with our builds. If 114 > turns out to be a drop in the wrong direction, I''ll down to 111, and > see if I can get it to work there.After I "upgraded" to 1.8.7 preview on Linux, I downgraded to p114. WxRuby on it seems very stable.> > Anyone - any testing time you can give to the samples on SVN HEAD > would > be great > > > I also will be running through these to, and fixing them up as I go, > as far as the problems that were discussed before in regards to the > begin, require, rescue, begin, require, load, end, end stuff that we > have at the top of the examples.I already fixed all the require lines. In one case my updater script broke a script, so still good to check em over. thanks alex
Hey Alex, On Wed, Apr 23, 2008 at 1:57 AM, Alex Fenton <alex at pressure.to> wrote:> After I "upgraded" to 1.8.7 preview on Linux, I downgraded to p114. > WxRuby on it seems very stable.Unfortunately, this doesn''t seem to be the case on MinGW. I am still getting crashes from bigdemo.rb concerning wx_droptarget, and Calendar crashes with a rb_gc_mark() unknown data type, for which I can only trace back to ProcessEvent() as the last part in wxRuby before it goes to Ruby''s GC Mark and Sweep stuff. Again, we''re looking at major bugs, all concerning the same problem. GC mark scan, is causing objects to not be properly referenced some how.> > > Anyone - any testing time you can give to the samples on SVN HEAD > > would > > be great > > > > > > I also will be running through these to, and fixing them up as I go, > > as far as the problems that were discussed before in regards to the > > begin, require, rescue, begin, require, load, end, end stuff that we > > have at the top of the examples. > I already fixed all the require lines. In one case my updater script > broke a script, so still good to check em over.We may not have a 1.9.6 MinGW Release, unless we can somehow figure out a way to see why we''re getting bad pointers. If we could somehow utilize "puts value.inspect" to inspect the object we get from st_foreach, and "puts rb_obj.inspect" from the SWIG_RubyReferenceToObject(value), to ensure that we''re getting what we actually want..... *sighs* How do you want to proceed? -- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-development/attachments/20080424/7b3a30c7/attachment-0001.html
Hey Alex, Okay, I have been able to verify that we are getting the correct information, including the Object ID, and the actual Ruby class reference during the GC_markIterate() on wxRubyApp. Now there''s been several crashes, at different points. First one, is the GC_mark_wxWindow(). It is failing on dialogs, specifically FontDialog, when it tries to do the wx_win->GetDropTarget(). Don''t ask me why, I have no idea. The second error, which I think traces back to general destruction under wxFont, wxColour, and Ultimately with wxTextDateAttribute or whatever it may be, it''s crashing at the MSVCRT level, not at the Ruby or wxRuby level. It''s either with UnRef() function, or with New allocator, and it comes from the iostream, or something similar, that is in MinGW. Both of these have me confuzelled, and I have no idea where to go from here. But I definately think there is something wrong here, specifically in the MinGW Build, which is the weirdest thing in the world. Any ideas? L8ers, On Thu, Apr 24, 2008 at 4:16 AM, Mario Steele <mario at ruby-im.net> wrote:> Hey Alex, > > On Wed, Apr 23, 2008 at 1:57 AM, Alex Fenton <alex at pressure.to> wrote: > > > After I "upgraded" to 1.8.7 preview on Linux, I downgraded to p114. > > WxRuby on it seems very stable. > > > Unfortunately, this doesn''t seem to be the case on MinGW. I am still > getting crashes from bigdemo.rb concerning wx_droptarget, and Calendar > crashes with a rb_gc_mark() unknown data type, for which I can only trace > back to ProcessEvent() as the last part in wxRuby before it goes to Ruby''s > GC Mark and Sweep stuff. > > Again, we''re looking at major bugs, all concerning the same problem. GC > mark scan, is causing objects to not be properly referenced some how. > > > > > > Anyone - any testing time you can give to the samples on SVN HEAD > > > would > > > be great > > > > > > > > > I also will be running through these to, and fixing them up as I go, > > > as far as the problems that were discussed before in regards to the > > > begin, require, rescue, begin, require, load, end, end stuff that we > > > have at the top of the examples. > > I already fixed all the require lines. In one case my updater script > > broke a script, so still good to check em over. > > > We may not have a 1.9.6 MinGW Release, unless we can somehow figure out a > way to see why we''re getting bad pointers. If we could somehow utilize > "puts value.inspect" to inspect the object we get from st_foreach, and "puts > rb_obj.inspect" from the SWIG_RubyReferenceToObject(value), to ensure that > we''re getting what we actually want..... *sighs* > > How do you want to proceed? > > > -- > Mario Steele > http://www.trilake.net > http://www.ruby-im.net > http://rubyforge.org/projects/wxruby/ > http://rubyforge.org/projects/wxride/ > http://rubyforge.org/projects/vwmc/ >-- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080426/f6b579ec/attachment.html>
Further testing, with a little throw in of manual debug information (Since GDB isn''t being nice), using the methods of GetClassInfo(), specifically GetSize(), GetClassName(), GetBaseClass1() and GetBaseClass2(). I did this so I could see if we are getting correct memory pointers, cause if we''re getting correct memory pointers, GetClassName, GetBaseClass1 and 2 all return wxStrings, for GetClassName() I''m getting just ''w'', GetBaseClass1() returns a bunch of binary bytes, GetBaseClass2() is returning null on every instance called when GC_mark_wxWindow() is called. Now, this tells me we are getting an invalid pointer. And the reason why I know this, is cause of the way memory allocation occurs, I''ve dealt with in another programming language that had the low level memory allocation routines available to you. All you have to do, is take the base address returned by the memory allocator, use math to add a number to it, for example 10, and it would offset the memory address by 10 bytes. Example: 0xF3EABC + 10 == Memory Address now 0xF3EACB. Add that to trying to read a structure, and passing the new pointer to the functions that read the information back out, and you litterally get jibberish back, since none of the offsets for the fields in the structure are correct anymore to get the data in the structure. So we are getting invalid pointers back, most likely from the SWIG_NewObject() function, or possibly the true Ruby object, and not the actual Wrapped Pointer to the wx Object. Which would explain the wxEvent bug having strange, crazy ass id''s with them, and the wxFont/Colour/DateTextAttr errors we are getting with the new allocator and the UnRef(), as memory is being unref''ed, and it''s not the correct address, causing a SegFault to occur. Amazing what you can learn about C/C++, from using an interpreted langauge that gives you access to those low level memory routines. Now the question remains, what is it, we''re actually getting back, a Pointer to the Swig wrapped object, a pointer to the Ruby Object, or a offsetted pointer to the wx object, that Swig has messed up. On Sat, Apr 26, 2008 at 4:33 PM, Mario Steele <mario at ruby-im.net> wrote:> Hey Alex, > > Okay, I have been able to verify that we are getting the correct > information, including the Object ID, and the actual Ruby class reference > during the GC_markIterate() on wxRubyApp. Now there''s been several crashes, > at different points. First one, is the GC_mark_wxWindow(). It is failing > on dialogs, specifically FontDialog, when it tries to do the > wx_win->GetDropTarget(). Don''t ask me why, I have no idea. > > The second error, which I think traces back to general destruction under > wxFont, wxColour, and Ultimately with wxTextDateAttribute or whatever it may > be, it''s crashing at the MSVCRT level, not at the Ruby or wxRuby level. > It''s either with UnRef() function, or with New allocator, and it comes from > the iostream, or something similar, that is in MinGW. > > Both of these have me confuzelled, and I have no idea where to go from > here. But I definately think there is something wrong here, specifically in > the MinGW Build, which is the weirdest thing in the world. Any ideas? > > L8ers, > > > On Thu, Apr 24, 2008 at 4:16 AM, Mario Steele <mario at ruby-im.net> wrote: > > > Hey Alex, > > > > On Wed, Apr 23, 2008 at 1:57 AM, Alex Fenton <alex at pressure.to> wrote: > > > > > After I "upgraded" to 1.8.7 preview on Linux, I downgraded to p114. > > > WxRuby on it seems very stable. > > > > > > Unfortunately, this doesn''t seem to be the case on MinGW. I am still > > getting crashes from bigdemo.rb concerning wx_droptarget, and Calendar > > crashes with a rb_gc_mark() unknown data type, for which I can only trace > > back to ProcessEvent() as the last part in wxRuby before it goes to Ruby''s > > GC Mark and Sweep stuff. > > > > Again, we''re looking at major bugs, all concerning the same problem. GC > > mark scan, is causing objects to not be properly referenced some how. > > > > > > > > > Anyone - any testing time you can give to the samples on SVN > > > HEAD > > > > would > > > > be great > > > > > > > > > > > > I also will be running through these to, and fixing them up as I go, > > > > as far as the problems that were discussed before in regards to the > > > > begin, require, rescue, begin, require, load, end, end stuff that we > > > > have at the top of the examples. > > > I already fixed all the require lines. In one case my updater script > > > broke a script, so still good to check em over. > > > > > > We may not have a 1.9.6 MinGW Release, unless we can somehow figure out > > a way to see why we''re getting bad pointers. If we could somehow utilize > > "puts value.inspect" to inspect the object we get from st_foreach, and "puts > > rb_obj.inspect" from the SWIG_RubyReferenceToObject(value), to ensure that > > we''re getting what we actually want..... *sighs* > > > > How do you want to proceed? > > > > > > -- > > Mario Steele > > http://www.trilake.net > > http://www.ruby-im.net > > http://rubyforge.org/projects/wxruby/ > > http://rubyforge.org/projects/wxride/ > > http://rubyforge.org/projects/vwmc/ > > > > > > -- > Mario Steele > http://www.trilake.net > http://www.ruby-im.net > http://rubyforge.org/projects/wxruby/ > http://rubyforge.org/projects/wxride/ > http://rubyforge.org/projects/vwmc/ >-- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080427/7cb0ddf8/attachment.html>
Hi Mario Thanks for your investigations. I''ve been looking at the MSVC build which has similar problems, and the MS debugger suggests that indeed the Event mark routine is getting an invalid pointer. When we''ve hit these sort of problems before, it''s shown up much worse on Windows, I think perhaps b/c of different memory allocation strategies. wxWidgets creates Event objects on the stack, not the heap, so rt of the problem is I don''t know of a way to know when they are finished with (unlike the way we use WindowDestroyEvent). One strange thing is that the two routes of C++ Event objects to Ruby Objects (EvtHandler#EventThunker and App#FilterEvent) neither specify a mark routine in the Data_Wrap_Struct call. So I don''t quite understand why the mark routine is getting called - they should be "unowned" by ruby except if Event.new is called on the ruby side, which is only in custom event handling. I guess the solution is either to 1) fix the mark routine 2) find out why the mark routine is getting called on Event objects that it shouldn''t or 3) find a different way to preserve ruby client data associated with event objects, which is why we have to have the mark routine in the first place. alex
That would indeed answer the problem with wxEvents, and make sense. But what of wxWindow / wxFontDialog. I would suggest testing to see what we are exactly getting, but the question becomes, how do we do such a thing. And should it even matter if we check or not. This was oviously working in the past, why is it now that we are getting these problems? Aside from it being a MinGW Build, I have yet to try this set, with Swig 1.3.34 instead of 1.3.35, but you said there were no changes as far as the Ruby side is concern. I''m going to look into that a bit more further. L8ers, On Sun, Apr 27, 2008 at 3:00 AM, Alex Fenton <alex at pressure.to> wrote:> Hi Mario > > Thanks for your investigations. I''ve been looking at the MSVC build which > has similar problems, and the MS debugger suggests that indeed the Event > mark routine is getting an invalid pointer. When we''ve hit these sort of > problems before, it''s shown up much worse on Windows, I think perhaps b/c of > different memory allocation strategies. > > wxWidgets creates Event objects on the stack, not the heap, so rt of the > problem is I don''t know of a way to know when they are finished with (unlike > the way we use WindowDestroyEvent). One strange thing is that the two routes > of C++ Event objects to Ruby Objects (EvtHandler#EventThunker and > App#FilterEvent) neither specify a mark routine in the Data_Wrap_Struct > call. So I don''t quite understand why the mark routine is getting called - > they should be "unowned" by ruby except if Event.new is called on the ruby > side, which is only in custom event handling. > > I guess the solution is either to 1) fix the mark routine 2) find out why > the mark routine is getting called on Event objects that it shouldn''t or 3) > find a different way to preserve ruby client data associated with event > objects, which is why we have to have the mark routine in the first place. > > > 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/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080427/e164232d/attachment-0001.html>
Hi Mario I''ve just committed a substantial set of changes to the way that events are managed between the C++ and Ruby side of the library. Seems we were running into one of the causes of hard-to-track bugs in the API. This is that SWIG will create "director" methods for any C++ method declared virtual in any ancestor class (including wxEvtHandler, for all wxWindow classes). These director methods will create a ruby wrapper for the C++ object then attempt to pass that object into ruby in a method call. Which is great, except if you weren''t expecting a ruby object to be created at that point. In this case, before normal event handlers were called, wxWidgets calls ProcessEvent, which SWIG passes to Ruby, including wrapping a short-lived (stack-based) C++ event object. The GC mark routines were getting called on these objects causing the crashes. I''ve fixed this with a directorin typemap to catch the times that the C++ API is passing the event object into a ruby method eg process_event. Anyway, could you svn up and see how it goes. bigdemo.rb seems much more stable, but I''d like to identify any errors that remain. cheers alex Mario Steele wrote:> That would indeed answer the problem with wxEvents, and make sense. > But what of wxWindow / wxFontDialog. I would suggest testing to see > what we are exactly getting, but the question becomes, how do we do > such a thing. And should it even matter if we check or not. This was > oviously working in the past, why is it now that we are getting these > problems? > > Aside from it being a MinGW Build, I have yet to try this set, with > Swig 1.3.34 instead of 1.3.35, but you said there were no changes as > far as the Ruby side is concern. I''m going to look into that a bit > more further.
Hey Alex, On Mon, Apr 28, 2008 at 3:28 PM, Alex Fenton <alex at pressure.to> wrote:> Hi Mario > > I''ve just committed a substantial set of changes to the way that events > are managed between the C++ and Ruby side of the library. > > Seems we were running into one of the causes of hard-to-track bugs in the > API. This is that SWIG will create "director" methods for any C++ method > declared virtual in any ancestor class (including wxEvtHandler, for all > wxWindow classes). These director methods will create a ruby wrapper for the > C++ object then attempt to pass that object into ruby in a method call. > Which is great, except if you weren''t expecting a ruby object to be created > at that point. > > In this case, before normal event handlers were called, wxWidgets calls > ProcessEvent, which SWIG passes to Ruby, including wrapping a short-lived > (stack-based) C++ event object. The GC mark routines were getting called on > these objects causing the crashes. I''ve fixed this with a directorin typemap > to catch the times that the C++ API is passing the event object into a ruby > method eg process_event. > > Anyway, could you svn up and see how it goes. bigdemo.rb seems much more > stable, but I''d like to identify any errors that remain.Well, looks like for now, as far as I can tell, Events are being handled properly. I can''t say for certain, as I still have wxWindow bugging out due to the failure to get a Drop Target from the wxFontDialog demo example. Debug: Program received signal SIGSEGV, Segmentation fault. 0x00220528 in ?? () (gdb) whe #0 0x00220528 in ?? () #1 0x6806a0c2 in GC_mark_wxWindow (ptr=0x2ccd1b8) at src/wx.cpp:2485 #2 0x66baea59 in rb_mark_hash () from E:\system\ruby\bin\msvcrt-ruby18.dll #3 0x686a9435 in wxRubyApp::markIterate (key=93954929, value=104909377, lev=0) at src/App.cpp:2317 #4 0x66bf634c in st_foreach () from E:\system\ruby\bin\msvcrt-ruby18.dll #5 0x686a9476 in wxRubyApp::mark_wxRubyApp (ptr=0x2cd55a0) at src/App.cpp:2346 #6 0x66baea59 in rb_mark_hash () from E:\system\ruby\bin\msvcrt-ruby18.dll #7 0x66baeb60 in rb_mark_hash () from E:\system\ruby\bin\msvcrt-ruby18.dll #8 0x66baf2a4 in rb_gc_mark_frame () from E:\system\ruby\bin\msvcrt-ruby18.dll #9 0x66bafac5 in rb_newobj () from E:\system\ruby\bin\msvcrt-ruby18.dll #10 0x66b9c442 in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #11 0x66b9d77b in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #12 0x66b9e151 in rb_respond_to () from E:\system\ruby\bin\msvcrt-ruby18.dll #13 0x66b9e294 in rb_funcall () from E:\system\ruby\bin\msvcrt-ruby18.dll #14 0x680690fe in wxRuby_WrapWxEventInRuby (wx_event=0x246eff0) at src/wx.cpp:2363 #15 0x67ceda97 in SwigDirector_wxFrame::ProcessEvent (this=0x2da8458, event=@0x246eff0) at src/Frame.cpp:2418 #16 0x680a74cb in wxWindowBase::TryParent () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4. 5/ext/new_allocator.h:69 #17 0x680b722e in wxEvtHandler::ProcessEvent () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4. 5/ext/new_allocator.h:69 #18 0x67cc1a29 in _wrap_wxEvtHandler_ProcessEvent (argc=1, argv=0x246dec0, self=52207632) at src/EvtHandler.cpp:2718 #19 0x66b9d3a0 in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #20 0x66b9d77b in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #21 0x66b9e151 in rb_respond_to () from E:\system\ruby\bin\msvcrt-ruby18.dll #22 0x66b9e294 in rb_funcall () from E:\system\ruby\bin\msvcrt-ruby18.dll #23 0x67f3f24b in SwigDirector_wxSplitterWindow::ProcessEvent ( this=0x2dad3e8, event=@0x246eff0) at src/SplitterWindow.cpp:2133 #24 0x680a74cb in wxWindowBase::TryParent () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4. 5/ext/new_allocator.h:69 #25 0x680b722e in wxEvtHandler::ProcessEvent () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4. 5/ext/new_allocator.h:69 #26 0x67cc1a29 in _wrap_wxEvtHandler_ProcessEvent (argc=1, argv=0x246e2a0, self=52207584) at src/EvtHandler.cpp:2718 #27 0x66b9d3a0 in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #28 0x66b9d77b in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #29 0x66b9e151 in rb_respond_to () from E:\system\ruby\bin\msvcrt-ruby18.dll The lines are off, cause I added #ifdef''s for __WXDEBUG__ for the routines I devised for trying to print out the GetClassInfo() information, which still remains to show that there is some kind of pointer offset going on. Also Calendar.rb demo is still bugging out, with an UnRef segfault on wxObject. Debug: 0x6806b781 in wxObject::UnRef () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 69 ~new_allocator() throw() { } Current language: auto; currently c++ (gdb) whe #0 0x6806b781 in wxObject::UnRef () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 #1 0x680c7d67 in wxFontBase::~wxFontBase () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 #2 0x680c1147 in wxFont::~wxFont () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 #3 0x67c2dd89 in free_wxCalendarDateAttr (arg1=0x2e5b220) at F:/wxWidgets-2.8.7/include/wx/generic/calctrl.h:136 #4 0x66baf62a in rb_gc_mark_frame () from E:\system\ruby\bin\msvcrt-ruby18.dll #5 0x66bafac5 in rb_newobj () from E:\system\ruby\bin\msvcrt-ruby18.dll #6 0x66b9c442 in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #7 0x66b9d77b in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #8 0x66b9e151 in rb_respond_to () from E:\system\ruby\bin\msvcrt-ruby18.dll #9 0x66b9e294 in rb_funcall () from E:\system\ruby\bin\msvcrt-ruby18.dll #10 0x680690fe in wxRuby_WrapWxEventInRuby (wx_event=0x246f140) at src/wx.cpp:2363 #11 0x67ceda97 in SwigDirector_wxFrame::ProcessEvent (this=0x2e4a498, event=@0x246f140) at src/Frame.cpp:2418 #12 0x680ab041 in wxWindowBase::UpdateWindowUI () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 #13 0x6802b4dc in _wrap_wxWindow_UpdateWindowUI (argc=1, argv=0x246f3f0, self=51793968) at src/Window.cpp:11002 #14 0x66b9d3a0 in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #15 0x66b9d77b in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #16 0x66b9e151 in rb_respond_to () from E:\system\ruby\bin\msvcrt-ruby18.dll #17 0x66b9e294 in rb_funcall () from E:\system\ruby\bin\msvcrt-ruby18.dll #18 0x67ce6d52 in SwigDirector_wxFrame::UpdateWindowUI (this=0x2e4a498, flags=2) at src/Frame.cpp:2133 #19 0x68092bf3 in wxWindow::OnInternalIdle () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 #20 0x680b9bc1 in wxAppBase::SendIdleEvents () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 #21 0x680b9f35 in wxAppBase::ProcessIdle () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 #22 0x6836c1cf in wxEventLoopManual::Run () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 #23 0x680b969e in wxAppBase::MainLoop () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 #24 0x6836fbc7 in wxEntryReal () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 #25 0x680bef57 in wxEntry () at E:/system/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/ext/new_allocator.h:69 #26 0x67bd5d57 in _wrap_App_main_loop (argc=0, argv=0x0, self=51795456) at src/App.cpp:2374 #27 0x66b9d3a0 in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #28 0x66b9d77b in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #29 0x66b98de8 in rb_thread_schedule () from E:\system\ruby\bin\msvcrt-ruby18.dll #30 0x66ba53e5 in rb_eval_string () from E:\system\ruby\bin\msvcrt-ruby18.dll #31 0x66ba5416 in ruby_exec () from E:\system\ruby\bin\msvcrt-ruby18.dll #32 0x66ba6450 in ruby_run () from E:\system\ruby\bin\msvcrt-ruby18.dll #33 0x00401341 in main (argc=2, argv=0x223ef0, envp=0x222b18) at ../ruby_1_8/main.c:48 (gdb) If you want to see the jibberish it''s spewing out from the GetClassInfo() stuff, here''s the code: In order to make it show, you need to comment out, or remove the #ifdef __WXDEBUG__. Index: mark_free_impl.i ==================================================================--- mark_free_impl.i (revision 1700) +++ mark_free_impl.i (working copy) @@ -113,6 +113,13 @@ rb_gc_mark(rb_caret); } +#ifdef __WXDEBUG__ + printf("wxwinDEBUG> wx_win->GetClassInfo()\n"); + printf(" GetClassName() %s\n",wx_win->GetClassInfo()->GetClassName()); + printf(" GetBaseClass1() %s\n",wx_win->GetClassInfo()->GetBaseClass1()); + printf(" GetBaseClass2() %s\n",wx_win->GetClassInfo()->GetBaseClass2()); + printf(" GetSize() = %d\n",wx_win->GetClassInfo()->GetSize()); +#endif wxDropTarget* wx_droptarget = wx_win->GetDropTarget(); if ( wx_droptarget ) { Index: App.i ==================================================================--- App.i (revision 1700) +++ App.i (working copy) @@ -86,6 +86,9 @@ static int markIterate(VALUE key, VALUE value, int lev) { VALUE rb_obj = SWIG_RubyReferenceToObject(value); +#ifdef __WXDEBUG__ + printf(" rubyDEBUG> rb_obj.inspect = %s\n",STR2CSTR(rb_inspect(rb_obj))); +#endif // Check if it''s a valid object (sometimes SWIG doesn''t return what we''re // expecting), a descendant of Wx::Window, and if it has not yet been // deleted by WxWidgets; if so, mark it. -- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080430/68e07967/attachment-0001.html>
Mario Steele wrote:> > Well, looks like for now, as far as I can tell, Events are being > handled properly.Cool. This was the really difficult problem.> I can''t say for certain, as I still have wxWindow bugging out due to > the failure to get a Drop Target from the wxFontDialog demo example.Good news is I can reproduce those bugs on OS X. I guess I''ve never kicked those samples hard enough. They look like simple DISOWN fixes are needed. I''ll try and apply these later and wrap the build. thanks alex
On Wed, Apr 30, 2008 at 3:55 AM, Alex Fenton <alex at pressure.to> wrote:> Good news is I can reproduce those bugs on OS X. I guess I''ve never kicked > those samples hard enough. They look like simple DISOWN fixes are needed. > I''ll try and apply these later and wrap the build.I consider that more then good news, means I''m not going crazy over here in Windows land. LOL I''ll await your commit, to test it out over here. Also, I found a way to get MediaCtrl enabled, just as I did for GraphicsContext. Evidently the wxPython team never really looked to deeply into the problem / solution for it, and it''s very similar to the way we had to make GDI Compliant with MinGW for it to work with wxWidgets. Also, what I thought was Pointer corruption, wasn''t at all, just me either not utitlizing the correct methods, or me not utilizing a conversion method to turn it from Unicode to ASCII UTF8 format. Here''s the update components, it might be a smart idea to keep these around, just incase we need to do further debugging in the future (Hence why I threw them in under __WXDEBUG__ defines): Index: mark_free_impl.i ==================================================================--- mark_free_impl.i (revision 1700) +++ mark_free_impl.i (working copy) @@ -113,6 +113,14 @@ rb_gc_mark(rb_caret); } +#ifdef __WXDEBUG__ + wxClassInfo* wx_classinfo = wx_win->GetClassInfo(); + printf("wxwinDEBUG> wx_win->GetClassInfo()\n"); + printf(" GetClassName() = %s\n",(const char*)( wxString(wx_classinfo->GetClassName()).mb_str( wxConvUTF8 ) ) ); + printf(" GetBaseClass1() = %s\n",(const char*)( wxString(wx_classinfo->GetBaseClassName1()).mb_str( wxConvUTF8 ) ) ); + printf(" GetBaseClass2() = %s\n",(const char*)( wxString(wx_classinfo->GetBaseClassName2()).mb_str( wxConvUTF8 ) ) ); + printf(" GetSize() = %d\n",wx_classinfo->GetSize()); +#endif wxDropTarget* wx_droptarget = wx_win->GetDropTarget(); if ( wx_droptarget ) { -- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080430/21ffe994/attachment.html>
I''ve tagged 1.9.6 in the repo and uploaded the builds for the three "core" platforms. Mario, if you''d like to do a RELEASE-based build for mingw, that''d be great. My demo licence for VMWare which I used to build the linux-x86_64 build has run out and I don''t really feel like buying one ($70) cos I don''t have any other use for it. If anyone is keen and able to offer the gem on this platform get in touch. alex
Hey Alex, I did a gem build, but it''s over 11 megs, and I found out why, I still have O0 in there, and some other stuff that keeps the debugging symbols in for both wxRuby and wxWidgets. I am in the process of re-compiling wxWidgets at home, and when I get home in the morning (8AM CST), I''ll compile the MinGW Version, and release it. On Wed, Apr 30, 2008 at 7:37 PM, Alex Fenton <alex at pressure.to> wrote:> I''ve tagged 1.9.6 in the repo and uploaded the builds for the three "core" > platforms. > > Mario, if you''d like to do a RELEASE-based build for mingw, that''d be > great. > > My demo licence for VMWare which I used to build the linux-x86_64 build > has run out and I don''t really feel like buying one ($70) cos I don''t have > any other use for it. If anyone is keen and able to offer the gem on this > platform get in touch. > > > 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/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080501/8ff9b798/attachment.html>
Mario Steele wrote:> I did a gem build, but it''s over 11 megs, and I found out why, I still > have O0 in there, and some other stuff that keeps the debugging > symbols in for both wxRuby and wxWidgets. I am in the process of > re-compiling wxWidgets at home, and when I get home in the morning > (8AM CST), I''ll compile the MinGW Version, and release it.OK cool. With gcc-based builds, assuming it''s linked against a release build of Wx, I use strip -x lib/wxruby.so to minimise the library size by purging debugging symbols. IIRC this worked with MingW but I haven''t tried it for a while. Anyway, much quicker than recompiling! alex
Yeah, that worked better..... LOL Down to 6.7 megs, instead of the 11.3 megs before. It dropped like a rock, bring the wxruby2.so file from 43 Megs to 17 Megs. BTW, I''m in the chat room, if you have time to stop by and chat for a second. On Thu, May 1, 2008 at 3:00 AM, Alex Fenton <alex at pressure.to> wrote:> Mario Steele wrote: > > > I did a gem build, but it''s over 11 megs, and I found out why, I still > > have O0 in there, and some other stuff that keeps the debugging symbols in > > for both wxRuby and wxWidgets. I am in the process of re-compiling > > wxWidgets at home, and when I get home in the morning (8AM CST), I''ll > > compile the MinGW Version, and release it. > > > OK cool. With gcc-based builds, assuming it''s linked against a release > build of Wx, I use > > strip -x lib/wxruby.so > > to minimise the library size by purging debugging symbols. IIRC this > worked with MingW but I haven''t tried it for a while. Anyway, much quicker > than recompiling! > > > 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/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080501/8cf03378/attachment.html>
BTW Alex, you forgot to upload the new Documents to the Website. I''d do it, but I can''t SCP at work, due to them blocking ssh ports. On Thu, May 1, 2008 at 3:20 AM, Mario Steele <mario at ruby-im.net> wrote:> Yeah, that worked better..... LOL Down to 6.7 megs, instead of the 11.3 > megs before. It dropped like a rock, bring the wxruby2.so file from 43 Megs > to 17 Megs. BTW, I''m in the chat room, if you have time to stop by and chat > for a second. > > > On Thu, May 1, 2008 at 3:00 AM, Alex Fenton <alex at pressure.to> wrote: > > > Mario Steele wrote: > > > > > I did a gem build, but it''s over 11 megs, and I found out why, I still > > > have O0 in there, and some other stuff that keeps the debugging symbols in > > > for both wxRuby and wxWidgets. I am in the process of re-compiling > > > wxWidgets at home, and when I get home in the morning (8AM CST), I''ll > > > compile the MinGW Version, and release it. > > > > > OK cool. With gcc-based builds, assuming it''s linked against a release > > build of Wx, I use > > > > strip -x lib/wxruby.so > > > > to minimise the library size by purging debugging symbols. IIRC this > > worked with MingW but I haven''t tried it for a while. Anyway, much quicker > > than recompiling! > > > > > > 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/ > http://rubyforge.org/projects/vwmc/ >-- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080502/28ffdc5e/attachment-0001.html>
Mario Steele wrote:> BTW Alex, you forgot to upload the new Documents to the Website. I''d > do it, but I can''t SCP at work, due to them blocking ssh ports.Thanks, done. Also I checked in some code for the mswin Rakefile that will bundle up vc80 dlls and install them and suitable manifests for ruby (and rubyw - good spot) along with the gem. Unless you can think of anything else urgent, I will probably tag 1.9.7 and release a mswin gem tomorrow. We can update the other gems for consistency at our leisure. The only other change is adding a dragdrop/clipboard sample i had kicking around my working copy. alex
I''d actually suggest doing 1.9.6.1 type release for the MSWin, so that way, we don''t jump versions when we do add other stuff that benifits all platforms, and we can keep the version numbering all correct. Either that, or just stick with 1.9.6, and update the current gem with the new stuff, and advise all users on the Ruby users list, of the changes to the gem, and if downloaded before you upload the new gem, to re-install it. Just my suggestion, what do you think? On Fri, May 2, 2008 at 6:24 PM, Alex Fenton <alex at pressure.to> wrote:> Mario Steele wrote: > > > BTW Alex, you forgot to upload the new Documents to the Website. I''d do > > it, but I can''t SCP at work, due to them blocking ssh ports. > > > Thanks, done. > > Also I checked in some code for the mswin Rakefile that will bundle up > vc80 dlls and install them and suitable manifests for ruby (and rubyw - good > spot) along with the gem. > > Unless you can think of anything else urgent, I will probably tag 1.9.7 > and release a mswin gem tomorrow. We can update the other gems for > consistency at our leisure. The only other change is adding a > dragdrop/clipboard sample i had kicking around my working copy. > > > 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/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080502/31c30945/attachment.html>
Mario Steele wrote:> I''d actually suggest doing 1.9.6.1 <http://1.9.6.1> type release for > the MSWin,That''d be my preferred option but rubygems only supports 3-number version schemes.> Either that, or just stick with 1.9.6, and update the current gem > with the new stuff, and advise all users on the Ruby users list, of > the changes to the gem, and if downloaded before you upload the new > gem, to re-install it. Just my suggestion, what do you think?I''m hesitant because we''ve had problems before uploading files over the same file, where the new file doesn''t get mirrored out correctly to the rubyforge download peers and people get served stale files. I''m willing to give it another go, but this time I''ve withdrawn the problem 1.9.6 mswin gem. I''ll leave it 12 hours or so, and if it seems to have been wiped from the gem system and mirrors, I''ll try tagging 1.9.6.1 and uploading it as 1.9.6. alex
BTW, on the AnimationCtrl, is there suppose to be 2 Images displayed, or only 1? Cause I''m getting 2 image controls displayed (Which You can use Wx::3DBORDER or Wx::BORDER in style to see it) See attached example. On Fri, May 2, 2008 at 7:31 PM, Alex Fenton <alex at pressure.to> wrote:> Mario Steele wrote: > > > I''d actually suggest doing 1.9.6.1 <http://1.9.6.1> type release for the > > MSWin, > > > That''d be my preferred option but rubygems only supports 3-number version > schemes. > > > Either that, or just stick with 1.9.6, and update the current gem with > > the new stuff, and advise all users on the Ruby users list, of the changes > > to the gem, and if downloaded before you upload the new gem, to re-install > > it. Just my suggestion, what do you think? > > > I''m hesitant because we''ve had problems before uploading files over the > same file, where the new file doesn''t get mirrored out correctly to the > rubyforge download peers and people get served stale files. > > I''m willing to give it another go, but this time I''ve withdrawn the > problem 1.9.6 mswin gem. I''ll leave it 12 hours or so, and if it seems to > have been wiped from the gem system and mirrors, I''ll try tagging 1.9.6.1and uploading it as > 1.9.6. > > > 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/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080502/68c86911/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: animationctrl_example.png Type: image/png Size: 20045 bytes Desc: not available URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080502/68c86911/attachment-0001.png>
BTW, also Wx::NULL_ANIMATION isn''t set, and passing Nil to the constructor for AnimationCtrl buggers out. Should use Wx::NULL_ANIMATION for both AnimationCtrl and Animation classes ctor''s. On Fri, May 2, 2008 at 7:44 PM, Mario Steele <mario at ruby-im.net> wrote:> BTW, on the AnimationCtrl, is there suppose to be 2 Images displayed, or > only 1? Cause I''m getting 2 image controls displayed (Which You can use > Wx::3DBORDER or Wx::BORDER in style to see it) See attached example. > > > On Fri, May 2, 2008 at 7:31 PM, Alex Fenton <alex at pressure.to> wrote: > > > Mario Steele wrote: > > > > > I''d actually suggest doing 1.9.6.1 <http://1.9.6.1> type release for > > > the MSWin, > > > > > That''d be my preferred option but rubygems only supports 3-number > > version schemes. > > > > > Either that, or just stick with 1.9.6, and update the current gem > > > with the new stuff, and advise all users on the Ruby users list, of the > > > changes to the gem, and if downloaded before you upload the new gem, to > > > re-install it. Just my suggestion, what do you think? > > > > > I''m hesitant because we''ve had problems before uploading files over the > > same file, where the new file doesn''t get mirrored out correctly to the > > rubyforge download peers and people get served stale files. > > > > I''m willing to give it another go, but this time I''ve withdrawn the > > problem 1.9.6 mswin gem. I''ll leave it 12 hours or so, and if it seems to > > have been wiped from the gem system and mirrors, I''ll try tagging > > 1.9.6.1 and uploading it as 1.9.6. > > > > > > 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/ > http://rubyforge.org/projects/vwmc/ >-- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ http://rubyforge.org/projects/vwmc/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20080502/75231e04/attachment.html>