The following patches implement object tracking. Note nasty games I play to make the tracking global. SWIG 1.3.30 won''t need this. I also updated the minimum required SWIG version to 1.3.29. Roy _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users
I''m reluctant to check these in, as they have made things distinctly
worse for me. These are the first patches I have tried to apply tonight,
and they make almost anything in bigdemo crash immediately. Here''s the
stack trace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211263296 (LWP 27912)]
0xb7866816 in SWIG_Ruby_NewPointerObj (ptr=0xbfd556a0, type=0xb7c6d0a0,
flags=Variable "flags" is not available.
) at src/Button.cpp:1312
1312 if (strcmp(type->name, type_name) == 0) {
Current language: auto; currently c++
(gdb) bt
#0 0xb7866816 in SWIG_Ruby_NewPointerObj (ptr=0xbfd556a0,
type=0xb7c6d0a0, flags=Variable "flags" is not available.
) at src/Button.cpp:1312
#1 0xb786d740 in SwigDirector_wxButton::ProcessEvent (this=0x82d2520,
event=@0xbfd556a0) at src/Button.cpp:3236
#2 0xb73c4581 in wxAppBase::SendIdleEvents (this=0x8122a28,
win=0x82d2520, event=@0xbfd556a0) at ../src/common/appcmn.cpp:431
#3 0xb73c45e5 in wxAppBase::SendIdleEvents (this=0x8122a28,
win=0x8226400, event=@0xbfd556a0) at ../src/common/appcmn.cpp:440
#4 0xb73c4456 in wxAppBase::ProcessIdle (this=0x8122a28)
at ../src/common/appcmn.cpp:406
#5 0xb731072e in wxapp_idle_callback () at ../src/gtk/app.cpp:281
#6 0xb69b5750 in g_child_watch_add () from /usr/lib/libglib-2.0.so.0
#7 0xb69b34ee in g_main_context_dispatch ()
from /usr/lib/libglib-2.0.so.0
#8 0xb69b64f6 in g_main_context_check () from /usr/lib/libglib-2.0.so.0
#9 0xb69b67e3 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#10 0xb6d6ce65 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#11 0xb73311c0 in wxEventLoop::Run (this=0x82a0c88)
at ../src/gtk/evtloop.cpp:80
#12 0xb73c4123 in wxAppBase::MainLoop (this=0x8122a28)
at ../src/common/appcmn.cpp:272
#13 0xb73c42af in wxAppBase::OnRun (this=0x8122a28)
at ../src/common/appcmn.cpp:340
#14 0xb70c3441 in wxEntry (argc=@0xb7c6d3c8, argv=0xb7c6d3c0)
at ../src/common/init.cpp:439
#15 0xb784b558 in _wrap_App_main_loop (argc=0, argv=0x0,
self=3061730980) at src/App.cpp:1650
#16 0xb7e9264a in rb_iterator_p () from /usr/lib/libruby1.8.so.1.8
#17 0xb7e9d07c in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8
#18 0xb7e9db82 in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8
#19 0xb7e9a478 in rb_thread_trap_eval () from /usr/lib/libruby1.8.so.1.8
#20 0xb7ea7586 in rb_eval_string () from /usr/lib/libruby1.8.so.1.8
#21 0xb7ea75d6 in ruby_exec () from /usr/lib/libruby1.8.so.1.8
#22 0xb7ea9715 in ruby_run () from /usr/lib/libruby1.8.so.1.8
#23 0x080486ac in main ()
Any thoughts before I dive in and try to figure it out myself?
Kevin
On Sun, 2006-04-23 at 13:28 -0400, Roy Sutton wrote:> The following patches implement object tracking. Note nasty games I
> play to make the tracking global. SWIG 1.3.30 won''t need this. I
also
> updated the minimum required SWIG version to 1.3.29.
>
> Roy
Kevin Smith wrote:> I''m reluctant to check these in, as they have made things distinctly > worse for me. These are the first patches I have tried to apply tonight, > and they make almost anything in bigdemo crash immediately. Here''s the > stack trace:Wow. On Windows I couldn''t detect any differences between tracking and no tracking. I have set up an Ubuntu box with the idea of checking out wxRuby on it (and also doing some Rails stuff), maybe it''s time to try testing it there. The box is at the office, though, so I don''t get to work on it much. Some days working on this stuff is like carving something out of wood and discovering a big rotted area beneath what looks like good wood. I''m looking forward to the day when some change doesn''t uncover a ton of other problems! Roy
On Mon, 2006-04-24 at 21:10 -0400, Kevin Smith wrote:> I''m reluctant to check these in, as they have made things distinctly > worse for me. These are the first patches I have tried to apply tonight, > and they make almost anything in bigdemo crash immediately.I found the easiest way to duplicate the problem was to run the minimal.rb sample, do Help/About, and hit OK to close the box. Then I discovered that the SWIG code was dereferencing some internal value, and it was expecting a normal Ruby object, but the value actually contained Qnil. I don''t know why. I updated the SWIG post-processors to allow for this case, and now everything works quite smoothly. I was able to run several samples, performing several operations in each, with no crashes. I did get one segfault upon exiting bigdemo though, so it''s not perfect yet. So Roy''s patch, and my additional patch, are both checked in. At least theoretically, we have object tracking now. Kevin
Kevin, Glad you tracked that down. Actually, the minimal sample crashes for me on Windows (before applying your patch). I believe it''s because it explicitly does a GC.start in the help box. This has to do with object tracking, which is not fully implemented yet. I will try out your patches to see if they resolve any other problems I''ve seen. I''m spinning my wheels at the moment trying to decide what to tackle. I think the most important thing is the typemap problem with the externalLeading stuff. Alex''s patch didn''t make it work right for me (though I may have applied it wrong?). If we can''t track it down we''ll have to manually update that code. On an unrelated note, how strongly are you for/against mixing in SWIG directives into our .h files? I think it may be the only way to apply certain typemaps, since you can''t apply typemaps by function name, only argument. Roy Kevin Smith wrote:> On Mon, 2006-04-24 at 21:10 -0400, Kevin Smith wrote: > >> I''m reluctant to check these in, as they have made things distinctly >> worse for me. These are the first patches I have tried to apply tonight, >> and they make almost anything in bigdemo crash immediately. >> > > I found the easiest way to duplicate the problem was to run the > minimal.rb sample, do Help/About, and hit OK to close the box. > > Then I discovered that the SWIG code was dereferencing some internal > value, and it was expecting a normal Ruby object, but the value actually > contained Qnil. I don''t know why. > > I updated the SWIG post-processors to allow for this case, and now > everything works quite smoothly. I was able to run several samples, > performing several operations in each, with no crashes. I did get one > segfault upon exiting bigdemo though, so it''s not perfect yet. > > So Roy''s patch, and my additional patch, are both checked in. At least > theoretically, we have object tracking now. > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > >
On Sat, 2006-04-29 at 16:02 -0400, Roy Sutton wrote:> I''m spinning my wheels at the moment trying to decide what to tackle.One of my own pet peeves is all the compile warnings. Especially the new "dh is not used". If there''s a simple way to fix the code emission to avoid them, that would be great. I don''t want to tweak compiler command lines to simply hide the warnings, though. Of course, for me, bigdemo still has the splitter problem. I''ll take a look at that myself this afternoon. Beyond that, I''m afraid I really haven''t used wx enough recently to know what is most pressing.> On an unrelated note, how strongly are you for/against mixing in SWIG > directives into our .h files? I think it may be the only way to apply > certain typemaps, since you can''t apply typemaps by function name, only > argument.I guess I would have to see an example to know how I feel about it. Kevin
Kevin Smith wrote:> On Sat, 2006-04-29 at 16:02 -0400, Roy Sutton wrote: > >> I''m spinning my wheels at the moment trying to decide what to tackle. >> > > One of my own pet peeves is all the compile warnings. Especially the new > "dh is not used". If there''s a simple way to fix the code emission to > avoid them, that would be great. I don''t want to tweak compiler command > lines to simply hide the warnings, though. >I know exactly what you mean. I insist on a clean compile on everything else. I was just taking a look at the new, recurring SWIG warning (Warning(473): Returning a pointer...).>> On an unrelated note, how strongly are you for/against mixing in SWIG >> directives into our .h files? I think it may be the only way to apply >> certain typemaps, since you can''t apply typemaps by function name, only >> argument. >> > > I guess I would have to see an example to know how I feel about it.If I have to do it to wrap something I''ll send in an example. I haven''t had to do it yet. Roy
On Sat, 2006-04-29 at 16:15 -0400, Kevin Smith wrote:> Of course, for me, bigdemo still has the splitter problem. I''ll take a > look at that myself this afternoon.Fixed. Turns out the default splitter location was so high that it was underneath the notebook tabs. So I couldn''t grab it with the mouse to resize it. I changed the minimum split panel size from 20 to 100, and that fixed it. I can now really use the bigdemo! Woo-hoo! Kevin
Hi Kevin, Kevin Smith wrote:>On Sat, 2006-04-29 at 16:15 -0400, Kevin Smith wrote: > > > I can now really use the bigdemo! Woo-hoo! > >Cool! For spectators like me, who are eagerly waiting to dig their hands in writing GUI applications using wxruby2, how far are we from getting a preview release? Million Thanks for all the hard work you guys are putting in :-) -- Shashank
Kevin Smith wrote:> On Sat, 2006-04-29 at 16:15 -0400, Kevin Smith wrote: > >> Of course, for me, bigdemo still has the splitter problem. I''ll take a >> look at that myself this afternoon. >> > > Fixed. Turns out the default splitter location was so high that it was > underneath the notebook tabs. So I couldn''t grab it with the mouse to > resize it. I changed the minimum split panel size from 20 to 100, and > that fixed it. I can now really use the bigdemo! Woo-hoo!Great! This reminds me of another problem I see. On Windows, all the drop-downs (combo box, listbox) don''t drop down far enough to reveal their contents. It appears that the size of the control is set such that it specifies the max height for the control when it''s expanded. Is this a bug in wxWindows? Is this bug only visible on Windows or does it happen elsewhere, too? I saw a bug in the wxWindows bug tracker related to problems with putting combos on resizable items, perhaps it''s related. Roy
Kevin Smith
2006-Apr-29 21:36 UTC
[Wxruby-users] How close to preview release? (was: Patches for object tracking)
On Sat, 2006-04-29 at 15:50 -0500, Shashank Date wrote:> Cool! For spectators like me, who are eagerly waiting to dig their hands > in writing GUI applications using wxruby2, how far are we from getting a > preview release?It''s a bit hard to tell. We are still working through several odd problems that came up with the switch to SWIG 1.3.29 and wx 2.6.3. Things are definitely better than they were a few days ago, so with luck we might restabilize this weekend. If so, a preview release could happen as early as next weekend. On the other hand, with bad luck, we might be many weeks from something stable and usable.> Million Thanks for all the hard work you guys are putting in :-)Thanks for the encouragement. And I''ll second your thanks to Alex and (especially) Roy, since they are really doing most of the work these days. My role at the moment is mostly just applying patches, which is fantastic! Kevin
On Sat, 2006-04-29 at 16:51 -0400, Roy Sutton wrote:> On Windows, all the drop-downs (combo box, listbox) don''t drop down > far enough to reveal their contents. It appears that the size of the > control is set such that it specifies the max height for the control > when it''s expanded.ComboBoxes look perfect to me (on Linux), in both the controls.rb and bigdemo samples. Kevin