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