Perl debugging: watched/local variables do not appear/update immediately

[Yogislav]

Short Summary

When debugging (usually over a loop, rarely in other situations) my debugger does not refresh watched/local variables values. It only refreshes after I change tab or minimize window. It's especially anoying when I loop over large arrays looking for an iteration with one specific value, but it does not display to me immediatelly and I have to alt-tab every time I click F5

Steps to Reproduce

1. Create a list with several hashes, each containing several keys (tested on 7 hashes, about 20 keys each);
2. Write a code like this:

   
   #!/usr/bin/perl -d

my @list = ( { name => 'AAA', surname => 'AAA', street => 'AAA', number => 1, city => 'AAA', country => 'AAA' }, { name => 'BBB', surname => 'BBB', street => 'BBB', number => 3, city => 'BBB', country => 'BBB' },
{ name => 'CCC', surname => 'CCC', street => 'CCC', number => 2, city => 'CCC', country => 'CCC' },
{ name => 'DDD', surname => 'DDD', street => 'DDD', number => 6, city => 'DDD', country => 'DDD' },
{ name => 'EEE', surname => 'EEE', street => 'EEE', number => 4, city => 'EEE', country => 'EEE' },
{ name => 'FFF', surname => 'FFF', street => 'FFF', number => 9, city => 'FFF', country => 'FFF' },
{ name => 'GGG', surname => 'GGG', street => 'GGG', number => 11, city => 'GGG', country => 'GGG' },
);

foreach my $elem (@list) { my $a = $elem->{name}; my $b = $elem->{surname}; my $c = $elem->{street}; my $d = $elem->{number}; my $e = $elem->{city}; my $f = $elem->{country}; print "$a $b lives on $c street number $d in city of $e which lies in $f.\n"; }

3. Place a breakpoint on the print piece and start debuger;
4. Once the debugger starts, start clicking F5 (or another continue button of your choice) at a moderate pace (2-4 clicks/s) and watch the console. 
You may notice that no local variables have appeared at all or they appear, but after each or several iterations, the $a, $b and $c do not change their values anymore, while print() displays proper string for each iteration.

### Platform Information

*Komodo Edit or IDE?* Komodo IDE
*Komodo Version?* version 10.2.3, build 89902, platform win32-x86.
*Operating System (and version)?* Windows 7 Pro 64bit (6.1, 7601)

[mitchell-as]

Hi, do you mind giving a full code sample? I don't know enough Perl to verify this issue. Thank you.

Note to self: this might be a Perl debugger issue. Other languages (e.g. Python, Ruby) update their variables each loop iteration.

[Yogislav]

@mitchell-as I edited original post with full code

[mitchell-as]

Thank you for the code. I am not able to reproduce this on Linux. @cgchoffman when you have the chance, can you reproduce this on Windows? Thanks.

[Yogislav]

For extra effects, you may try to extend the list (insert same hashes 100 more times) and try debugging over it even faster. This way it may be even more obviouse, that the variables do not refresh on time.

[th3coop]

It's working fine for me. I tripped the hash list and press F5 as fast as I could (among other key stroke rates) and never saw an issue.

[Yogislav]

I just launched a GIF Recorder in order to record how it looks for me.. and with recorder running (recording or not) everything works fine. What I get from all that is: 1) When variables don't refresh, I need to change to different window, or minimize and maximize Komodo; 2) When I have GIF Recorder on top of my Komodo (even on another screen, recording something completely else) - variables do refresh; Conclusion: GIF Recorder probably counts as an "active" window on top of Komodo, and since having changing/minimizing active window causes variables to refresh, they do refresh with recorder running.

Question remains, if it's only my computer acting out (however one of my colleagues also experience this) or is it something with Komodo not handling too well?

[Naatan]

It's possible that the tree isnt repainting when the data is changed, but the window switch would force a paint. That said I don't see how a GIF Recorder would force a paint, but I suppose it's within the realm of possibilities.

Given we cannot reproduce this lets just aim to force a paint whenever the list is updated, which should be happening anyway.