Hi! I''m proceeding with my image organizer program, now one can get pictures in their acual size: a new dialog box is created, the image inside. BUT It seems, that this memory is reserved, so not freed, when I close the dialog. Do I have to delete the Bitmap manually, when closing the corresponding dialog window? Or what? thx in advance ps: I will send the code next year... Gergo -- +-[ Kontra, Gergely<kgergely@mcl.hu> PhD student Room IB113 ]---------+ | http://www.mcl.hu/~kgergely "Olyan langesz vagyok, hogy | | Mobil:(+36 20) 356 9656 ICQ: 175564914 poroltoval kellene jarnom" | +-- Magyar php mirror es magyar php dokumentacio: http://hu.php.net --+
KONTRA Gergely wrote:> I''m proceeding with my image organizer program, now one can get pictures > in their acual size: a new dialog box is created, the image inside.Cool.> BUT > > It seems, that this memory is reserved, so not freed, when I close the > dialog. Do I have to delete the Bitmap manually, when closing the > corresponding dialog window? Or what?Ah, yes. This is the biggest remaining TO DO item before wxruby can be considered stable enough for production use. Currently, it does a very poor job with memory management. In most cases, it simply chooses not to free anything, because it isn''t smart enough yet to know what can be freed and what cannot. I have a few ideas for solving this, but do not yet have a concrete plan. I want to find out how FXRuby solved the problem (assuming it has solved it). Hopefully your specific case can be fixed at the same time that we fix the general problem. I think this will have to wait until after the 0.2 release, but it will probably becom one of the highest priority tasks at that point. Sorry I couldn''t give you better news. Kevin
I don''t have a lot of time, but I did want to share some of what is happening. If nothing else, it will give me something to look back at when I am able to work on this problem. wxRuby is challenging in a few ways: It has ruby objects that point to C++ objects (this is the normal case), and C++ objects that point to ruby objects. An example of the latter is an event callback. It has ruby objects that are explicitly created by the wxRuby app, and it has ruby objects that are created implicitly. An example of the latter is when you call get_font and wxRuby has to "wrap" an existing C++ font objects that was created implicitly by wxWindows. Sometimes, the ruby object is ready to be released, but the C++ object needs to stay around because other C++ objects refer to it. Sometimes the ruby object still exists but the C++ object it points to has already been freed by wxWindows. Sometimes the C++ object is being destroyed and it has to release any ruby objects it points to. I think I remember some code in wxRuby where Park Heesob (the original author) was trying to solve it. But I know in some cases it resulted in segfaults because not all the cases were handled. I think part of the answer is to provide a "release" or "free" method for each wxRuby object. The hard part is getting it to always do the right thing. It seems to me that all of this must have been solved by wxPython, and probably also by FXRuby. I tried looking at each of those project to try to figure out what they were doing, but couldn''t figure it out. I haven''t yet contacted the maintainers to ask for their help. Kevin
Lyle Johnson (author of FXRuby) might be able to give some practical advice. Curt> -----Original Message----- > From: wxruby-users-bounces@rubyforge.org > [mailto:wxruby-users-bounces@rubyforge.org]On Behalf Of Kevin Smith > Sent: Thursday, January 22, 2004 12:18 AM > To: wxruby-users@rubyforge.org > Subject: Re: [Wxruby-users] memory management > > > I don''t have a lot of time, but I did want to share some of what is > happening. If nothing else, it will give me something to look back at > when I am able to work on this problem. > > wxRuby is challenging in a few ways: > > It has ruby objects that point to C++ objects (this is the normal case), > and C++ objects that point to ruby objects. An example of the latter is > an event callback. > > It has ruby objects that are explicitly created by the wxRuby app, and > it has ruby objects that are created implicitly. An example of the > latter is when you call get_font and wxRuby has to "wrap" an existing > C++ font objects that was created implicitly by wxWindows. > > Sometimes, the ruby object is ready to be released, but the C++ object > needs to stay around because other C++ objects refer to it. Sometimes > the ruby object still exists but the C++ object it points to has already > been freed by wxWindows. Sometimes the C++ object is being destroyed and > it has to release any ruby objects it points to. > > I think I remember some code in wxRuby where Park Heesob (the original > author) was trying to solve it. But I know in some cases it resulted in > segfaults because not all the cases were handled. I think part of the > answer is to provide a "release" or "free" method for each wxRuby > object. The hard part is getting it to always do the right thing. > > It seems to me that all of this must have been solved by wxPython, and > probably also by FXRuby. I tried looking at each of those project to try > to figure out what they were doing, but couldn''t figure it out. I > haven''t yet contacted the maintainers to ask for their help. > > Kevin > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.559 / Virus Database: 351 - Release Date: 1/7/2004 >
On Jan 22, 2004, at 12:18 AM, Kevin Smith wrote:> wxRuby is challenging in a few ways: > > It has ruby objects that point to C++ objects (this is the normal > case), and C++ objects that point to ruby objects. An example of the > latter is an event callback.Yes. For FXRuby, I addressed this problem (the mapping from C++ object pointers back to the Ruby instances) by storing the objects in a Hash, where the "keys" are the C++ pointers and the "values" are the Ruby instances (of type VALUE).> It has ruby objects that are explicitly created by the wxRuby app, and > it has ruby objects that are created implicitly. An example of the > latter is when you call get_font and wxRuby has to "wrap" an existing > C++ font objects that was created implicitly by wxWindows.Yes...> Sometimes, the ruby object is ready to be released, but the C++ object > needs to stay around because other C++ objects refer to it. Sometimes > the ruby object still exists but the C++ object it points to has > already been freed by wxWindows. Sometimes the C++ object is being > destroyed and it has to release any ruby objects it points to. > > I think I remember some code in wxRuby where Park Heesob (the original > author) was trying to solve it. But I know in some cases it resulted > in segfaults because not all the cases were handled. I think part of > the answer is to provide a "release" or "free" method for each wxRuby > object. The hard part is getting it to always do the right thing.The "free" function is the one that tells Ruby how to clean up the C++ object when the corresponding Ruby instance is released; in many cases, it''s as simple as just delete-ing the C++ object. The one that you guys are going to need to look at is the "mark" function, which is the function that Ruby calls during a garbage collection sweep to try to identify which objects are still reachable (i.e. in use). The basic ideas behind a mark-and-sweep garbage collection scheme aren''t unique to Ruby, and if you don''t already have a good handle on how it works you may want to look up some other references first (on the web or elsewhere). And yes, it is the understatement of the year to say, "The hard part is getting it to always do the right thing" ;) I think it''s working pretty well in FXRuby at this point, but GC-related bugs used to crop up all the time. Good luck, and let me know if I can offer any more specific advice, etc. Lyle