On Sun, 2011-02-20 at 22:25 +0000, vadrer wrote:
> Hi,
> 
> Some time ago (long ago) we tried to establish a way when CODE REFs
> created in Tcl::call would be properly refcounted, but then gave up.
> 
> it appears that now I found a way how it could be done in a 99.999%
> clean way.
> 
> I've just commited into repo Tcl.pm on github, 
> https://github.com/gisle/tcl.pm/commit/fe4305492ee9fc845c992fae13c91fa01da26cdb
> so following piece of code behaves correctly:


and now I realised that in Tcl::eval sub we could put to %anon_refs hash
just information based on __FILE__ and __LINE__ of invoked subroutine,
just via 'caller' perl function, then CODE refcounting would be just
fine, i.e. proper destroy of Tcl commands could be managed in time.

all the same but key to hash is caller - all should be fine.

> 
> 
> use strict;
> use Tcl;
> use Tcl::Tk;
> 
> my $int = new Tcl::Tk;
> 
> $int->Eval(<<'EOS');
> package require Tk
> pack [button .b1 -text b1]
> pack [button .b2 -text b2]
> pack [button .b3 -text b3]
> focus .b1
> EOS
> 
> if (1) {
>     my $r = 'aaa';
> $int->call('.b1','configure',-command=>sub {print ".b1\n";});
> $int->call('.b2','configure',-command=>sub {print ".b2\n";});
> $int->call('.b3','configure',-command=>sub {
>       print "reconfiguring .b2 r=$r\n";
>       $r++;
>       $int->call('.b2','configure',-command=>sub {print "***.B2*** $r;\n";},
> -text=> '.B2');
>     });
> }
> 
> $int->icall('tkwait', 'window', '.');
> 
> 
> Button .b3 on click changes -command for .b2 button, and this command
> resolves to new TCL name each time, because of some scope lexical. 
> 
> However previous -command for .b2 button is now destroyed, due to my
> latest change (well, not destroyed very initial -command for .b2, for
> some known reasons)
> 
> I will also add t/ test file for this,
> also I'll remove debugging output, and also fix some spur at the end - 
> 
> ====
> called Tcl_FindHashEntry on deleted table
> Aborted
> ====
> 
> I would like to hear from experts - does it works for all.
> 
> Also, is it useful to do same work for Tcl variables as well, or tcl
> vars are not that often?
> 
> Thanks,
> Vadim.
> 
> 


Reply via email to