From noreply at rubyforge.org Fri Feb 1 09:07:20 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 1 Feb 2008 09:07:20 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-17697 ] "puts Frame.show" crashes application Message-ID: <20080201140720.A6B5518586F8@rubyforge.org> Bugs item #17697, was opened at 01-02-2008 09:07 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=17697&group_id=35 Category: Incorrect behavior Group: current Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: "puts Frame.show" crashes application Initial Comment: I know that nobody would use "puts SomeFrame.show". I'm just reporting this bug because it could cause another problem. if a run the program below the app crash with the message "This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information." My system: Windows XP SP 2 Ruby 1.8.6 gem 1.0.1 wxruby 1.9.4 Thanks very much. Wxruby rocks! The program: begin require 'wx' rescue LoadError => no_wx_err begin require 'rubygems' require 'wx' rescue LoadError raise no_wx_err end end include Wx class BugExample < Frame def initialize(*args) super panel = Panel.new(self) sizer = BoxSizer.new(Wx::VERTICAL) # comment the line below and the bug goes away sizer.add(StaticText.new(panel, -1, 'Hi, im a weird bug example'), 0, GROW|ALL, 4) panel.set_sizer(sizer) sizer.set_size_hints(panel) sizer.fit(self) end end App.run do f = BugExample.new(nil) puts f.show end ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=17697&group_id=35 From noreply at rubyforge.org Sat Feb 2 01:58:40 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 2 Feb 2008 01:58:40 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-17714 ] http://wxruby.rubyforge.org/doc/frame.html Display is too wide for even a wide lcd! Message-ID: <20080202065840.2591F18586D6@rubyforge.org> Bugs item #17714, was opened at 2008-02-02 06:58 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=17714&group_id=35 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Dale E. Edmons (linuxfan) Assigned to: Nobody (None) Summary: http://wxruby.rubyforge.org/doc/frame.html Display is too wide for even a wide lcd! Initial Comment: http://wxruby.rubyforge.org/doc/frame.html Display is too wide for even a wide lcd! I can almost display the functions, but it is much too wide unlike other pages. Thanks. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=17714&group_id=35 From noreply at rubyforge.org Sat Feb 2 23:04:40 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Sat, 2 Feb 2008 23:04:40 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-17742 ] aui/aui.rb example program exhibits a memory leak Message-ID: <20080203040440.AD46418586F5@rubyforge.org> Bugs item #17742, was opened at 2008-02-03 04:04 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=17742&group_id=35 Category: Incorrect behavior Group: current Status: Open Resolution: None Priority: 3 Submitted By: Dale E. Edmons (linuxfan) Assigned to: Nobody (None) Summary: aui/aui.rb example program exhibits a memory leak Initial Comment: aui/aui.rb example program exhibits a memory leak Any click or raise event on aui/aui.rb causes a small loss of memory as shown by free. Am currently trying to verify that it is unique to wxruby. distro: SourceMage GNU/Linux X11: xorg-modular xorg-xserver xorg-server 1.3.0.0 1.3.0.0 wxgtk:stable x11-toolkits wxgtk 2.8.7 2.8.7 ruby: stable devel ruby 1.8.6-p111 1.8.6-p111 swig: stable devel swig 1.3.33 1.3.31 gcc: stable gnu gcc 4.2.2 4.2.2 gtk+: stable x11-toolkits gtk+ 1.2.10 1.2.10 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=17742&group_id=35 From noreply at rubyforge.org Wed Feb 6 06:50:29 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 6 Feb 2008 06:50:29 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-17827 ] Crash when closing Dialog in bigdemo.rb Message-ID: <20080206115029.F110418585C7@rubyforge.org> Bugs item #17827, was opened at 2008-02-06 11:50 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=17827&group_id=35 Category: Incorrect behavior Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Fenton (brokentoy) Assigned to: Alex Fenton (brokentoy) Summary: Crash when closing Dialog in bigdemo.rb Initial Comment: Segfault in bigdemo.rb. To reproduce, start the sample, select the first item in the widget tree list ("wxDialog"). Then close the Dialog with either the OK or Cancel button. Backtrace is: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xb84352ec 0x00136e80 in st_lookup () (gdb) whe #0 0x00136e80 in st_lookup () #1 0x000cfe3c in rb_clear_cache_by_class () #2 0x000dac7d in rb_eval_string_wrap () #3 0x000d80da in rb_eval_string_wrap () #4 0x000d7c78 in rb_eval_string_wrap () #5 0x000d7c78 in rb_eval_string_wrap () #6 0x000d6a20 in rb_eval_string_wrap () #7 0x000d7541 in rb_eval_string_wrap () #8 0x000d6739 in rb_eval_string_wrap () #9 0x000da95f in rb_eval_string_wrap () #10 0x000dad6a in rb_eval_string_wrap () #11 0x000d80da in rb_eval_string_wrap () #12 0x000da95f in rb_eval_string_wrap () #13 0x000e439a in rb_apply () #14 0x000d1057 in rb_with_disable_interrupt () #15 0x000da18c in rb_eval_string_wrap () #16 0x000dad6a in rb_eval_string_wrap () #17 0x000d80da in rb_eval_string_wrap () #18 0x000de178 in rb_thread_trap_eval () #19 0x000de7e6 in rb_thread_trap_eval () #20 0x000da18c in rb_eval_string_wrap () #21 0x000dad6a in rb_eval_string_wrap () #22 0x000db7ed in rb_respond_to () #23 0x000db8d6 in rb_funcall () #24 0x010ab236 in wxRbCallback::EventThunker () at string.h:690 #25 0x0139fbc3 in wxAppConsole::HandleEvent (this=0x3ad2d0, handler=0x833200, func={__pfn = 0x10ab18c , __delta = 0}, event=@0xbfffdf24) at ../src/common/appbase.cpp:320 #26 0x0143ba6e in wxEvtHandler::ProcessEventIfMatches (entry=@0x1582a500, handler=0x833200, event=@0xbfffdf24) at ../src/common/event.cpp:1225 #27 0x0143cb82 in wxEvtHandler::SearchDynamicEventTable (this=0x833200, event=@0xbfffdf24) at ../src/common/event.cpp:1407 #28 0x0143cc8c in wxEvtHandler::ProcessEvent (this=0x833200, event=@0xbfffdf24) at ../src/common/event.cpp:1283 #29 0x010aa5c2 in _wrap_wxEvtHandler_ProcessEvent () at string.h:690 #30 0x000d1057 in rb_with_disable_interrupt () #31 0x000da18c in rb_eval_string_wrap () #32 0x000dad6a in rb_eval_string_wrap () #33 0x000db7ed in rb_respond_to () #34 0x000db8d6 in rb_funcall () #35 0x010c5b0d in SwigDirector_wxFrame::ProcessEvent () at string.h:690 #36 0x0156e892 in wxWindowBase::TryParent (this=0x84f000, event=@0xbfffdf24) at ../src/common/wincmn.cpp:2612 #37 0x0143cd42 in wxEvtHandler::ProcessEvent (this=0x84f000, event=@0xbfffdf24) at ../src/common/event.cpp:1300 #38 0x010aa5c2 in _wrap_wxEvtHandler_ProcessEvent () at string.h:690 #39 0x000d1057 in rb_with_disable_interrupt () #40 0x000da18c in rb_eval_string_wrap () #41 0x000dad6a in rb_eval_string_wrap () #42 0x000db7ed in rb_respond_to () #43 0x000db8d6 in rb_funcall () #44 0x0124b089 in SwigDirector_wxSplitterWindow::ProcessEvent () at string.h:690 #45 0x0156e892 in wxWindowBase::TryParent (this=0x871a00, event=@0xbfffdf24) at ../src/common/wincmn.cpp:2612 #46 0x0143cd42 in wxEvtHandler::ProcessEvent (this=0x871a00, event=@0xbfffdf24) at ../src/common/event.cpp:1300 #47 0x0143cd1c in wxEvtHandler::ProcessEvent (this=0x15824400, event=@0xbfffdf24) at ../src/common/event.cpp:1294 #48 0x01591388 in wxScrollHelperEvtHandler::ProcessEvent (this=0x15824400, event=@0xbfffdf24) at ../src/generic/scrlwing.cpp:211 #49 0x0159ced8 in wxGenericTreeCtrl::DoSelectItem (this=0x871a00, itemId=@0xbfffe1b8, unselect_others=true, extended_select=false) at ../src/generic/treectlg.cpp:1895 #50 0x015a1e87 in wxGenericTreeCtrl::OnMouse (this=0x871a00, event=@0xbfffe43c) at ../src/generic/treectlg.cpp:3351 #51 0x0139fbc3 in wxAppConsole::HandleEvent (this=0x3ad2d0, handler=0x871a00, func={__pfn = 0x15a0e2a , __delta = 0}, event=@0xbfffe43c) at ../src/common/appbase.cpp:320 #52 0x0143ba6e in wxEvtHandler::ProcessEventIfMatches (entry=@0x1b63270, handler=0x871a00, event=@0xbfffe43c) at ../src/common/event.cpp:1225 #53 0x0143be5a in wxEventHashTable::HandleEvent (this=0x1b63420, event=@0xbfffe43c, self=0x871a00) at ../src/common/event.cpp:898 #54 0x0143ccdb in wxEvtHandler::ProcessEvent (this=0x871a00, event=@0xbfffe43c) at ../src/common/event.cpp:1287 #55 0x0143cd1c in wxEvtHandler::ProcessEvent (this=0x15824400, event=@0xbfffe43c) at ../src/common/event.cpp:1294 #56 0x01591388 in wxScrollHelperEvtHandler::ProcessEvent (this=0x15824400, event=@0xbfffe43c) at ../src/generic/scrlwing.cpp:211 #57 0x014ba3ca in wxMacTopLevelMouseEventHandler (handler=0xbfffe880, event=0x1582b430, data=0x833200) at ../src/mac/carbon/toplevel.cpp:598 #58 0x014bb2fd in wxMacTopLevelEventHandler (handler=0xbfffe880, event=0x1582b430, data=0x833200) at ../src/mac/carbon/toplevel.cpp:843 #59 0x95b31863 in DispatchEventToHandlers () #60 0x95b30c9d in SendEventToEventTargetInternal () #61 0x95b4d08e in SendEventToEventTarget () #62 0x95b5fb73 in ToolboxEventDispatcherHandler () #63 0x95b31c1c in DispatchEventToHandlers () #64 0x95b30c9d in SendEventToEventTargetInternal () #65 0x95b4d08e in SendEventToEventTarget () #66 0x014512b1 in wxApp::MacHandleOneEvent (this=0x3ad2d0, evr=0x1582b430) at ../src/mac/carbon/app.cpp:1225 #67 0x01451381 in wxApp::MacDoOneEvent (this=0x3ad2d0) at ../src/mac/carbon/app.cpp:1194 #68 0x0146c1d2 in wxEventLoop::Dispatch (this=0x15869e80) at ../src/mac/carbon/evtloop.cpp:107 #69 0x015095af in wxEventLoopManual::Run (this=0x15869e80) at ../src/common/evtloopcmn.cpp:115 #70 0x014df853 in wxAppBase::MainLoop (this=0x3ad2d0) at ../src/common/appcmn.cpp:312 #71 0x014df9c1 in wxAppBase::OnRun (this=0x3ad2d0) at ../src/common/appcmn.cpp:367 #72 0x013db917 in wxEntry (argc=@0x1b74cb8, argv=0x3ad480) at ../src/common/init.cpp:456 #73 0x013db9d6 in wxEntry (argc=@0x1b58e1c, argv=0x1b58e14) at ../src/common/init.cpp:468 #74 0x01008760 in wxRubyApp::main_loop () at app.h:220 #75 0x01006e42 in _wrap_App_main_loop () at string.h:242 #76 0x000d1057 in rb_with_disable_interrupt () #77 0x000da18c in rb_eval_string_wrap () #78 0x000dad6a in rb_eval_string_wrap () #79 0x000d80da in rb_eval_string_wrap () #80 0x000e706e in rb_load_protect () #81 0x000e709f in ruby_exec () #82 0x000e70cb in ruby_run () #83 0x00001fff in main () (gdb) ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=17827&group_id=35 From noreply at rubyforge.org Wed Feb 6 11:22:59 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 6 Feb 2008 11:22:59 -0500 (EST) Subject: [wxruby-development] [ wxruby-Support Requests-17829 ] v1.94 new install error on running samples Message-ID: <20080206162259.D5D2018585E7@rubyforge.org> Support Requests item #17829, was opened at 2008-02-06 11:22 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=219&aid=17829&group_id=35 Category: None Group: None Status: Open Priority: 3 Submitted By: Matthew Simpson (mattstrat) Assigned to: Nobody (None) Summary: v1.94 new install error on running samples Initial Comment: --------------------------- ruby.exe - Unable To Locate Component --------------------------- This application has failed to start because MSVCP71.dll was not found. Re-installing the application may fix this problem. --------------------------- OK --------------------------- Hi there, I am a new user trying out ruby and wxRuby. I get the above error trying to start any of the wxRuby samples. Ruby itself seems to be installed fine running other non-wx samples OK. I don't have visual c++ installed at all on the test system either, is there some dependancy? TIA Matt ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=219&aid=17829&group_id=35 From alex at pressure.to Thu Feb 7 06:47:39 2008 From: alex at pressure.to (Alex Fenton) Date: Thu, 07 Feb 2008 11:47:39 +0000 Subject: [wxruby-development] Linux x86_64 gem Message-ID: <47AAEFDB.6000105@pressure.to> Hi I'd like to offer a Linux AMD-64 gem again for 1.9.4. Sean - I think you posted a way to do this using an emulator on OS X but I can't find your instructions. Perhaps you could point me in the right direction please? thanks alex From sean.m.long at gmail.com Thu Feb 7 12:46:10 2008 From: sean.m.long at gmail.com (Sean Long) Date: Thu, 7 Feb 2008 09:46:10 -0800 Subject: [wxruby-development] Linux x86_64 gem In-Reply-To: <47AAEFDB.6000105@pressure.to> References: <47AAEFDB.6000105@pressure.to> Message-ID: I found the old email, I wrote: > I am using VMware fusion on my MacBook Pro which has a Core 2 Duo. As > long as you have a Core 2 Duo or newer VMware fusion will allow you to > run 32 and 64 bit hosts. Previously I ran Parallels which was ok but > VMware is much more stable and I don't think Parallels can do both 32 > and 64 bit. I build wxWidgets according to the Linux instructions at: http://wxruby.rubyforge.org/wiki/wiki.pl?HowToBuildWxWidgets and added CFLAGS=-fPIC CXXFLAGS=-fPIC LDFLAGS=-fPIC And that was all I did Sean On Feb 7, 2008 3:47 AM, Alex Fenton wrote: > Hi > > I'd like to offer a Linux AMD-64 gem again for 1.9.4. Sean - I think you > posted a way to do this using an emulator on OS X but I can't find your > instructions. Perhaps you could point me in the right direction please? > > thanks > alex > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development > From alex at pressure.to Thu Feb 7 20:47:30 2008 From: alex at pressure.to (Alex Fenton) Date: Fri, 08 Feb 2008 01:47:30 +0000 Subject: [wxruby-development] Linux x86_64 gem In-Reply-To: References: <47AAEFDB.6000105@pressure.to> Message-ID: <47ABB4B2.9020806@pressure.to> Sean Long wrote: >> I am using VMware fusion on my MacBook Pro which has a Core 2 Duo. Thanks, that worked. Setting up all the packages is a bit of a grind, and I couldn't get it to recognise MediaCtrl, but apart from that flaw, we've got a AMD-64 gem. alex From mario at ruby-im.net Fri Feb 8 01:40:46 2008 From: mario at ruby-im.net (Mario Steele) Date: Fri, 8 Feb 2008 00:40:46 -0600 Subject: [wxruby-development] Linux x86_64 gem In-Reply-To: <47ABB4B2.9020806@pressure.to> References: <47AAEFDB.6000105@pressure.to> <47ABB4B2.9020806@pressure.to> Message-ID: Hey Alex, I'm working on a SourceMage setup with Dale, and for some reason I'm getting an Unresolved Symbol error comming from the wxruby2.so file, even though I have wxGTK compiled with the flags needed to initialize the WxMediaCtrl class within it. I have gstreamer0.10 installed, so it's not having a problem finding that. And as far as I can tell, wxGTK compiles just fine with MediaCtrl enabled. Don't know of the symbol yet, I'll have to find out when I get home tonight. And it does it no matter what, just from a simple ruby - rwxruby2.so, will cause the undefined symbol error to popup. I've been trying to re-compile wxGTK to recognize the MediaCtrl, as well as wxRuby, both 1.9.4, and SVN Head. Are you having the same problem on the AMD-64 Bit version of the gem? Also, you said a while back, that you was successfully able to split one control off, into it's own shared library, in which to use. Can you send me that, so I can study it, and see how we can progress it to include the various other classes in wxRuby? Might as well start somewhere, right? L8ers, On 2/7/08, Alex Fenton wrote: > > Sean Long wrote: > >> I am using VMware fusion on my MacBook Pro which has a Core 2 Duo. > > Thanks, that worked. Setting up all the packages is a bit of a grind, > and I couldn't get it to recognise MediaCtrl, but apart from that flaw, > we've got a AMD-64 gem. > > 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/20080208/be7aed24/attachment.html From alex at pressure.to Fri Feb 8 05:34:49 2008 From: alex at pressure.to (Alex Fenton) Date: Fri, 08 Feb 2008 10:34:49 +0000 Subject: [wxruby-development] Linux x86_64 gem In-Reply-To: References: <47AAEFDB.6000105@pressure.to> <47ABB4B2.9020806@pressure.to> Message-ID: <47AC3049.5070606@pressure.to> Mario Steele wrote: > I'm working on a SourceMage setup with Dale, and for some reason I'm > getting an Unresolved Symbol error comming from the wxruby2.so file, > even though I have wxGTK compiled with the flags needed to initialize > the WxMediaCtrl class within it. I have gstreamer0.10 installed, so > it's not having a problem finding that. And as far as I can tell, > wxGTK compiles just fine with MediaCtrl enabled. It may be worth double-checking config.log in your wxWidgets build directory to see that configure found all the elements it requires to compile wxMediaCtrl. Search for 'gst' in that file to find the checks it does, and any that fail. > Don't know of the symbol yet, I'll have to find out when I get home > tonight. And it does it no matter what, just from a simple ruby > -rwxruby2.so, will cause the undefined symbol error to popup. I've > been trying to re-compile wxGTK to recognize the MediaCtrl, as well as > wxRuby, both 1.9.4, and SVN Head. Are you having the same problem on > the AMD-64 Bit version of the gem? The problem I had was that configure said it couldn't find 'gstreamer-0.10-plugins-base', but I couldn't find a package in Ubuntu repository with exactly that name. Everything similar was installed, but it still didn't work. I'm thinking that if it is a painful dependency, we should consider shipping the default binary gem for Linux without MediaCtrl. The primary requirement for the binary gems is that they are easy to get started with. > Also, you said a while back, that you was successfully able to split > one control off, into it's own shared library, in which to use. Can > you send me that, so I can study it, and see how we can progress it to > include the various other classes in wxRuby? Might as well start > somewhere, right? I'll post this separately. cheers alex From alex at pressure.to Fri Feb 8 05:56:55 2008 From: alex at pressure.to (Alex Fenton) Date: Fri, 08 Feb 2008 10:56:55 +0000 Subject: [wxruby-development] modularising wxRuby Message-ID: <47AC3577.9050104@pressure.to> Here's some notes on grouping the compiled bits of the library into separate parts instead of a single wxruby2.so: Each class is loaded and defined in a single file. For class Foo, this will be obj/Foo.o. The function that initialises each file is called Init_wxFoo, generated by SWIG and near the bottom of the source. It will call its parent's initializer if needed. At the moment, every class is initialised at startup when the main initialisation function in wx.cpp is called, through a function called 'InitializeOtherModules'. The call to this function is defined in swig/wx.i using a SWIG %init block. The rake task 'src/wx.cpp' in rakewx.rb defines this InitializeOtherModules function and appends it to wx.cpp so that it calls every known class. So, to break a class into a separately loaded file, we have to: 1) Remove Init_wxFoo from the main InitializeOtherModules call in wx.cpp 2) Create a new container/loader file like wx.i which calls Init_wxFoo. Call it wx_foo.i 3) Remove obj/Foo.o from the main linker task 4) Create a new linker task which links obj/Foo.o into a .so file with obj/wx_foo.o 5) require 'wx_foo' A few further complexities: - Each linker task that creates a separate .so has to know which extra libraries to include - eg libwx_stc for StyledTextCtrl, 'gdiplus.dll' for GraphicsContext etc - Each separate module would have to have complementary ruby code that requires the relevant ruby files in lib/wx/classes to decorate and extend the compiled code with ruby. This includes, importantly, event handling - the event type definitions mapping event type integer codes to Ruby event classes. This is already done for some classes eg MediaCtrl and StyledTextCtrl. So I think this is all doable but would require a fairly substantial overhaul. I'd be interested to hear what people think about when we should do this in the roadmap. cheers alex From mario at ruby-im.net Sat Feb 9 08:31:47 2008 From: mario at ruby-im.net (Mario Steele) Date: Sat, 9 Feb 2008 07:31:47 -0600 Subject: [wxruby-development] modularising wxRuby In-Reply-To: <47AC3577.9050104@pressure.to> References: <47AC3577.9050104@pressure.to> Message-ID: This is very interesting information Alex..... Have you tested the library's actual hd size, to see if it does reduce in size as far as the separated class into it's own .so object? Does it have the same size as wxruby2.so, or is it considerably smaller? If it's considerably smaller then wxruby2.so, then this will be a very worth while setup. If it's the same size as wxruby2.so, then that'll break the camel's back right there, so to say. I say, if the size of the .so file is smaller, then I would say it would be worth while, to see about starting to separate the major classes, that have dependency requirements first. Such as wxMediaCtrl, wxOpenGL, wxStyledTextCtrl for our "Initial" testbed, around 1.9.6 or 1.9.7 versions if not sooner. This way, we can eliminate the need to create a "Minimal" version of wxRuby, and then a feature enriched version of wxRuby. Then we can concentrate, on creating a Single wxRuby distro, that has the basics, then add in the extra stuff, such as wxMediaCtrl, or wxOpenGL, and such, if the person wants to absolutely use it. I think it would be very viable, and worthwhile to pursue this avenue at this stage of development, before we hit 2.0.0 version. Of course, I'm open to hear other comments from others, developers or not. L8ers, On 2/8/08, Alex Fenton wrote: > > Here's some notes on grouping the compiled bits of the library into > separate parts instead of a single wxruby2.so: > > Each class is loaded and defined in a single file. For class Foo, this > will be obj/Foo.o. The function that initialises each file is called > Init_wxFoo, generated by SWIG and near the bottom of the source. It will > call its parent's initializer if needed. > > At the moment, every class is initialised at startup when the main > initialisation function in wx.cpp is called, through a function called > 'InitializeOtherModules'. The call to this function is defined in > swig/wx.i using a SWIG %init block. > > The rake task 'src/wx.cpp' in rakewx.rb defines this > InitializeOtherModules function and appends it to wx.cpp so that it > calls every known class. > > So, to break a class into a separately loaded file, we have to: > 1) Remove Init_wxFoo from the main InitializeOtherModules call in wx.cpp > 2) Create a new container/loader file like wx.i which calls Init_wxFoo. > Call it wx_foo.i > 3) Remove obj/Foo.o from the main linker task > 4) Create a new linker task which links obj/Foo.o into a .so file with > obj/wx_foo.o > 5) require 'wx_foo' > > A few further complexities: > - Each linker task that creates a separate .so has to know which extra > libraries to include - eg libwx_stc for StyledTextCtrl, 'gdiplus.dll' > for GraphicsContext etc > > - Each separate module would have to have complementary ruby code that > requires the relevant ruby files in lib/wx/classes to decorate and > extend the compiled code with ruby. This includes, importantly, event > handling - the event type definitions mapping event type integer codes > to Ruby event classes. This is already done for some classes eg > MediaCtrl and StyledTextCtrl. > > So I think this is all doable but would require a fairly substantial > overhaul. I'd be interested to hear what people think about when we > should do this in the roadmap. > > cheers > 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/20080209/9c0a2157/attachment-0001.html From alex at pressure.to Sat Feb 9 09:41:01 2008 From: alex at pressure.to (Alex Fenton) Date: Sat, 09 Feb 2008 14:41:01 +0000 Subject: [wxruby-development] modularising wxRuby In-Reply-To: References: <47AC3577.9050104@pressure.to> Message-ID: <47ADBB7D.4000003@pressure.to> Mario Steele wrote: > This is very interesting information Alex..... Have you tested the > library's actual hd size, to see if it does reduce in size as far as > the separated class into it's own .so object? Does it have the same > size as wxruby2.so, or is it considerably smaller? I I tried removing some big non-core classes like StyledTextCtrl, Grid, Graphics* and the size of the rump wxruby2.so was about 25% smaller. Real gains could be bigger though. > I say, if the size of the .so file is smaller, then I would say it > would be worth while, to see about starting to separate the major > classes, that have dependency requirements first. Agree that size is not the only possible advantage - it's also being able to include components like MediaCtrl on Linux that depend on third-party libraries without the whole wxruby becoming unusable without those. > I think it would be very viable, and worthwhile to pursue this avenue > at this stage of development, before we hit 2.0.0 version. Of course, > I'm open to hear other comments from others, developers or not. Don't underestimate how big a task it will likely be. It'll mean restructuring all the layers in the library from the swig files and the rake process through to the ruby library files. It'll need a lot of cross-platform test and build to get the .dll / -l arguments to the linker right for each compiled module. I would prefer to continue with only conservative bugfixes plus doc and sample work to the 1.9 series. I would consider adding the 'sizer' syntax sugar, and dropping MediaCtrl from the pre-comp Linux binary, plus minor missing classes, but other than that no significant changes. I'd hope to get to a stable 2.0 within one or two more releases. To be honest I don't currently have the time or motivation to start on another major overhaul. But I think this is definitely worth pursuing. If people wish to take it on earlier I'd be very happy to create a SVN branch with a view to a modular wxruby2.2 (or 3.0, if wxWidgets comes out and we move to it) alex From mario at ruby-im.net Sun Feb 10 05:34:09 2008 From: mario at ruby-im.net (Mario Steele) Date: Sun, 10 Feb 2008 04:34:09 -0600 Subject: [wxruby-development] Linux x86_64 gem In-Reply-To: <47AC3049.5070606@pressure.to> References: <47AAEFDB.6000105@pressure.to> <47ABB4B2.9020806@pressure.to> <47AC3049.5070606@pressure.to> Message-ID: On 2/8/08, Alex Fenton wrote: > > Mario Steele wrote: > > I'm working on a SourceMage setup with Dale, and for some reason I'm > > getting an Unresolved Symbol error comming from the wxruby2.so file, > > even though I have wxGTK compiled with the flags needed to initialize > > the WxMediaCtrl class within it. I have gstreamer0.10 installed, so > > it's not having a problem finding that. And as far as I can tell, > > wxGTK compiles just fine with MediaCtrl enabled. > It may be worth double-checking config.log in your wxWidgets build > directory to see that configure found all the elements it requires to > compile wxMediaCtrl. Search for 'gst' in that file to find the checks it > does, and any that fail. Checked wxGTK compile log, and it shows that it found GStreamer, and enabled wxMediaCtrl, here's the relevant parts of the configure log that pertain to wxMediaCtrl: checking for --enable-sound... yes checking for --enable-mediactrl... yes checking for --enable-gstreamer8... no checking for --enable-printfposparam... yes checking for linux/joystick.h... yes configure: WARNING: wxMetafile is not available on this system... disabled checking for CAIRO... yes checking for GST... yes checking for gcc precompiled header bug... no As you can see, it is detecting gstreamer just fine. > Don't know of the symbol yet, I'll have to find out when I get home > > tonight. And it does it no matter what, just from a simple ruby > > -rwxruby2.so, will cause the undefined symbol error to popup. I've > > been trying to re-compile wxGTK to recognize the MediaCtrl, as well as > > wxRuby, both 1.9.4, and SVN Head. Are you having the same problem on > > the AMD-64 Bit version of the gem? > The problem I had was that configure said it couldn't find > 'gstreamer-0.10-plugins-base', but I couldn't find a package in Ubuntu > repository with exactly that name. Everything similar was installed, but > it still didn't work. The unresolved symbol, which is a weird one, is _ZNK11wxMediaCtrl12GetClassInfoEv, I've never seen that one before, and I know wxGTK is compiled properly. I am going to test and see if the wxGTK Sample for media ctrl compiles just fine or what happens. I'm thinking that if it is a painful dependency, we should consider > shipping the default binary gem for Linux without MediaCtrl. The primary > requirement for the binary gems is that they are easy to get started with. As I have said, in the other thread, I am in agreement with you about this. But due to the fact of till we get a stable modularization setup for it, we'll have to persue a setup of two binary gems, one with out the extra stuff such as GraphicsContext, MediaCtrl, OpenGL, etc, etc, till we get modularization working properly, in which we can separate these dependency required parts of wxGTK. 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/20080210/1eee5707/attachment.html From mario at ruby-im.net Sun Feb 10 07:39:42 2008 From: mario at ruby-im.net (Mario Steele) Date: Sun, 10 Feb 2008 06:39:42 -0600 Subject: [wxruby-development] SVN Commit 1555 Message-ID: Hello All, I just committed to SVN couple of changes. One is a "temporary" fix with the textile documentation for gridcellchoiceeditor, gridcellfloatrenderer, lognull and logpassthrough classes, which contained no Header for the class. Simply a cosmetic change. The major change, is the addition of WXRUBY_EXCLUDED environment variable, which directly modifies what classes are excluded from compiling, even if the features are available in the build of wxWidgets. Rake will still run through, and do it's normal checks of wxWidgets features, and still disable the features that are not available. This is only useful for such features as StyledTextCtrl, MediaCtrl, OpenGL, stuff that we had to detect if the feature is available or not. Enjoy, -- 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/20080210/70bae4a8/attachment.html From alex at pressure.to Mon Feb 11 05:05:23 2008 From: alex at pressure.to (Alex Fenton) Date: Mon, 11 Feb 2008 10:05:23 +0000 Subject: [wxruby-development] Linux x86_64 gem In-Reply-To: References: <47AAEFDB.6000105@pressure.to> <47ABB4B2.9020806@pressure.to> <47AC3049.5070606@pressure.to> Message-ID: <47B01DE3.3090700@pressure.to> Mario Steele wrote: > The unresolved symbol, which is a weird one, is > _ZNK11wxMediaCtrl12GetClassInfoEv, I've never seen that one before, > and I know wxGTK is compiled properly. I am going to test and see if > the wxGTK Sample for media ctrl compiles just fine or what happens. That error is strange. Let us know how you get on. > > I'm thinking that if it is a painful dependency, we should consider > shipping the default binary gem for Linux without MediaCtrl. The > primary > requirement for the binary gems is that they are easy to get > started with. > > > > As I have said, in the other thread, I am in agreement with you about > this. But due to the fact of till we get a stable modularization > setup for it, we'll have to persue a setup of two binary gems, one > with out the extra stuff such as GraphicsContext, MediaCtrl, OpenGL, > etc, etc, I was meaning a cruder solution - we still have a single set of binary gems, but the Linux one just doesn't come with Wx::MediaCtrl. If people on Linux want to use that class, they have to build their own wxRuby. We should be able to use your recent patch to do that. Not ideal, but the set of people that are both on Linux and have to use this pretty specialist class should be quite small, and able to deal with it if it's documented clearly. alex From mario at ruby-im.net Sat Feb 16 19:40:22 2008 From: mario at ruby-im.net (Mario Steele) Date: Sat, 16 Feb 2008 18:40:22 -0600 Subject: [wxruby-development] Idea for wxRuby Message-ID: Hello guys, I've actually been looking over a few things, and think there's a package we can add to wxRuby, utilising Ruby code, and 1 additional extension. I think it would proabbly be best to add this package to wx_sugar for now, but the idea, is incorperating SDL into wxRuby through, what I like to call, wxSDL. I've seen a few posts on here from people who want to do Graphics Drawing for Games, and such. And with some review of previous efforts to incorperate SDL into wxWidgets through C++, I think this would be an excellent Idea in which to incorperate into our stuff. The basic idea behind it, is to utilize SDL for all the drawing functions, mainly geared towards drawing on a SDL Surface, then retriving the data from the SDL Surface (SDL_pixels, or utilizing Ruby/SDL SDLSurface#pixels), then creating an Wx::Image from that, then utitlizing Wx::Bitmap or even draw_image() to draw the Bitmap to the screen in the final displaying of the image data. I think this would be a great way to enhance wxRuby, and also show of ways in which to incorperate outside libraries into wxRuby, without having to nesscarly write an extension in which to do it. What do you guys think? Add as a library into wx_sugar, or create a Ruby Tutorial? 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/20080216/421a2aab/attachment.html From alex at pressure.to Mon Feb 18 12:30:38 2008 From: alex at pressure.to (Alex Fenton) Date: Mon, 18 Feb 2008 17:30:38 +0000 Subject: [wxruby-development] Idea for wxRuby In-Reply-To: References: Message-ID: <47B9C0BE.9060302@pressure.to> Hi Mario Mario Steele wrote: > The basic idea behind it, is to utilize SDL for all the drawing > functions, mainly geared towards drawing on a SDL Surface, then > retriving the data from the SDL Surface (SDL_pixels, or utilizing > Ruby/SDL SDLSurface#pixels), then creating an Wx::Image from that, > then utitlizing Wx::Bitmap or even draw_image() to draw the Bitmap to > the screen in the final displaying of the image data. Sounds interesting. I don't know much about SDL - sounds like it overlaps with wxRuby quite a bit. Does it have much better/faster drawing routines? I guess the first step would be to write it up as a tutorial and then if there's useful generic glue code to add, we could easily add it to wxSugar. cheers alex From mario at ruby-im.net Tue Feb 19 05:05:46 2008 From: mario at ruby-im.net (Mario Steele) Date: Tue, 19 Feb 2008 04:05:46 -0600 Subject: [wxruby-development] Idea for wxRuby In-Reply-To: <47B9C0BE.9060302@pressure.to> References: <47B9C0BE.9060302@pressure.to> Message-ID: Hey Alex, That's actually what I'm working on right now, is to create a sample first, to prove the ideas behind it, utilizing Ruby/SDL, and wxRuby, to ensure that everything works. So far, I'm not quite there yet. But I will be working on it some more today to see if I can get it to work. L8ers, On 2/18/08, Alex Fenton wrote: > > Hi Mario > > Mario Steele wrote: > > The basic idea behind it, is to utilize SDL for all the drawing > > functions, mainly geared towards drawing on a SDL Surface, then > > retriving the data from the SDL Surface (SDL_pixels, or utilizing > > Ruby/SDL SDLSurface#pixels), then creating an Wx::Image from that, > > then utitlizing Wx::Bitmap or even draw_image() to draw the Bitmap to > > the screen in the final displaying of the image data. > Sounds interesting. I don't know much about SDL - sounds like it > overlaps with wxRuby quite a bit. Does it have much better/faster > drawing routines? > > I guess the first step would be to write it up as a tutorial and then if > there's useful generic glue code to add, we could easily add it to > wxSugar. > > cheers > 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/20080219/f1a49297/attachment-0001.html From noreply at rubyforge.org Tue Feb 19 07:34:24 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Tue, 19 Feb 2008 07:34:24 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-18201 ] Can't load Gauge from XRC on MSW Message-ID: <20080219123424.5743B1858690@rubyforge.org> Bugs item #18201, was opened at 2008-02-19 12:34 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=18201&group_id=35 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Fenton (brokentoy) Assigned to: Nobody (None) Summary: Can't load Gauge from XRC on MSW Initial Comment: Error message is: gauge_xrc.rb:26:in `find_window_by_id': Error wrapping object; class `wxGauge95' is not supported in wxRuby (NotImplementedError) In wxWidgets, wxGauge on MSW is an alias for wxGauge95. The underlying object reports its class as a wxGauge95 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=18201&group_id=35 From mario at ruby-im.net Tue Feb 19 22:08:28 2008 From: mario at ruby-im.net (Mario Steele) Date: Tue, 19 Feb 2008 21:08:28 -0600 Subject: [wxruby-development] Idea for wxRuby In-Reply-To: References: <47B9C0BE.9060302@pressure.to> Message-ID: Hey Again. Alright, I've finally implemented a Demo of what I was looking at. And my god, does it make a difference. The sample that I created, basically is meant to be a per pixel drawing setup. I've worked it over, looking at a few things, and tested it against the original C++ Demo, that someone created for a way to implement SDL with wxWidgets. Now, the C++ Program has definate speed enhancements, and runs quite a bit faster, however, comparing my implementation of wxSDL that I created, compared to using a native wxBitmap setup, shows drastic changes. wxBitmap utilizing DC Drawing, is 100 times slower. The time it takes for wxBitmap to draw 1 frame, wxSDL has drawn atleast 15 to 30 frames. But compare that to the C++ Example, it's proabbly running 50 or 60 FPS. So I can definatly see some advantages to creating a wxSDL library. I'm going to include the two samples for those who want to look at it. But I will also be posting them on the Wiki, with a full break down of the code, following much the same way as the original Example Tutorial followed. You can find the download of the C++ here: http://code.technoplaza.net/wx-sdl/part1/wx-sdl.zip There's other advantages, as we can use SDL for playing Music and Videos as well. Might be a great replacement for MediaCtrl all together. Enjoy, and tell me what you guys think. L8ers, PS: wx-sdl requires Ruby/SDL in order to work. On 2/19/08, Mario Steele wrote: > > Hey Alex, > > That's actually what I'm working on right now, is to create a sample > first, to prove the ideas behind it, utilizing Ruby/SDL, and wxRuby, to > ensure that everything works. So far, I'm not quite there yet. But I will > be working on it some more today to see if I can get it to work. > > L8ers, > > On 2/18/08, Alex Fenton wrote: > > > > Hi Mario > > > > Mario Steele wrote: > > > The basic idea behind it, is to utilize SDL for all the drawing > > > functions, mainly geared towards drawing on a SDL Surface, then > > > retriving the data from the SDL Surface (SDL_pixels, or utilizing > > > Ruby/SDL SDLSurface#pixels), then creating an Wx::Image from that, > > > then utitlizing Wx::Bitmap or even draw_image() to draw the Bitmap to > > > the screen in the final displaying of the image data. > > Sounds interesting. I don't know much about SDL - sounds like it > > overlaps with wxRuby quite a bit. Does it have much better/faster > > drawing routines? > > > > I guess the first step would be to write it up as a tutorial and then if > > there's useful generic glue code to add, we could easily add it to > > wxSugar. > > > > cheers > > 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/20080219/79e54fc5/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: wx-sdl.rb Type: application/octet-stream Size: 2820 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-development/attachments/20080219/79e54fc5/attachment.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: wx-plain.rb Type: application/octet-stream Size: 2735 bytes Desc: not available Url : http://rubyforge.org/pipermail/wxruby-development/attachments/20080219/79e54fc5/attachment-0001.obj From teki321 at gmail.com Tue Feb 19 22:55:37 2008 From: teki321 at gmail.com (Bela Babik) Date: Wed, 20 Feb 2008 14:55:37 +1100 Subject: [wxruby-development] Idea for wxRuby In-Reply-To: References: <47B9C0BE.9060302@pressure.to> Message-ID: > wxBitmap utilizing DC Drawing, is 100 times slower. The time it takes for wxBitmap to draw 1 frame, wxSDL I am getting 9-10 fps without any drawing. Have you tried opengl? teki From mario at ruby-im.net Tue Feb 19 23:06:53 2008 From: mario at ruby-im.net (Mario Steele) Date: Tue, 19 Feb 2008 22:06:53 -0600 Subject: [wxruby-development] Idea for wxRuby In-Reply-To: References: <47B9C0BE.9060302@pressure.to> Message-ID: 9-10 fps without any drawing? On 2/19/08, Bela Babik wrote: > > > wxBitmap utilizing DC Drawing, is 100 times slower. The time it takes > for wxBitmap to draw 1 frame, wxSDL > > I am getting 9-10 fps without any drawing. Have you tried opengl? > > teki > _______________________________________________ > 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/20080219/dcc60a4a/attachment.html From teki321 at gmail.com Wed Feb 20 00:29:56 2008 From: teki321 at gmail.com (Bela Babik) Date: Wed, 20 Feb 2008 16:29:56 +1100 Subject: [wxruby-development] Idea for wxRuby In-Reply-To: References: <47B9C0BE.9060302@pressure.to> Message-ID: This is the slow part: for y in 0.. at screen.h do for x in 0.. at screen.w do color = (y * y) + (x * x) + ticks @screen.putPixel(x,y,color) end end Check this: http://pastie.caboo.se/154642 On Feb 20, 2008 3:06 PM, Mario Steele wrote: > 9-10 fps without any drawing? > > > > On 2/19/08, Bela Babik wrote: > > > > > > > > > wxBitmap utilizing DC Drawing, is 100 times slower. The time it takes > for wxBitmap to draw 1 frame, wxSDL > > > > I am getting 9-10 fps without any drawing. Have you tried opengl? > > > > teki > > > > _______________________________________________ > > 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/ > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development > > From alex at pressure.to Wed Feb 20 06:57:05 2008 From: alex at pressure.to (Alex Fenton) Date: Wed, 20 Feb 2008 11:57:05 +0000 Subject: [wxruby-development] Idea for wxRuby In-Reply-To: References: <47B9C0BE.9060302@pressure.to> Message-ID: <47BC1591.6030103@pressure.to> Hi Mario Mario Steele wrote: > Alright, I've finally implemented a Demo of what I was looking at. > And my god, does it make a difference. The sample that I created, > basically is meant to be a per pixel drawing setup. Thanks for investigating this. I tried it and the speed-up is very impressive. I guess this is partly down to SDL being more efficient internally, and partly down to ruby/SDL being a thinner wrapper than that generated by SWIG for DC. I can see that SDL would make a good partner for certain applications - the event handling and controls on the Wx side, with SDL as a specialised drawing & collision canvas. I think this would be a worthy addition to the samples. I wonder whether we could create a dir in the main distro for samples which demonstrate using wxRuby with other libraries. Using Grid or a virtual ListCtrl with sqlite might be another. cheers alex From mario at ruby-im.net Wed Feb 20 15:53:49 2008 From: mario at ruby-im.net (Mario Steele) Date: Wed, 20 Feb 2008 14:53:49 -0600 Subject: [wxruby-development] Idea for wxRuby In-Reply-To: References: <47B9C0BE.9060302@pressure.to> Message-ID: Hello Bela, Yes, I know this part is the slow part. I mentioned this when I stated that there is a slow down compared to the C++ Version of the code. Your basically assigning a Mathematical Value, that first needs to be evaluated, before the value is assign, then your doing this 320 by 200 times, which means that the mathematical expression (y*y) + (x*x) + ticks is being evaluated 64000 times, as well as the @screen.putPixel() method call. So in an interpreted realm, this is not the most co-efficient way in which to do these calculations. Still, utilizing SDL is still faster, then even Wx::MemoryDC. It would even be faster, if your mainly dealing with drawing shapes, and images onto the SDL Surface, compared to utilizing DC itself alone to write it. As Alex has said, SDL is a lite wrapper, compared with wxRuby which is heavily bogged down by SWIG Conversion stuff to convert Ruby objects into C++ Stuff. On 2/19/08, Bela Babik wrote: > > This is the slow part: > > for y in 0.. at screen.h do > for x in 0.. at screen.w do > color = (y * y) + (x * x) + ticks > @screen.putPixel(x,y,color) > end > end > > Check this: http://pastie.caboo.se/154642 > > > On Feb 20, 2008 3:06 PM, Mario Steele wrote: > > 9-10 fps without any drawing? > > > > > > > > On 2/19/08, Bela Babik wrote: > > > > > > > > > > > > > wxBitmap utilizing DC Drawing, is 100 times slower. The time it > takes > > for wxBitmap to draw 1 frame, wxSDL > > > > > > I am getting 9-10 fps without any drawing. Have you tried opengl? > > > > > > teki > > > > > > _______________________________________________ > > > 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/ > > _______________________________________________ > > wxruby-development mailing list > > wxruby-development at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-development > > > > > _______________________________________________ > 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/20080220/5827cf32/attachment.html From alex at pressure.to Wed Feb 20 16:00:49 2008 From: alex at pressure.to (Alex Fenton) Date: Wed, 20 Feb 2008 21:00:49 +0000 Subject: [wxruby-development] Idea for wxRuby In-Reply-To: References: <47B9C0BE.9060302@pressure.to> Message-ID: <47BC9501.9070402@pressure.to> Mario Steele wrote: > Hello Bela, > > Yes, I know this part is the slow part. I mentioned this when I > stated that there is a slow down compared to the C++ Version of the > code. Your basically assigning a Mathematical Value, that first needs > to be evaluated, before the value is assign, then your doing this 320 > by 200 times, which means that the mathematical expression (y*y) + > (x*x) + ticks is being evaluated 64000 times, as well as the > @screen.putPixel() method call. So in an interpreted realm, this is > not the most co-efficient way in which to do these calculations. Well, also you have set_pen, Pen.new, Colour.new etc within a tight loop. Pen.new in particular is an expensive operation and caching pens in this sort of scenario (as Jay McGavren found with Zyps) can really speed things up. It's on the Feature Request list that this be done automatically. But all that aside, I think it is definitely also down to the greater speed of SDL vs wxWidgets, and the thinness of the wrapper, so worth pursuing and including alex From noreply at rubyforge.org Thu Feb 21 09:57:59 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 21 Feb 2008 09:57:59 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-18275 ] Wx::Pen and Wx::PenList Message-ID: <20080221145759.685221858675@rubyforge.org> Bugs item #18275, was opened at 2008-02-21 08:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=18275&group_id=35 Category: Incorrect or missing docs Group: current Status: Open Resolution: None Priority: 3 Submitted By: Mario Steele (eumario) Assigned to: Alex Fenton (brokentoy) Summary: Wx::Pen and Wx::PenList Initial Comment: The documents for these two classes are missing information. Wx::Pen stops at Pen#get_cap(), and doesn't list any other methods, Wx::PenList is completely blank, no documentation at all. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=18275&group_id=35 From noreply at rubyforge.org Wed Feb 27 06:10:19 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Wed, 27 Feb 2008 06:10:19 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-18420 ] DC#draw_poly_polygon arguments not mapped correctly Message-ID: <20080227111019.DA45218585FC@rubyforge.org> Bugs item #18420, was opened at 2008-02-27 11:10 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=18420&group_id=35 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Fenton (brokentoy) Assigned to: Nobody (None) Summary: DC#draw_poly_polygon arguments not mapped correctly Initial Comment: This DC method's arguments aren't mapped correctly in ruby, giving the error: in `draw_poly_polygon': in method 'DrawPolyPolygon', argument 3 of type 'int []' (TypeError) The right method signature would probably be: ( [ [ Polygon1 ], [ Polygon2 ], [ Polygon3 ] ], offset_x, offset_y, rule ) i.e first argument is an array of arrays of points ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=18420&group_id=35 From chauk.mean at gmail.com Wed Feb 27 11:47:59 2008 From: chauk.mean at gmail.com (Chauk-Mean P) Date: Wed, 27 Feb 2008 17:47:59 +0100 Subject: [wxruby-development] Better API for ToolBar Message-ID: Hi, Most wxRuby classes do not require an explicit ID : - Window and its subclasses do not require an explicit ID during their creation - Menu do not require an explicit ID during the addition of a menu item Toolbar does not follow this rule. Indeed, you have to explicitly define an ID to add a tool within a toolbar. 1/ It would be great if ToolBar#add_tool : - takes only optionnally an ID - if the ID is specified, the method returns the tool position as usual - if the ID is not specified, the method returns both the "generated ID" and the tool position (as Ruby can return more than one value). 2/ It would be even more great if ToolBar#add_tool supports "hash style" named arguments. Then we could merge add_tool and insert_tool as following : # add my_toolbar.add_tool("Text", my_bitmap) # insert my_toolbar.add_tool("Text", my_bitmap, :position => 3) Cheers. Chauk-Mean. From noreply at rubyforge.org Thu Feb 28 06:18:36 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Thu, 28 Feb 2008 06:18:36 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-18441 ] /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27: [BUG] Segmentation fault Message-ID: <20080228111837.037891858606@rubyforge.org> Bugs item #18441, was opened at 28/02/2008 06:18 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=18441&group_id=35 Category: None Group: current Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27: [BUG] Segmentation fault Initial Comment: Hi! I have this "bug"? in my application. This error occurs randomly after events executions. For example if I choose "Project->Import" from main menu, a Wizard opens. Normal situation. So, I finish or cancel Wizard and 1-2s after, I have this error (see below). When I remove all events, my application don't crash. See an example of event calling : evt_menu(importRecMenuItem.get_id) { |e| on_import_receivers(e) } [...] def on_import_receivers(event) mywizard = Components::WizardImportReceivers.new(self) mywizard.destroy end [...] In an other file class WizardImportReceivers < Wx::Wizard def initialize(parent) super(parent, Wx::ID_ANY, translate("Import"), Wx::Bitmap.new("./resources/welcome.png", Wx::BITMAP_TYPE_PNG)) step_one = Wx::WizardPageSimple.new(self, nil, nil) self.setup_page_welcome_one(step_one) step_two = Wx::WizardPageSimple.new(self, step_one) step_one.set_next(step_two) self.setup_page_selectfile_two(step_two) step_three = Wx::WizardPageSimple.new(self, step_two) step_two.set_next(step_three) self.setup_page_format_two(step_three) @actual_page_num = 0 @filename = "" evt_wizard_page_changing(self.get_id) { | event | on_wizard_page_changing(event) } run_wizard(step_one) end This problem occurs too on an tree_sel_changed. Thanks for your help. ===== ERROR ===== /Library/Ruby/Site/1.8/rubygems/custom_require.rb:27: [BUG] Segmentation fault ==================== ERROR DETAILS ON GDB ==================== Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x00000000 0x001499cc in ruby_digitmap () ========= BACKTRACE ========= #0 0x001499cc in ruby_digitmap () #1 0x82000000 in ?? () #2 0x000ed23d in rb_mark_hash () #3 0x01007cc2 in wxRubyApp::mark_iterate () #4 0x000de162 in rb_thread_trap_eval () #5 0x000df026 in rb_yield () #6 0x000ef217 in rb_hash_values_at () #7 0x000ee9e1 in st_foreach_safe () #8 0x00137421 in st_foreach () #9 0x000eeacc in st_foreach_safe () #10 0x000d51fa in rb_ensure () #11 0x000f1c0c in rb_hash_select () #12 0x000da18c in rb_eval_string_wrap () #13 0x000dad6a in rb_eval_string_wrap () #14 0x000db7ed in rb_respond_to () #15 0x000db8d6 in rb_funcall () #16 0x000cc844 in rb_each () #17 0x000d0c43 in rb_iterate () #18 0x01007610 in wxRubyApp::mark_wxRubyApp () #19 0x000ed23d in rb_mark_hash () #20 0x000ed47d in rb_mark_hash () #21 0x00137421 in st_foreach () #22 0x000ed20a in rb_mark_hash () #23 0x000ed286 in rb_mark_hash () #24 0x000ed47d in rb_mark_hash () #25 0x00137421 in st_foreach () #26 0x000ed194 in rb_mark_hash () #27 0x000ed057 in rb_mark_hash () #28 0x000ed47d in rb_mark_hash () #29 0x00137421 in st_foreach () #30 0x000ed20a in rb_mark_hash () #31 0x000ed47d in rb_mark_hash () #32 0x00137421 in st_foreach () #33 0x000ed20a in rb_mark_hash () #34 0x000ed057 in rb_mark_hash () #35 0x000ed47d in rb_mark_hash () #36 0x00137421 in st_foreach () #37 0x000ed20a in rb_mark_hash () #38 0x000ed057 in rb_mark_hash () #39 0x000ed057 in rb_mark_hash () #40 0x000ed057 in rb_mark_hash () #41 0x000ed2bf in rb_mark_hash () #42 0x000ed6c6 in rb_gc_mark_maybe () #43 0x000ee2bb in ruby_xmalloc () #44 0x00137111 in st_add_direct () #45 0x00144fe5 in rb_ivar_set () #46 0x0123fdaf in SwigDirector_wxSplitterWindow::SetName () #47 0x01244330 in SwigDirector_wxSplitterWindow::ProcessEvent () #48 0x01570cb2 in wxWindowBase::TryParent () #49 0x01456ebc in wxEvtHandler::ProcessEvent () #50 0x010a76f6 in Init_wxEvtHandler () #51 0x000d1057 in rb_with_disable_interrupt () #52 0x000da18c in rb_eval_string_wrap () #53 0x000dad6a in rb_eval_string_wrap () #54 0x000db7ed in rb_respond_to () #55 0x000db8d6 in rb_funcall () #56 0x011c6887 in SwigDirector_wxPanel::ProcessEvent () #57 0x01570cb2 in wxWindowBase::TryParent () #58 0x01456ebc in wxEvtHandler::ProcessEvent () #59 0x010a76f6 in Init_wxEvtHandler () #60 0x000d1057 in rb_with_disable_interrupt () #61 0x000da18c in rb_eval_string_wrap () #62 0x000dad6a in rb_eval_string_wrap () #63 0x000db7ed in rb_respond_to () #64 0x000db8d6 in rb_funcall () #65 0x011b5bb9 in SwigDirector_wxNotebook::ProcessEvent () #66 0x01570cb2 in wxWindowBase::TryParent () #67 0x01456ebc in wxEvtHandler::ProcessEvent () #68 0x010a76f6 in Init_wxEvtHandler () #69 0x000d1057 in rb_with_disable_interrupt () #70 0x000da18c in rb_eval_string_wrap () #71 0x000dad6a in rb_eval_string_wrap () #72 0x000db7ed in rb_respond_to () #73 0x000db8d6 in rb_funcall () #74 0x011c6887 in SwigDirector_wxPanel::ProcessEvent () #75 0x01570cb2 in wxWindowBase::TryParent () #76 0x01456ebc in wxEvtHandler::ProcessEvent () #77 0x01575355 in wxWindowBase::UpdateWindowUI () #78 0x014d3112 in wxWindow::OnInternalIdle () #79 0x014f48d6 in wxAppBase::SendIdleEvents () #80 0x014f4911 in wxAppBase::SendIdleEvents () #81 0x014f4911 in wxAppBase::SendIdleEvents () #82 0x014f4911 in wxAppBase::SendIdleEvents () #83 0x014f4911 in wxAppBase::SendIdleEvents () #84 0x014f4911 in wxAppBase::SendIdleEvents () #85 0x014f4c1b in wxAppBase::ProcessIdle () #86 0x0151b76d in wxEventLoopManual::Run () #87 0x014f4483 in wxAppBase::MainLoop () #88 0x01402e2a in wxEntry () #89 0x010076b6 in wxRubyApp::main_loop () #90 0x01005efe in Init_wxApp () #91 0x000d1057 in rb_with_disable_interrupt () #92 0x000da18c in rb_eval_string_wrap () #93 0x000dad6a in rb_eval_string_wrap () #94 0x000d80da in rb_eval_string_wrap () #95 0x000e706e in rb_load_protect () #96 0x000e709f in ruby_exec () #97 0x000e70cb in ruby_run () #98 0x00001fff in main () ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=18441&group_id=35 From alex at pressure.to Fri Feb 29 16:54:02 2008 From: alex at pressure.to (Alex Fenton) Date: Fri, 29 Feb 2008 21:54:02 +0000 Subject: [wxruby-development] Better API for ToolBar In-Reply-To: References: Message-ID: <47C87EFA.7030001@pressure.to> Chauk-Mean P wrote: > Hi, > > Most wxRuby classes do not require an explicit ID : > > .... > Toolbar does not follow this rule. Indeed, you have to explicitly > define an ID to add a tool within a toolbar. > I agree this is a bit of wart. I've been using that class a bit recently and the API still feels a bit clumsy, though better than it was. > 1/ > It would be great if ToolBar#add_tool : > - takes only optionnally an ID > - if the ID is specified, the method returns the tool position as usual > - if the ID is not specified, the method returns both the "generated > ID" and the tool position (as Ruby can return more than one value). > It feels a bit weird to have different return values depending on the arguments. I think at least it should always return two values if that's needed. But then multi-return values are irritating to deal with when you're only interested in one of them. I guess my ideal API would return an instance of Wx::ToolBar::Tool, a pure ruby struct class encapsulating those, and upon which you could call toggle(), delete() etc. The same goes for Wx::Grid, where I'd like a Wx::Grid::Cell. This feels more OO-ish - but is not the way the wxWidgets API is designed - one of the reason some people don't like it. But I'm not sure whether to pursue this at this point. > 2/ > It would be even more great if ToolBar#add_tool supports "hash style" > named arguments. Then we could merge add_tool and insert_tool as > following : > > # add > my_toolbar.add_tool("Text", my_bitmap) > # insert > my_toolbar.add_tool("Text", my_bitmap, :position => 3) I think this is pretty possible and desirable. Feel free to post a feature request or even better an implementation. alex From noreply at rubyforge.org Fri Feb 29 21:33:17 2008 From: noreply at rubyforge.org (noreply at rubyforge.org) Date: Fri, 29 Feb 2008 21:33:17 -0500 (EST) Subject: [wxruby-development] [ wxruby-Bugs-18508 ] Sizer#get_children not mapped correctly, SizerItem missing Message-ID: <20080301023317.D1ED818585A0@rubyforge.org> Bugs item #18508, was opened at 2008-03-01 02:33 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=18508&group_id=35 Category: Missing API call Group: None Status: Open Resolution: None Priority: 3 Submitted By: Alex Fenton (brokentoy) Assigned to: Alex Fenton (brokentoy) Summary: Sizer#get_children not mapped correctly, SizerItem missing Initial Comment: Sizer#add currently returns an opaque swig type of SizerItem. Sizer#get_children currently returns an opaque swig type of SizerItemList. The return type should clearly be an array, but not certain what it should contain. SizerItem is not currently ported, but could be. Or it could return an array of Windows, Sizer and perhaps nil to represent a spacer. ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=18508&group_id=35