On Nov 1, 2010, at 14:27 , Konovalov, Vadim (Vadim)** CTR ** wrote: >> From: Gisle Aas [mailto:[email protected]] > >> Right. The attached patch does exactly that. It allows this >> program to work as expected: > > very nice. > >> ---------------- >> use strict; >> use warnings; >> use Tkx; >> >> Tkx::package_require("Tktable"); >> >> my $mw = Tkx::widget->new("."); >> my %hash = ( # data to display >> '0,0' => 'Goodby', >> '1,1' => 'cruel', >> '2,2' => 'world', >> ); >> >> my $t = $mw->new_table( >> -rows => 5, >> -cols => 3, >> -cache => 1, >> -variable => \%hash, >> ); >> $t->g_pack(-fill => 'both', -expand => 1); >> Tkx::MainLoop(); >> use Data::Dump; dd \%hash; >> ---------------- >> >> One uglyness is that the hash is copied the first time it's >> passed to a Tcl function in this way. I wonder if it would > > As far as I understand, you're copying to allow 'tie'. > Am I correct that you think of it as 'ugly' because of cases when there will > be large amount of data to copy?
Right. It seems like it can be quite inefficient if you set up large tables that you then pass to Tcl. If this turn out to be an issue, you can always just pass the empty hash initially and then fill it afterwords. >> be possible to set up some arrangement with tracing on the >> Tcl side that calls back into Perl so that we can actually >> keep that hash on the Perl side; thus avoiding the copy. Too >> complicated? > > I see no big reason for the hash to be on Perl side. > At least current implementation looks to me consistent with other Perl > 'tie's, and also with current Tcl bindings. It's certainly simpler to use the existing mechanism. I applied this patch with tests to the repo at <http://github.com/gisle/tcl.pm>. I also applied a patch to fix RT#56721. Vadim, do you want to roll a new release? Is there other of the RT issues you think we can resolve now? --Gisle
