Matthias Clasen (matthias) Kristian Rietveld (kris) Torsten Schoenfeld (kaffee) Johan Dahlin (jdahlin) Behdad Esfahbod (behdad) Tim Janik (rambokid) Federico Mena Quintero (federico) Jonathan Blandford (jrb) Jan 03 21:13:14 --> You are now talking on #gtk-devel Jan 03 22:01:53 ok, lets start Jan 03 22:02:43 hello Jan 03 22:02:47 aloha Jan 03 22:05:21 hi Jan 03 22:05:24 salam Jan 03 22:05:43 so, beyond the perl bindings, did we find other things that will be broken by the current state of floating flag support ? Jan 03 22:07:01 well, the better question would probably be: do we know that no other things will break? Jan 03 22:07:17 I know that pygtk will continue to work. but what about the other bindings? Jan 03 22:07:55 thats probably a question best asked on the bindings list Jan 03 22:08:18 true. Jan 03 22:08:23 * mclasen goes asking Jan 03 22:09:39 * kaffee is writing a response to rambokid's mail right now, by the way. Jan 03 22:14:26 ok, regardless of the final outcome of this, I want to do a glib release in the next few days. Do we have any outstanding api things to fix before that ? Jan 03 22:15:38 mclasen: i don't think so. and, didn't we say we're API frozen at this point? Jan 03 22:16:01 rambokid: I think we agreed to do an api frozen release early in january. Jan 03 22:16:08 that hasn't happened yet... Jan 03 22:16:16 mclasen: on "new years eve" to eb exact. Jan 03 22:16:55 mclasen: huh? that is not the impression i got from the last meeting. want me to dig it up and quote you? Jan 03 22:17:15 no Jan 03 22:17:28 ok ;) Jan 03 22:17:42 be nice to eachother ;) Jan 03 22:18:58 I'd actually like the API freeze to be extended a bit until the GInitiallyUnused issue is settled. Jan 03 22:19:08 (which I think it isn't.) Jan 03 22:19:34 err, make that GInitiallyUnowned. (Freud'ian typo?) Jan 03 22:24:47 kris, how is the async branch looking ? Jan 03 22:26:04 pretty okay Jan 03 22:26:11 I would like some people to look at it/test it Jan 03 22:26:35 federico would be the natural reviewer candidate, but he is not here... Jan 03 22:26:58 yeah Jan 03 22:27:09 he's been wanting to look at it for a week or two/three now Jan 03 22:27:13 but he's really busy Jan 03 22:27:28 --> jdahlin (~jdahlin@200-171-140-32.dsl.telesp.net.br) has joined #gtk-devel Jan 03 22:28:28 kris: its not that urgent, is it ? if federico doesn't find time in the next few weeks, I can take a look at it. Otherwise, I'd rather let federico review it Jan 03 22:29:08 ok; Jan 03 22:29:27 though we really want to ensure that it gets proper testing before we release stable tarballs of gtk+2.10 Jan 03 22:30:59 --> federico (~federico@201.137.148.211) has joined #gtk-devel Jan 03 22:31:01 la la la Jan 03 22:31:16 hey federico Jan 03 22:32:05 are we discussing the glib api freeze? Jan 03 22:32:12 there's no gslice debugging fu Jan 03 22:32:43 federico: does that need api, beyond an env var ? Jan 03 22:34:18 ok, since we were speaking about branches, I wonder what we should say wrt to the direct-fb backend that has recently been proposed again Jan 03 22:36:53 mclasen: an couple env vars are probably fine. In the future I'd probably like some debugging functions like list_all_slices_and_allocated_blocks(), or some valgrind hooks Jan 03 22:37:19 mclasen: you could say that an env. var is part of the API :) Jan 03 22:37:23 what's the use case for that? and what would valgrind hooks do? Jan 03 22:38:25 federico: i don't think we should consider debugging env vars parts of the essential API that we need to get frozen for a timely release schedule. Jan 03 22:38:38 rambokid: "how much memory got allocated? how many magazines are free/full/half? how much memory could I release by freeing magazines?" Jan 03 22:39:17 rambokid: rlove and I are wondering about an AIX-like SIGLOWMEM - you'd release full magazines if the kernel signals you Jan 03 22:39:45 yeah, we had an email thread on that. Jan 03 22:43:36 anyway, we can keep doing that in HEAD. Jan 03 22:43:46 federico: will you be able to review kris' async branch sometime in the near future ? Jan 03 22:43:48 rambokid: in the meantime, do you have time to do the env. vars for valgrinding? Jan 03 22:43:54 mclasen: yeah, I want to do that soon Jan 03 22:44:30 federico: i hope to find time for the env vars during january Jan 03 22:45:01 rambokid: awesome - we really need that for valgrinding evolution :) Jan 03 22:45:15 ok, I'll have to leave in a few minutes Jan 03 22:46:21 I expect to do a glib release later this week; I'll announce it as basically api-frozen except for the floating discussion Jan 03 22:46:52 oh, what's up with that? I haven't read the newest mails Jan 03 22:47:13 basically, it makes us Perl guys unhappy. Jan 03 22:47:27 kaffee: does your code break? Jan 03 22:47:39 because we break if a previously known type suddenly has an unknown parent. Jan 03 22:47:51 i.e. you had code that worked with glib 2.8 - does it break with glib HEAD? Jan 03 22:48:04 yeah, every non-trivial gtk2-perl program will break is gtk+ is updated under our arse. Jan 03 22:48:14 s/is gtk+ is/if gtk+ is/; Jan 03 22:48:24 glib you mean Jan 03 22:48:34 no, the change in gtk+ breaks us. Jan 03 22:48:44 GtkObject inheriting from GInitiallyUnowned. Jan 03 22:49:18 yeah, you need glib-2.9 for that though. Jan 03 22:49:28 rambokid: could you be convinced to not have sinkability in glib at all? it's bad API practice. Jan 03 22:49:39 rambokid: true. Jan 03 22:50:17 federico: i think you want to turn to gtk-devel-list and read the last 2 month of discussing this. Jan 03 22:50:44 ok Jan 03 22:50:54 I still think sinkability is a bad idea :) Jan 03 22:51:24 bye Jan 03 22:51:28 <-- mclasen has quit (Leaving) Jan 03 22:51:37 rambokid: I must admit, the last two months of gtk-devel-list seemed to be people disagreeing with you that it was a good idea Jan 03 22:52:17 jrb: wrong, there were lots of misunderstandings tehre, and i adressed ever concern raised at least once. Jan 03 22:53:46 I just sent a reply to your mail, rambokid, and I think it contains a point that you haven't adressed yet. Jan 03 22:54:30 jrb: I think quite a few people think it's good to have the floating stuff somewhere in GLib. many aren't happy with the implementation though, it seems. Jan 03 22:55:49 kaffee: as i outlined in my reply to you. even if we don't have GInitiallyUnowned, your logic is likely to break in the future, because we may very well introduce other parent types. Jan 03 22:56:14 basically, the glib type system is too dynamic to properly work with, if you do not support lazy type registration. Jan 03 22:56:46 new parent types may as well be introduced between gtkwidgets for instance. Jan 03 22:56:48 in my new reply, I outline why lazy type registration is neither reliable nor extensible. Jan 03 22:57:16 without exposing GType to the programmer. Jan 03 22:57:26 no you didn't. you just said the original perl maintainers thought it'd be improbable for reasons you didn't outline. Jan 03 22:57:54 well, I mentioned the name mangling and prefix guessing that would be needed. Jan 03 22:58:04 what do you mean with not exposing GType to the developer? Jan 03 22:58:47 i don't know what you mean by neccessar yname mangling and prefix guessing. maybe it'd be worth outlining those concerns then. Jan 03 22:59:37 well, if you don't specify the GType to Perl package name mapping manually, you have to use heuristics that mungle g_type_name. Jan 03 22:59:54 which is what pygtk does, and which is what we think isn't reliable. Jan 03 23:00:28 the strip common prefixes and use the remainder as the class name, basically. Jan 03 23:00:57 but how would that work gobject-based libraries that use completely different prefixes? Jan 03 23:01:50 kaffee: glib, gdk and gtk type names follow strict conventions. if you can't properly convert them, please outline the problems you encounter so we can solve that issue for you (in an email to gtk-devel-list would be best). they are meant to be reliably convertible (.e. into g_foo_bar variants) Jan 03 23:01:59 kaffee: manually Jan 03 23:02:23 introspection will solve this anyway. Jan 03 23:03:09 rambokid: ok, will try. Jan 03 23:03:22 kaffee: ok, thanks. Jan 03 23:03:59 but still, the main point really is that old and current versions of our bindings will break. Jan 03 23:04:20 jdahlin: true. Jan 03 23:05:45 <-- jdahlin has quit (Ex-Chat) Jan 03 23:05:52 kaffee: right, but a perl binding upgrade will be able to fix that. not having sinking in glib most probably leads to much unfixable breakage though. and as i outlined in email, we can put a prominent release note to make distributors aware of this. Jan 03 23:07:30 yeah, and if you really can't be convinced, then that's the way to go. but I don't buy the argument that not adding sinking functionality to glib now will lead to bugs -- people have been surviving for years without it. Jan 03 23:08:28 and we're not even arguing against adding sinking to glib. we just want GtkObject to not change parents. Jan 03 23:08:45 and with ref counting bugs and complicated API, that is my point. the results of that are just long term effects so harder to see. Jan 03 23:09:16 kaffee: i'll say it again, you need to prepare for parent changes in the hierarchy anyway. Jan 03 23:09:51 lets discuss the rest in email, so we can close the meeting ;) Jan 03 23:10:17 ok Jan 03 23:10:45 thanks, i'll put up the logs then.