Hi Don, On 25.01.2014, at 10:48, Donald Allen <donaldcal...@gmail.com> wrote:
> I don't think the warning is coming from Gtk. I think it's coming from
> gtk2hs/gtk/Graphics/UI/Gtk/ModelView/Gtk2HsStore.c
>
> static gboolean
> gtk2hs_store_iter_has_child (GtkTreeModel *tree_model,
> GtkTreeIter *iter /* in */)
> {
> WHEN_DEBUG(g_debug("calling gtk2hs_store_iter_has_child\t(%p,
> %p)\n", tree_model, iter));
> Gtk2HsStore *store = (Gtk2HsStore *) tree_model;
> g_return_val_if_fail (GTK2HS_IS_STORE (tree_model), FALSE);
> g_return_val_if_fail (iter->stamp == store->stamp, FALSE);
> <<<<<<<<<<<<<<<<<--------------------------------------
>
> gboolean result = gtk2hs_store_iter_has_child_impl(store->impl, iter);
> WHEN_DEBUG(g_debug("return gtk2hs_store_iter_has_child\t=%s\n",
> result ? "TRUE" : "FALSE"));
> return result;
> }
>
> I think this assertion is just wrong. It's assuming that the
> time-stamp on the store can't change in a callback that involves a
> time-stamped iter. That's not true, as I've demonstrated.
I see. Well, by all means, let's remove this assertion. Duncan and I coded this
with our assumptions about what the invariants should be. Are there other
assertions in the Gtk2Hs C code that should go?
> This all
> works correctly in my C version. (The statements I've made about what
> I think is right and wrong are based on a very cursory -- pun intended
> -- understanding of the gtk2hs code, so it's possible I'm all wet. I
> don't think so, but it's possible. This needs to be looked at by
> someone who really understands the code.)
>
So, as I've said: I tried to understand what the invariants are and the
assertions so far did point out incorrect code. I've never tried to get
on-demand adding of nodes to work, which is why I've not come across this.
> You might be able to find out which callback is fired by connecting
> to various likely ones and printing messages, possibly printing the
> TreeIter.
>>
>> In the extreme case, C would allow you to destructively change the stamp
>> while in the callback. That is hopefully not what the developers intended,
>> also because it's not obvious to what the stamp should be set.
>>
>> I hope this helps a bit.
>
> Thanks for trying. Perhaps your message has prompted me to make things
> a bit clearer.
>
> If there is a fix or something general rule, maybe we can add a
> comment to the signal so that other people know?
>
> I think there's just a bug in the code. Adding documentation isn't
> going to fix it at this point. I make this statement because I'm able
> to accomplish what I described quite easily in my C version and should
> be able to do so in Haskell. I believe the bug is in the gtk2hs layer,
> as I described above.
Ok, let's remove this assertion and any other assertion that you think is
out-of-place. If this does not affect all callbacks, then maybe we can have a
comment in the C code saying why the iterators may have a different time stamp
so that people don't put the assertion back in if they eyeball the code in the
future.
Can you send a patch?
Cheers,
Axel
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------ CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
