On Sun, Jan 26, 2014 at 10:32 AM, Axel Simon <axel.si...@in.tum.de> wrote:
> 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?
I don't understand why you need a patch from me. I have no opinion
about any assertions other than the one I tripped over and I've said
that I think it should be removed and you've agreed. It's a one line
delete. Why do you need a patch?
/Don
>
> Cheers,
> Axel
>
------------------------------------------------------------------------------
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
