[04:12] <smspillaz> desrt: hey, do you know if g_settings_unref is meant to implicitly unref any value that you might have retrived from the same key using g_settings_get_value ?
[04:13] <smspillaz> I seem to have to do:
[04:13] <smspillaz> GVariant *v = g_settings_get_value (settings, "key");
[04:13] <smspillaz> g_variant_ref (v);
[04:13] <smspillaz> g_settings_reset (v);
[04:13] <smspillaz> erm, - g_settings_reset (settings, "key");
[04:13] <smspillaz> g_variant_unref (v);
[04:13] <smspillaz> in order to not get a warning about a double unref
[04:14] <smspillaz> (valgrind says there are no leaks when I do that as well)
[04:14] <smspillaz> oh, s/g_settings_unref/g_settings_reset
[06:35] <Maiz_en_Heces> anybody here?
[08:21] <MCR1> smspillaz: Hi :) Are you here ?
[16:09] <ahoneybun> I can not log into pad.ubuntu.com
[16:27] <desrt> smspillaz: erm...
[16:28] <desrt> smspillaz: g_settings_get_value() returns a reference.  you should call unref() on the return value, not ref.
[16:28] <desrt> it's possible your refcounting issues lie elsewhere
[16:28] <desrt> for example, i hope you're not doing something like this:
[16:28] <desrt> v = g_variant_new_int32 (4);
[16:28] <desrt> g_settings_set_value (s, "foo", v);
[16:28] <desrt> g_variant_unref (v);
[23:44] <smspillaz> desrt: right, I am using set_value
[23:44] <smspillaz> desrt: anything in particular I should know? I need to wrap the API for testing purposes and varargs aren't really territory I want to venture into
[23:46] <smspillaz> desrt: so to clarify, I'm doing something like
[23:46] <smspillaz> v = g_variant_new_int32 (blah);
[23:46] <smspillaz> g_settings_set_value (v);
[23:46] <smspillaz> g_settings_reset_key (key);
[23:46] <desrt> so far so good
[23:46] <smspillaz> I did notice the documentation said that set_value consumes the reference
[23:47] <desrt> yup.  that's true.
[23:47] <smspillaz> okay, so actually I'll amend that example
[23:47] <smspillaz> (I just woke up)
[23:47] <desrt> maybe you should use a pastebin :)
[23:47] <smspillaz> v = g_variant_new_blah
[23:47] <smspillaz> desrt: you'll see all my wrapper code, it will make it kinda confusing
[23:48] <smspillaz> but, considering it a very thin wrapper, okay
[23:48] <desrt> smspillaz: you're the one that's confused :)
[23:48]  * desrt can probably dig through the layers
[23:48] <smspillaz> http://paste.ubuntu.com/1129829/
[23:48] <desrt> uh...
[23:48] <desrt> boost::shared_ptr<GVariant>?
[23:48] <smspillaz> uh ?
[23:48] <desrt> what is this magic? :)
[23:49] <smspillaz> it auto-unrefs the variant on destruction
[23:49] <smspillaz> that's probably where the problem lies if the reference is consumed hey
[23:49] <desrt> are you sure that it's aware of floating references?
[23:49]  * desrt guesses it's not
[23:49] <smspillaz> no, its very stupid
[23:49] <desrt> i bet that's where your bug is then
[23:49] <smspillaz> right, well, as long as it doesn't affect user code (I don't do this in user code)
[23:49] <smspillaz> but at least now I know the behaviour is correct
[23:50] <desrt> you're right.  i'm confused.
[23:50] <desrt> can you please produce a failing testcase in C?
[23:50] <desrt> so that we can rule out some c++ crack causing problems
[23:50] <smspillaz> desrt: it is the C++ crack :)
[23:50] <desrt> (which is still my leading theory at this point)
[23:50] <desrt> oh.  good.
[23:50] <desrt> problem solved :D
[23:50] <smspillaz> desrt: the failing test case at this point in c would be g_variant_new .. g_settings_set_value ... g_settings_reset ... g_variant_unref
[23:50] <smspillaz> as you mentioend earlier
[23:51] <smspillaz> so I guess as long as I ref it with the comment there its probably fine
[23:51] <desrt> maybe you should avoid mixing shared_ptr with floating refcounts
[23:51] <smspillaz> desrt: its only really for testing purposes
[23:51] <desrt> or do what vala does: wrap the call to the constructor with g_variant_ref_sink()
[23:51] <smspillaz> could work too
[23:53] <smspillaz> desrt: I'm assuming btw that GSettings isn't an implementation of some GInterface somewhere I can mock as well
[23:53] <smspillaz> so I'm okay in creating my own wrapper for testing purposes
[23:55] <desrt> nope.
[23:55] <smspillaz> I'm not okay, or its not an interface ?
[23:55] <desrt> you can implement your own backend, though
[23:55] <desrt> and there are some built-in backends that are useful for testing
[23:56] <smspillaz> right, there's the memory backend
[23:56] <desrt> ya.  that's a popular favourite.
[23:56] <smspillaz> although I actually wanted to mock out the object alltogether
[23:56] <desrt> ya.  you can't do that.
[23:56] <smspillaz> annnd why not ?
[23:56] <desrt> because it's not an interface
[23:56] <smspillaz> but is it sane if I wrap it in another object which *is* an interface ?
[23:56] <desrt> one thing you could do, though, is just write your own version of the API
[23:56] <desrt> with the same symbol names
[23:56] <smspillaz> right that's what I just did
[23:56] <desrt> that will work as long as you don't plan to use anything else in GIO
[23:57] <smspillaz> sure
[23:57] <desrt> which you're probably not doing...
[23:57] <desrt> just don't like -lgio
[23:57] <smspillaz> +!
[23:57] <desrt> *link
[23:57] <smspillaz> yep
[23:57] <smspillaz> its not the same symbol names but just a wrapper class
[23:57] <smspillaz> anyways
[23:57] <smspillaz> I'm assuming I'm fine
[23:58]  * desrt mumbles something about this being much harder than it should be
[23:58] <smspillaz> right, I remember I had to wrap it for some non-trivial reason
[23:58]  * ogra_ mumbles the same about life every day
[23:58] <smspillaz> like not noting to carry the burden of requiring a schemafile for tests and everything etc
[23:58] <smspillaz> *not having to
[23:58] <smspillaz> but I just woke up so
[23:58] <smspillaz> yeah
[23:58] <desrt> the non-trivial reason is that compiz resembles emacs
[23:59] <smspillaz> very funny
[23:59] <ogra_> it has a kitchen sink now ?