wxlua-users Mailing List for wxLua (Page 2)

On Tue, Nov 18, 2008 at 9:03 AM, Evan DeMond <eva...@gm...> wrote:
> Thanks for the info; I managed to diagnose what was going on: the event
> handler for my wxSocketClient was getting cleaned up accidentally, since
> apparently you have to create one explicitly to handle events with that
> object.

Just use your wxFrame or any wxWindow; you can even use wxGetApp(),
the wxApp. There's nothing special about any particular wxEvtHandler.
The only thing you have to worry about is being able to determine
where the events come from, use unique IDs.

> As an aside, is there any known reason why wxSocketBase shouldn't derive
> from wxEvtHandler? That choice doesn't entirely make sense to me.

Because it doesn't in C++.

Regards,
    John

Thanks for the info; I managed to diagnose what was going on: the event
handler for my wxSocketClient was getting cleaned up accidentally, since
apparently you have to create one explicitly to handle events with that
object.

As an aside, is there any known reason why wxSocketBase shouldn't derive
from wxEvtHandler? That choice doesn't entirely make sense to me.

Thanks all,
Evan

On Sat, Nov 15, 2008 at 7:09 PM, Eero Pajarre <epa...@gm...> wrote:
>
>> To be sure, you cannot create anything you want to outlive the current
>> scope with the "local" keyword since it will be GCed.
>
> It may be that one of things which led to my confusion was that
> with GUI objects you can let their "Lua variables" to go out of their scope
> if they have been added to an other GUI object. This association is enough
> for keeping them alive
>
> (and actually it appears that a visible frame is not collected, even if its Lua
> variable goes out of scope)

Ahh, there's the rub, all wxWindow derived classes are owned by their
parents and the top level windows, like a wxFrame or wxDialog, are are
expected to exist until the user explicitly closes them. When you look
at the binding files you will see the %delete keyword in the %class
declaration for all objects that will be garbage collected. This is
the way it has to be to avoid double deletion or no deletion at all.
You will also see the very rare cases of the %gc and %ungc tags used
to enforce changes in ownership.

http://wxlua.sourceforge.net/docs/wxluaref.html

> But the fact that the timer is live (creating timer events), will not save it
> from GC.

We cannot possibly check for all special cases like this where some
object might be "active" or not, the code base would balloon to the
point of being unmaintainable or incomprehensible.

> And  of course after I realised that my timer will get collected I was able to
> avoid that.  It just took some time to realise... My wxLua main program
> forces gc_step so often that my timer never had time to trigger, so I
> thought that it was not working at all.
>
> btw. even after some reconsidering I think that the way how it works,
> is the correct/better behaviour for timers

Good, there are unfortunately a few seemingly oddities like wxWindows
from a Lua standpoint, but the bottom line is that I've tried to be
consistent with the C++ version. Any object taking or loosing
ownership of another in the C++ wxWidgets docs also applies to wxLua
and if it didn't your program would crash. The silent failure of your
wxTimer is unfortunate, but it is behaving correctly.

Regards,
    John

On Sat, Nov 15, 2008 at 9:02 PM, John Labenski <jla...@gm...> wrote:
> On Sat, Nov 15, 2008 at 2:58 AM, Eero Pajarre <epa...@gm...> wrote:
>>
>> Just wanted to tell about my own experience, which I told on this
>> mailing list in June. wxTimers can be garbage collected even if they
>> are in use. So if you use timers you might want to check for that possibility.
>>
>
> Could you elaborate? There is no reason why a wxTimer should be
> deleted and not a wxPoint for the same code.
>

Sorry I didn't want to say that I considered the behaviour wrong.

I just wanted mention this because it managed to confuse me
for a while when it happened in my code.


> To be sure, you cannot create anything you want to outlive the current
> scope with the "local" keyword since it will be GCed.

It may be that one of things which led to my confusion was that
with GUI objects you can let their "Lua variables" to go out of their scope
if they have been added to an other GUI object. This association is enough
for keeping them alive

(and actually it appears that a visible frame is not collected, even if its Lua
variable goes out of scope)

But the fact that the timer is live (creating timer events), will not save it
from GC.

And  of course after I realised that my timer will get collected I was able to
avoid that.  It just took some time to realise... My wxLua main program
forces gc_step so often that my timer never had time to trigger, so I
thought that it was not working at all.

btw. even after some reconsidering I think that the way how it works,
is the correct/better behaviour for timers

     Eero

See this thread on the Lua list for a current discussion about some
related problems with Lua's GC and userdata.

http://lua-users.org/lists/lua-l/2008-11/msg00262.html

Also note that you can tweak up the collector to make it more
aggressive, but getting the right values is a trial and error process
as the values of setpause and setstepmul are not simple.

See the collectgarbage() function
http://www.lua.org/manual/5.1/manual.html#pdf-collectgarbage

wxLua already does this at startup to make it a little more frequent:

        // Make the GC a little more aggressive since we push void* data
        // that may be quite large. The upshot is that Lua runs faster.
        // Empirically found by timing: "for i = 1, 1E6 do local p =
wx.wxPoint() end"
        lua_gc(L, LUA_GCSETPAUSE, 120);
        lua_gc(L, LUA_GCSETSTEPMUL, 400);

Regards,
    John


