wxruby users - May 2010 - Does stack get unwound when event returns without skip?

I''m using a TextCtrl in an editor and in my evt_key_down, evt_key_up,
etc. handlers I''ve been avoiding using event.skip in order to get the
behavior I want, but it looks like that is making the stack grow.  Can
someone tell me if the stack gets unwound when an event handler finishes
without using skip?  And, if it doesn''t, if there is another good way
get it unwound before exiting.

Any help would be appreciated.

Thanks,
Ross
-- 
Posted via http://www.ruby-forum.com/.

Ross Goodell wrote:
> I''m using a TextCtrl in an editor and in my evt_key_down,
evt_key_up,
> etc. handlers I''ve been avoiding using event.skip in order to get
the
> behavior I want, but it looks like that is making the stack grow.  Can
> someone tell me if the stack gets unwound when an event handler finishes
> without using skip?  And, if it doesn''t, if there is another good
way
> get it unwound before exiting.
> 
> Any help would be appreciated.
> 
> Thanks,
> Ross
Further experimentation has shown me that whatever the problem is, it 
has nothing to do with not using skip.

Ross
-- 
Posted via http://www.ruby-forum.com/.

Hi Ross

On 06/05/2010 00:27, Ross Goodell wrote:
> I''m using a TextCtrl in an editor and in my evt_key_down,
evt_key_up,
> etc. handlers I''ve been avoiding using event.skip in order to get
the
> behavior I want, but it looks like that is making the stack grow.  Can
> someone tell me if the stack gets unwound when an event handler finishes
> without using skip?  And, if it doesn''t, if there is another good
way
> get it unwound before exiting.
>    
I''m not totally sure what you mean by "unwound" here. It
sounds like
you''re concerned that the Event object isn''t getting released
and
garbage collected, and so the total world of Ruby objects is growing and 
consuming memory.

As your later post suggests, skip() shouldn''t affect this - it just 
signals whether the event should be passed on to other handlers for 
processing. There is some special and careful handling of Events in the 
wxRuby interface to C++, so if you''ve found a memory leak, I''d
be really
grateful if you could provide a simple example which demonstrates.

thanks
alex

Alex Fenton wrote:
> Hi Ross
> 
> On 06/05/2010 00:27, Ross Goodell wrote:
>> I''m using a TextCtrl in an editor and in my evt_key_down,
evt_key_up,
>> etc. handlers I''ve been avoiding using event.skip in order to
get the
>> behavior I want, but it looks like that is making the stack grow.  Can
>> someone tell me if the stack gets unwound when an event handler
finishes
>> without using skip?  And, if it doesn''t, if there is another
good way
>> get it unwound before exiting.
>>    
> 
> I''m not totally sure what you mean by "unwound" here. It
sounds like
> you''re concerned that the Event object isn''t getting
released and
> garbage collected, and so the total world of Ruby objects is growing and
> consuming memory.
> 
> As your later post suggests, skip() shouldn''t affect this - it
just
> signals whether the event should be passed on to other handlers for
> processing. There is some special and careful handling of Events in the
> wxRuby interface to C++, so if you''ve found a memory leak,
I''d be really
> grateful if you could provide a simple example which demonstrates.
> 
> thanks
> alex
Thanks Alex.  By not getting "unwound" I meant that the stack that was
displayed when I gave the "w" command in the Ruby debugger continued
to
show entries for methods called by an exception handler, e.g. rescue 
NameError => noMethodErrorObj during the processing for an event handler 
such as evt_key_up, after the exception handler had completed.  (Also by 
using the "up" command in the Ruby debugger I found that the old
stacked
local variables really were still available.)

Further experiments since I made that last post suggested to me that at 
least much of it was caused by my using logic in Ruby rescue clauses to 
complete the processing and assuming that the subsequent return from the 
method would "unwind" the stack in the same way as a normal method 
return.  Some experimentation seemed to indicate that I need to use 
retry if I want to get the stack "unwound" normally.  I''m now
in the
process of making that change everywhere I need to and seeing if that 
solves my problem.

My hypothesis in this is that rescue must be intended only for logic 
that will terminate the program unless retry is given.  If that''s wrong
and there is a problem in wxRuby, I will certainly get a simple example 
together and pass it on to you.  However, I''m about to go on vacation, 
so it may be a few weeks before I get it done.

Thanks very much for your response,
Ross
-- 
Posted via http://www.ruby-forum.com/.

