Meeting on irc.gnome.org:#gtk-devel
Meeting started May 17 2005 16:02 EDT


In attendence: 

Matthias Clasen (mclasen),
Jonathan Blandford (jrb),
Maciej Katafiasz (mathrick),
Johan Dahlin (jdahlin),
Owen Taylor (owen),


<mclasen>	ok, I didn't post an agenda
<mclasen>	but I think we could talk about the current state of the introspection stuff
<mclasen>	(sorry about the UTC mess-up, btw)
<mclasen>	jrb: did you get a "working binding" going ?
<jrb>	mclasen: jdahlin did, but he's a code horder
<jrb>	mclasen: and he won't let me play with his toys
<mathrick>	heh
<mathrick>	does current spec allow for any sort of default argument specification?
<mathrick>	it doesn't seem so
<mclasen>	mathrick: no, it doesn't
<mathrick>	mclasen: that's gonna be needed
<mathrick>	and python's keyword arguments will be fun, as jdahlin said
<mclasen>	mathrick: I don't see why keyword arguments are particularly relevant to binding a C library
<mathrick>	mclasen: are you familiar with python's positional vs. keyword aguments distinction?
<mathrick>	mclasen: it is
<mclasen>	I mean, there are no keyword arguments in C, so it should be possible to do a binding without introducing them
<jdahlin>	jrb: I'm not a horder any longer, it's all in cvs
<mclasen>	mathrick: I assume they're similar to keyword arguments in lisp/scheme dialects...
<mathrick>	mclasen: there's 3 possible argument classes, actually
<jdahlin>	mclasen: what I have working is module, class and method generation, working on invokation
<mathrick>	mclasen: positional, keyword, and additional keyword
<jdahlin>	I have a couple of things on my wishlist
<mclasen>	mathrick: additional is like rest ?
<mathrick>	mclasen: like, def some_func(arg1, arg2, arg3, *args, **kw_args)
<jdahlin>	mclasen: a global registry, which we talked about a couple of days ago
<jdahlin>	mathrick: we can ignore * and ** since the introspection doesn't support that
<mathrick>	mclasen: yes, but there's also *args, which is like rest, and **kw_args, which is variable, but contains dict of keyword -> value mapping
<mathrick>	jdahlin: well, question is, can we do that
<jdahlin>	* is similar to va_list in C, ** is similar, but you receive the arguments in a hash table
<mathrick>	jdahlin: at least * is interesting for variac args
<mathrick>	s/variac/variadic/
<mclasen>	we're not going to support variadic functions in the metadata, I think
<mathrick>	mclasen: **kwargs is useful for example in here: http://pygtk.org/pygtk2reference/class-gtktreeviewcolumn.html#method-gtktreeviewcolumn--set-attributes
<mathrick>	we should at least get some useful convention
<jdahlin>	mclasen: default arguments is also high on the wishlist
<mathrick>	func("name", val, "name2", val2, NULL) seems to be established mapping for that
<mclasen>	default arguments may be a good testcase for annotations
<jdahlin>	glade_xml_new is a good example for that, you usally send in NULL on at least one of the arguments
<mathrick>	mclasen: yeah
<mathrick>	mclasen: I'll get typed anno proposal ready tomorrow, if nothing bad happens
<owen>	mathrick: GTK+ never uses that for keyword arguments where the keywords are part of the API
<mathrick>	owen: yes, that was meant for **kwargs mapping into C
<mathrick>	owen: which are by definition unknown
<owen>	mathrick: I don't think mapping g_object_new() to keyword arguments in the intropsection data makes sense
<mathrick>	owen: hmm>
<mathrick>	?
<mathrick>	owen: I didn't get you
<owen>	mathrick: That's the kind of thing that has to be done by hand... the introspection data can't handle *everything* that you might want to do in an ideal language binding
<mathrick>	owen: nah, compare gtk_tree_view_column_set_attributes () with gtk.TreeViewColumn.set_attributes()
<owen>	mathrick: Not sure what you are arguing
<mathrick>	owen: there's very clear mapping of dict (**kwargs) into "keyword", value..., NULL pairs
<owen>	mathrick: You are missing the fact that the *type* of the value needs to be determined at runtime, by a method specific to the interface
<mathrick>	owen: hmm
<owen>	mathrick: That seems overambitious for introspection to encode
<jrb>	(it is awfully convenient, though)
<mathrick>	owen: jrb is right :)
<owen>	mathrick: I think we are assuming that language bindings will frequently add a bit of convenience API over what we can introspect
<jdahlin>	I agree with owen, it's not so difficult to do this in language bindings
<mathrick>	owen: dunno, if function is truly variadic, it's gonna have to validate input itself anyway
<mathrick>	jdahlin: you mean hand-crafted?
<jdahlin>	We'll always require extra glue/integration for each language
<owen>	mathrick: If this sequence of bytes on the stack is a not a pointer to a GObject, then return an error?
<owen>	mathrick: How are you going to implement that?
<mathrick>	humm
<mclasen>	so, coming back to default values. Does it sound reasonable to do them as annotations, or should we add them to the core metadata ?
<mathrick>	mclasen: annotations sound fine
<owen>	mclasen: is annotation lookup going to be constant time?
<owen>	what's the tradeoff one vs the other?
<jdahlin>	what kind of annotations?
<mclasen>	owen: bsearch
<jdahlin>	sorry, I must have missed something.
<jrb>	what default values are we thinking of encoding?  Are we doing anything other than NULLs?
<owen>	mclasen: blech
<owen>	mlcasen: default values need to be looked up every time that you invoke a function. Though I suppose you could cache the pointer to the annotation...
<mclasen>	owen: alternatively, store a direct link to the annotations in each blob
<mathrick>	owen: yeah, it should be cacheable
<mclasen>	or simply make default values part of the argblob
<owen>	mclasen: if we using annotations for things that are needed invoke time, then I think they need constant-time lookup. If they are only used for "documentation", then it doesnt' matter
<mathrick>	jdahlin: what's the current strategy of pybank, does it def methods for introspected functions, or looks them up at invoke time?
<jdahlin>	mathrick: currently it does it at creation time, I can't see why it shouldn't
<jdahlin>	class creation time
<mathrick>	jdahlin: ok, so we can easily cache default values
<mathrick>	I suppose other dynamic languages can do that too
<mclasen>	owen: if we are really serious about constant-time lookup going from function name -> call, we need hashes to look up functions, in addition of the current arrays
<mathrick>	mclasen: dunno, are there any languages so dynamic that they couldn't cache that info?
<owen>	mclasen: bsearch might be OK for initial lookup if it's cacheable.  But I could imagine spending a lot of time bsearching for a larger program
<mclasen>	owen: bsearching would require to sort the entries in the directory/functions in an interface. We don't do that currently
<owen>	mclasen: Linear scan? Hmm. I think it's unpleasant if you have to populate the entire interface the first time you hit any function in it.
<mclasen>	owen: so we should probably sort the arrays
<owen>	mclasen: either that or add a hash table
<mclasen>	...or both
<owen>	or both
<mclasen>	would that be a single hash table, or one per interface ?
<mclasen>	There are two lookup operations
<mclasen>	1. find an interface/function in the blob
<mclasen>	2. find a function in an interface/object
<mclasen>	currently you have to loop over the directory for the first, and loop over the list of functions in an interface for the second
<owen>	You could argue either way. You need the interface blob in any case to do anything with the function blob, so a single hash table lookup to get to the funcion blob doesn't help?
<mclasen>	owen: there is g_base_info_get_container() which allows you to get the "containing" blob, so in theory you can navigate back from the function info to the interface 
<mclasen>	but it is going to be a challenge to make that work when directly jumping to the function blob
<mclasen>	since there is no "parent" link in the metadata
<owen>	How do you even know how to look up the function blob? You'd have to have the interface name to look something up in the global hash table
<mclasen>	you would probably have to use a qualified name like Gtk.Widget.show, not just show
<owen>	What I'm sayting is that you already have the Gtk.Widget class object before you check to see if it has a show method
<owen>	So, the only real justification for a global hash table wwould be if it was more compact or convenient in the metadata format
<mclasen>	ok, so I want to work on implementing the struct layout pieces of the metadata in the parser this week
<mclasen>	(as an excuse for not looking into the scary scanner task...)
<mclasen>	Do we have a good idea for generating the struct offset information at build time ? Keeping arch-dependent xml files around for all arches is clearly suboptimal
<jrb>	mclasen: we could define the entire struct in order and imply the offsets from that
<owen>	I think you have to include everything that could influence struct packing
<jrb>	mclasen: though it sounds a little fragile
<owen>	all the field types and any nesting in the structure
<mathrick>	mclasen: one sucky idea is to generate structs field-by-field and print sizeof()
<mathrick>	will be slow as hell with gazillion of gcc invocations
<mclasen>	one could try to generate code which uses G_STRUCT_OFFSET a lot...
<mathrick>	yes
<owen>	mathrick: the logic for determining struct offsets for different architecutres isn't *that* complex. I think ORBit has it
<mathrick>	doesn't libffi do part of that too?
<mathrick>	it has sucky docs for sure
<mathrick>	owen: if we can steal from ORBit, it's good. We will need to have it for dynamic languages anyway, come to think of it
<mclasen>	mathrick: All structures must have type set to FFI_TYPE_STRUCT.  You may set
<mclasen>	size and alignment to 0. These will be calculated and reset to the
<mclasen>	appropriate values by ffi_prep_cif()
<mathrick>	but inside compiler-generated C code, we can simply use G_STRUCT_OFFSET
<owen>	mathrick: Well, the point of including it in the intropsection is os that dynamic languages *don't* have to calculate
<jrb>	mathrick: wouldn't that require the header, and defeat the purpose (er, what owen said)
<mathrick>	owen: depends on how much of infrastructure we want to put inside core introspection
<mathrick>	and how much to delegate to bindings
<mclasen>	jrb: the idea with G_STRUCT_OFFSET would be to generate code at build time which uses G_STRUCT_OFFSET to dump the offsets
<jrb>	mclasen: ah -- I thouht mathrick was proposing to use it in conjunction w/ introspection in the bindings
<mathrick>	no, only at build time
<mclasen>	ok, I'll have to leave soon
<mclasen>	i'm currently trying to get through the unmilestoned bugs, btw
<mclasen>	help with triaging them would be welcome
<owen>	Help clearing off some of the milestoned bugs would be appreciated to, of course.
<owen>	We're past 1100 total and not looking back...
<mclasen>	is that including enhancements ?
<mclasen>	the number on the "last weeks bug activity" report is more like 900 
<owen>	mclasen: Yes. That's everything.
<owen>	Most of those 900 are enhancemnts too, of course


Meeting ended May 17, 17:26 EDT