librelist archives

« back to archive

infinite loop in EditLine

infinite loop in EditLine

From:
Charles Remes
Date:
2013-12-19 @ 18:00
I have a shoes app that I'm porting to Shoes4. It's been very easy so far.

One issue that has just recently bitten me has to do with EditLines (a 
subclass of InputBox) and how changes to the box are published to all 
listeners.

In my app, when a user is typing something into the box I have the 
callback do some parsing on the text. If a match is found, the entered 
text is replaced by a sanitized version. The problem that I am seeing is 
that this leads to infinite recursion and a stack overflow in the JVM. 
This happens because when I set the text within the callback this in turn 
causes the callback to be called *again,* ad infinitum.

Here's some code:


  def text_element(head)
    @stack.app.edit_line(:width => head[:width] - 10, :margin => 5) do |e|
      if Defaults.has_key?(e.text)
        e.text = e.text.upcase # setting the #text field causes this 
callback to trigger again, infinitely
      end
    end
  end

I can solve this within the callback by changing the "if" to detect that 
the text hasn't actually changed so the test fails and the callback exits.
However, it feels like this should be solved by the library itself (like 
Shoes3). I suspect that I can fix this in the SWT backend by checking the 
event "e" and if it's a ModifyEvent and the text is the same as before, 
don't pass this event on to any listeners. Does that sound reasonable or 
is there a better solution?

cr

Re: [shoes] infinite loop in EditLine

From:
Tobias Pfeiffer
Date:
2013-12-20 @ 10:40
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thank you Charles for your report!

For the information of everybody: Charles was kind enough to already
fix this in a pull request to the shoes4 project, you can check it out
here: https://github.com/shoes/shoes4/pull/505

Cheers,
Tobi

On Thu 19 Dec 2013 07:00:47 PM CET, Charles Remes wrote:
> I have a shoes app that I'm porting to Shoes4. It's been very easy so far.
>
> One issue that has just recently bitten me has to do with EditLines (a 
subclass of InputBox) and how changes to the box are published to all 
listeners.
>
> In my app, when a user is typing something into the box I have the 
callback do some parsing on the text. If a match is found, the entered 
text is replaced by a sanitized version. The problem that I am seeing is 
that this leads to infinite recursion and a stack overflow in the JVM. 
This happens because when I set the text within the callback this in turn 
causes the callback to be called *again,* ad infinitum.
>
> Here's some code:
>
>
>   def text_element(head)
>     @stack.app.edit_line(:width => head[:width] - 10, :margin => 5) do |e|
>       if Defaults.has_key?(e.text)
>         e.text = e.text.upcase # setting the #text field causes this 
callback to trigger again, infinitely
>       end
>     end
>   end
>
> I can solve this within the callback by changing the "if" to detect that
the text hasn't actually changed so the test fails and the callback exits.
However, it feels like this should be solved by the library itself (like 
Shoes3). I suspect that I can fix this in the SWT backend by checking the 
event "e" and if it's a ModifyEvent and the text is the same as before, 
don't pass this event on to any listeners. Does that sound reasonable or 
is there a better solution?
>
> cr
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJStB6iAAoJEBzX32BGBaITHTQIANISFdLU7gd+CB6WsEbGm9Ae
RTCrOBCAqkLVTxk2vx+vIiukBaFOxn2YCsWTEX9dFh50rNW+p0zMzKRfo63g0VC+
+1ejguYuy3jD4fjnA5Oo2jg2IkecfwPsoFWrcWj36Ur/3pmgEr66V16Xej/Yk4mF
HdglYO7eqb1NuHZ5mH8uHNjDndNmKJTlaDIzN21kOYR70LfsJQv98Wj4QPHxMDD0
C5XlsBgLAhhLWMV97i1MLgCZ5vxxxsegaGYtsq6SAtFN7hVE52BD0/LtTRZ4qk0P
3aI+tLnx8I3Ow/Lp5BVu5/yYYUXx31DcipE4rxLCeJ1k0/CPltk8Xzqqzzj+sds=
=pCuF
-----END PGP SIGNATURE-----

Re: [shoes] infinite loop in EditLine

From:
Tobias Pfeiffer
Date:
2013-12-20 @ 10:46
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oh and of course I'm personally super happy that you try to convert
your old shoes3 app to shoes4 and find that to be a pleasant experience
so far! Thanks for the pre-alpha testing! =)

On Fri 20 Dec 2013 11:40:34 AM CET, Tobias Pfeiffer wrote:
> Thank you Charles for your report!
>
> For the information of everybody: Charles was kind enough to already
> fix this in a pull request to the shoes4 project, you can check it out
> here: https://github.com/shoes/shoes4/pull/505
>
> Cheers,
> Tobi
>
> On Thu 19 Dec 2013 07:00:47 PM CET, Charles Remes wrote:
>> I have a shoes app that I'm porting to Shoes4. It's been very easy so far.
>>
>> One issue that has just recently bitten me has to do with EditLines (a 
subclass of InputBox) and how changes to the box are published to all 
listeners.
>>
>> In my app, when a user is typing something into the box I have the 
callback do some parsing on the text. If a match is found, the entered 
text is replaced by a sanitized version. The problem that I am seeing is 
that this leads to infinite recursion and a stack overflow in the JVM. 
This happens because when I set the text within the callback this in turn 
causes the callback to be called *again,* ad infinitum.
>>
>> Here's some code:
>>
>>
>>   def text_element(head)
>>     @stack.app.edit_line(:width => head[:width] - 10, :margin => 5) do |e|
>>       if Defaults.has_key?(e.text)
>>         e.text = e.text.upcase # setting the #text field causes this 
callback to trigger again, infinitely
>>       end
>>     end
>>   end
>>
>> I can solve this within the callback by changing the "if" to detect 
that the text hasn't actually changed so the test fails and the callback 
exits. However, it feels like this should be solved by the library itself 
(like Shoes3). I suspect that I can fix this in the SWT backend by 
checking the event "e" and if it's a ModifyEvent and the text is the same 
as before, don't pass this event on to any listeners. Does that sound 
reasonable or is there a better solution?
>>
>> cr
>>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJStB/uAAoJEBzX32BGBaITSyAH/1v93UyahgUssS5aUSgjqGlI
OtFLP2+eABNmnm7dsBKaonUBaNk2LdbabCBlSrgAJZGn4Ip8id9JsHoqcfdp5PHL
fZWKcDPMs9QB3HtAe9jSrhwvp6h9ure/LTQKzhubzvGwGqnEmg/7DhakGuK4t1uB
IxgkSBcjczNNjE0t8Lh3AS6CnnzgQrC5Gfm4D8LD8hB83L+V/ViXgudZ6RXeyZ9V
BrVMwj41doef9PmRMzf+fNJflt3kKfzS7z5HuoqEG+CHzfUcUMRnIFiX8IjTMfU0
dtyI+lcwFQC850kH78ZANcr3WjGwg24wsjEfhaQPA9Hq3G5ec2PePbaME/RIBkg=
=YdZI
-----END PGP SIGNATURE-----