On 19/05/2010 02:12, Ross Goodell wrote:
> Thanks Alex.  By not getting "unwound" I meant that the stack
that was
> displayed when I gave the "w" command in the Ruby debugger
continued to
> show entries for methods called by an exception handler, e.g. rescue
> NameError =>  noMethodErrorObj during the processing for an event
handler
> such as evt_key_up, after the exception handler had completed.  (Also by
> using the "up" command in the Ruby debugger I found that the old
stacked
> local variables really were still available.)
>    
That''s interesting to know. From debugging on the C++ side, how I think
it should look is that a wxRuby app is constantly within a main_loop 
method. Within that it''s sequentially in a series of event handlers, 
which are called Procs. So perhaps if the next event hasn''t started,
the
old stack context is still there, even if practically it''s finished.
> Further experiments since I made that last post suggested to me that at
> least much of it was caused by my using logic in Ruby rescue clauses to
> complete the processing and assuming that the subsequent return from the
> method would "unwind" the stack in the same way as a normal
method
> return.  Some experimentation seemed to indicate that I need to use
> retry if I want to get the stack "unwound" normally. 
I''m now in the
> process of making that change everywhere I need to and seeing if that
> solves my problem.
>    
What''s the problem that it''s causing for your app? I would
limit using
rescue/retry to genuine Ruby exception conditions; there should be a 
more straightforward way to do it if it''s ordinary event processing. PS
- I expect you''ve already noted this, but never hold a reference to a 
Wx::Event object (eg in an @instance_variable). wxRuby is likely to 
delete the object from under you causing crashes or other problems.
> My hypothesis in this is that rescue must be intended only for logic
> that will terminate the program unless retry is given.  If that''s
wrong
> and there is a problem in wxRuby, I will certainly get a simple example
> together and pass it on to you.  However, I''m about to go on
vacation,
> so it may be a few weeks before I get it done.
>    
Rescue should work as in "normal" ruby; it''s just that all
the code
running in a GUI app is the event handling code, with the main_loop as 
the root context of the stack.

Hope you have a good holiday, please get in touch if further questions 
come up.

a

Alex,

I apologize for being so late in responding.  I?d intended to come up 
with a small example of the problem, but it turned out to be more 
difficult than I?d expected.  Then vacation and other activities wiped 
out most of about 7 weeks.

I eventually was able to reduce the stack build-up significantly, by 
avoiding passing the Wx::Event objects and other clean-ups.  I also 
moved my working logic out of all the rescue blocks.  I understand that 
shouldn?t make a difference.  I had the impression that it did reduce 
the stack build-up, but I could very well be mistaken.  Perhaps your 
conjecture--that if the next event hasn''t started, the old stack
context
is still there--is correct.

I did not eliminate all of my use of exception handling for non-terminal 
errors.  I use exception handling to improve the program?s performance 
when checking for those problems ahead of time in my program when I 
believe that it would be a significant performance hit.

I was never able to reproduce any of the remaining stack build-up 
problems in my simplified example, so I still don?t know what is going 
on.  The stack build-up is slow enough that I?ve never been aware of it 
interfering with my program?s behavior.

Thanks again for all your help.

My regards,
Ross


Alex Fenton wrote:
> On 19/05/2010 02:12, Ross Goodell wrote:
>> Thanks Alex.  By not getting "unwound" I meant that the stack
that was
>> displayed when I gave the "w" command in the Ruby debugger
continued to
>> show entries for methods called by an exception handler, e.g. rescue
>> NameError =>  noMethodErrorObj during the processing for an event
handler
>> such as evt_key_up, after the exception handler had completed.  (Also
by
>> using the "up" command in the Ruby debugger I found that the
old stacked
>> local variables really were still available.)
>>    
> 
> That''s interesting to know. From debugging on the C++ side, how I
think
> it should look is that a wxRuby app is constantly within a main_loop
> method. Within that it''s sequentially in a series of event
handlers,
> which are called Procs. So perhaps if the next event hasn''t
started, the
> old stack context is still there, even if practically it''s
finished.
> 
>> Further experiments since I made that last post suggested to me that at
>> least much of it was caused by my using logic in Ruby rescue clauses to
>> complete the processing and assuming that the subsequent return from
the
>> method would "unwind" the stack in the same way as a normal
method
>> return.  Some experimentation seemed to indicate that I need to use
>> retry if I want to get the stack "unwound" normally. 
I''m now in the
>> process of making that change everywhere I need to and seeing if that
>> solves my problem.
>>    
> 
> What''s the problem that it''s causing for your app? I
would limit using
> rescue/retry to genuine Ruby exception conditions; there should be a
> more straightforward way to do it if it''s ordinary event
processing. PS
> - I expect you''ve already noted this, but never hold a reference
to a
> Wx::Event object (eg in an @instance_variable). wxRuby is likely to
> delete the object from under you causing crashes or other problems.
> 
>> My hypothesis in this is that rescue must be intended only for logic
>> that will terminate the program unless retry is given.  If
that''s wrong
>> and there is a problem in wxRuby, I will certainly get a simple example
>> together and pass it on to you.  However, I''m about to go on
vacation,
>> so it may be a few weeks before I get it done.
>>    
> 
> Rescue should work as in "normal" ruby; it''s just that
all the code
> running in a GUI app is the event handling code, with the main_loop as
> the root context of the stack.
> 
> Hope you have a good holiday, please get in touch if further questions
> come up.
> 
> a
-- 
Posted via http://www.ruby-forum.com/.