On Fri, Nov 14, 2008 at 12:28 PM, John Labenski <jla...@gm...> wrote:
> On Thu, Nov 13, 2008 at 7:16 PM, Evan DeMond <eva...@gm...> wrote:
>> Hi all,
>>
>> I've got a wxLua application that freezes when Lua performs garbage
>> collection. I suspect that some important piece of the application is
>> getting garbage collected - so I need to devise a way to tell what's getting
>> garbage collected and when. The __gc metamethod was my first idea, but that
>> has to be set from the C API, and can't be set from within Lua, so that
>> seems out.
>>
>> Any other recourse I can take to figure out what's going on here?
>
> You cannot get the list of objects that will be GCed in the next
> cycle, but you can get a complete list of wxWidgets objects that will
> be garbage collected when there are no more references to them in Lua.
>
> Search for this word: GetTrackedWindowInfo
> Here: http://wxlua.sourceforge.net/docs/wxluaref.html
>
> I recommend just printing them out occasionally and see if you are
> collecting a lot of objects and add a call to obj:delete() to force
> immediate collection. You may need to do this in "for" loops where you
> may generate a lot of them since the Lua GC only runs (I may not
> remember correctly) for table creation, function calls, and maybe
> something else.
>
> You can also call collectgarbage("collect") to force collections at
> the end of functions that you know generate a lot of objects that will
> be garbage collected. However, I recommend being more proactive with
> the :delete() function if you really are generating a lot of them.
>
> Hope this helps,
>    John
>

On Sat, Nov 15, 2008 at 2:58 AM, Eero Pajarre <epa...@gm...> wrote:
>
> Just wanted to tell about my own experience, which I told on this
> mailing list in June. wxTimers can be garbage collected even if they
> are in use. So if you use timers you might want to check for that possibility.
>

Could you elaborate? There is no reason why a wxTimer should be
deleted and not a wxPoint for the same code.

To be sure, you cannot create anything you want to outlive the current
scope with the "local" keyword since it will be GCed. If you don't
want to pollute the global table with objects you can tuck your
wxTimer into a frame or a special table of things you want to keep.

Try this in the minimal.wx.lua sample, put it just before the
frame:Show(true) line.


    frame.timer = wx.wxTimer(frame, 100)
    frame:Connect(100, wx.wxEVT_TIMER,
        function (event)
            wx.wxMessageBox('This is the timer dialog of the Minimal
wxLua sample.\n'..
                            wxlua.wxLUA_VERSION_STRING.." built with
"..wx.wxVERSION_STRING,
                            "About wxLua",
                            wx.wxOK + wx.wxICON_INFORMATION,
                            frame)
        end )

    frame.timer:Start(5000, false)



Hope this helps,
    John

On Fri, Nov 14, 2008 at 2:16 AM, Evan DeMond <eva...@gm...> wrote:
> Hi all,
>
> I've got a wxLua application that freezes when Lua performs garbage
> collection. I suspect that some important piece of the application is
> getting garbage collected - so I need to devise a way to tell what's getting
> garbage collected and when. The __gc metamethod was my first idea, but that
> has to be set from the C API, and can't be set from within Lua, so that
> seems out.
>
> Any other recourse I can take to figure out what's going on here?
>

Just wanted to tell about my own experience, which I told on this
mailing list in June. wxTimers can be garbage collected even if they
are in use. So if you use timers you might want to check for that possibility.



   Eero

On Thu, Nov 13, 2008 at 7:16 PM, Evan DeMond <eva...@gm...> wrote:
> Hi all,
>
> I've got a wxLua application that freezes when Lua performs garbage
> collection. I suspect that some important piece of the application is
> getting garbage collected - so I need to devise a way to tell what's getting
> garbage collected and when. The __gc metamethod was my first idea, but that
> has to be set from the C API, and can't be set from within Lua, so that
> seems out.
>
> Any other recourse I can take to figure out what's going on here?

You cannot get the list of objects that will be GCed in the next
cycle, but you can get a complete list of wxWidgets objects that will
be garbage collected when there are no more references to them in Lua.

Search for this word: GetTrackedWindowInfo
Here: http://wxlua.sourceforge.net/docs/wxluaref.html

I recommend just printing them out occasionally and see if you are
collecting a lot of objects and add a call to obj:delete() to force
immediate collection. You may need to do this in "for" loops where you
may generate a lot of them since the Lua GC only runs (I may not
remember correctly) for table creation, function calls, and maybe
something else.

You can also call collectgarbage("collect") to force collections at
the end of functions that you know generate a lot of objects that will
be garbage collected. However, I recommend being more proactive with
the :delete() function if you really are generating a lot of them.

Hope this helps,
    John

Hi all,

I've got a wxLua application that freezes when Lua performs garbage
collection. I suspect that some important piece of the application is
getting garbage collected - so I need to devise a way to tell what's getting
garbage collected and when. The __gc metamethod was my first idea, but that
has to be set from the C API, and can't be set from within Lua, so that
seems out.

Any other recourse I can take to figure out what's going on here?

Thanks,

Evan

I've made wxlua packages for maemo (http://maemo.org) and posted them on my
site. You can install them on your N810 or (possibly) on your N770 by pointing
your browser at http://tomshiro.org/lua-maemo and bonking the appropriate links.

Happy Hacking!

-- CHS