row-changed handler treepath lifespan

[Kevin Ryde]

The program below gets for me

signal handler:
  $VAR1 = bless( do{\(my $o = 137867656)}, 'Gtk2::TreePath' );
  0
mainline:
  $VAR1 = bless( do{\(my $o = 137867656)}, 'Gtk2::TreePath' );
GLib-ERROR **: /tmp/buildd/glib2.0-2.16.4/glib/gmem.c:156: failed to allocate 1657472160 bytes at foo.pl line 21.
Aborted

Is the treepath allowed to be kept and used later outside the signal
handler?  I know iters have bizarre lifespan rules, but I thought
treepaths were ok (or as ok as anything in the path/iter/model debacle
can be said to be ok! :-).


use strict;
use warnings;
use Gtk2 '-init';
use Data::Dumper;

my $store = Gtk2::ListStore->new ('Glib::String');

my $global_path;
$store->signal_connect (row_changed => sub {
                          my ($concat, $path, $iter) = @_;
                          $global_path = $path;
                          print "signal handler:\n";
                          print "  ",Dumper($global_path);
                          print "  ",$global_path->to_string,"\n";
                        });
$store->append;
$store->set ($store->get_iter_first, 0 => 'one');

print "mainline:\n";
print "  ",Dumper($global_path);
print "  ",$global_path->to_string,"\n";
exit 0;

_______________________________________________
gtk-perl-list mailing list
gtk-perl-list@...
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

[muppet]

On Jul 6, 2008, at 8:19 PM, Kevin Ryde wrote:

> Is the treepath allowed to be kept and used later outside the signal
> handler?  I know iters have bizarre lifespan rules, but I thought
> treepaths were ok (or as ok as anything in the path/iter/model debacle
> can be said to be ok! :-).

GtkTreePath is not a reference-counted object in C, but a plain old  
opaque thing.  When the C code destroys the path, it goes away.  Since  
you're getting this path from a signal invocation, it's not yours, and  
you can't keep it.

All you really have to do is make a copy, e.g. $global_path = $path-
 >copy().

Yes, it does suck.  This sort of boxed bug is one of the few places in  
Gtk2-Perl where you still have to think about memory management.  
Because of how GtkTreePath is implemented, there's no way for the perl  
wrapper to know that the object has been destroyed.

If i could change this without breaking lots of code, i'd rework the  
bindings for GtkTreePath not to be a normal opaque boxed wrapper, but  
actually return to perl the string representation of that path, and  
create a GtkTreePath from the string on demand in the bindings.  That  
would let you just give indices to the TreeModel API, which is what  
you really want to do anyway.

At the very least, might some operator overloading magic help?



--
The Master in the art of living makes little distinction between his  
work and his play, his labor and his leisure, his mind and his body,  
his education and his recreation, his love and his religion. He hardly  
knows which is which. He simply pursues his vision of excellence in  
whatever he does, leaving others to decide whether he is working or  
playing. To him he is always doing both.

   -- Zen Philosophy



_______________________________________________
gtk-perl-list mailing list
gtk-perl-list@...
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

[Kevin Ryde]

muppet <scott@...> writes:
>
> Since you're getting this path from a signal invocation, it's not
> yours, and you can't keep it.

Ah dear, yep.

> If i could change this without breaking lots of code, i'd rework the
> bindings for GtkTreePath not to be a normal opaque boxed wrapper, but
> actually return to perl the string representation of that path,

Or an array instead of a string.

> just give indices to the TreeModel API, which is what you really want
> to do anyway.

Yep.

> At the very least, might some operator overloading magic help?

Maybe, unless there'd be danger of making the obscure even more obscure
:).  I guess the treepath is not much more than an attempt in C at a
variable-length @array you push/pop and look through the values.
_______________________________________________
gtk-perl-list mailing list
gtk-perl-list@...
http://mail.gnome.org/mailman/listinfo/gtk-perl-list