GNOME Bugzilla – Bug 571373
typelib 1.0 finalization
Last modified: 2015-02-12 20:21:54 UTC
We should finalize the 1.0 version of the typelib, as part of declaring g-i stable. Things to check/do: * Go through the bug list, ensure we've added what we need to the typelib now, or at least allocate space for it * Padding in all typelib members where it makes sense, for things we haven't thought of yet * Do we support custom key/value annotations well? (This is another extension avenue) I'm working on a structure padding patch, ensuring we have at least 8 bits for flags, and 16 bits for a string pointer (which could be an indirection to a new directory block with another arbitrary data chunk).
My first patch here is going to move typelib-format.txt inside gtypelib.h. This will make sure it's up to date and make it more obvious which members aren't documented.
Created attachment 128509 [details] [review] Bug 571373 - Move typelib docs from typelib-format.txt into girepository.h typelib-format.txt was growing out of date; a good solution to this is to move it closer to the code it's documenting. By doing this we also gain the ability to use gtk-doc on it.
Created attachment 128524 [details] [review] Bug 571373 - Consistently use sizeof () inside gtypelib and girmodule This not only makes it easier to change these structures, it becomes clearer exactly what each magic number is just for reference.
Created attachment 128525 [details] [review] Bug 571373 - Remove hardcoded offsets in ginfo.c In a few places we had hardcoded sizes for accessing structure members and computing into variable size arrays. Remove those.
Created attachment 128526 [details] [review] [WIP] Bug 571373 - Remove hardcoded sizes/offsets in girnode.c [This patch is not yet complete] Where appropriate we now use G_STRUCT_OFFSET and sizeof() instead of hardcoded integers.
I've double checked the first two and I believe they're correct. This last one I went through hunk by hunk and double checked, but while working on this patch I hit some things that are either bugs or I don't grok yet, denoted by /* SIZEOFFIXME */ Going to attack the FIXMEs soon and sort them out.
Created attachment 128568 [details] [review] Bug 571373 - Remove hardcoded sizes/offsets in girnode.c Where appropriate we now use G_STRUCT_OFFSET and sizeof() instead of hardcoded integers. Add comments for some special cases.
Created attachment 128589 [details] [review] Bug 571373 - Increase the size of ObjectBlob and InterfaceBlob Since there aren't many of these relatively, we add two full guint32s.
Created attachment 128590 [details] [review] Bug 571373 - Increase the size of StructBlob, UnionBlob, EnumBlob All of these get two full guint32, because while they're more common than ObjectBlob, they're still not that many.
Created attachment 128591 [details] [review] Bug 571373 - Increase the size of VFuncBlob, PropertyBlob, SignalBlob All of these get one word each, since they are more common than ObjectBlob.
Created attachment 128592 [details] [review] Bug 571373 - Increase the size of FieldBlob and ConstantBlob One guint32 for each of these.
Note that these padding increases took Gtk.typelib (one of the larger typelibs) from 442472 bytes to 458760, i.e. just a 3% increase. Not surprising considering most of the data is probably strings.
Before freezing the 1.0 format we should decide how to handle custom annotations in the typelib. Which blobs should support annotations? how many annotations should be supported by blob?
For custom annotations see bug 571548 (this one depends on it)
Comment on attachment 128509 [details] [review] Bug 571373 - Move typelib docs from typelib-format.txt into girepository.h There's a special syntax you can use to get the documentation gtk-doc. I would be great if you could use it to get everything in there. Yes, I plan to move most parts of documentation on the wiki over to gtk-doc when I can find time and motivation to do so.
Comment on attachment 128590 [details] [review] Bug 571373 - Increase the size of StructBlob, UnionBlob, EnumBlob Squash the relevant size changes with the other patch, so we'll be bisectable.
Comment on attachment 128591 [details] [review] Bug 571373 - Increase the size of VFuncBlob, PropertyBlob, SignalBlob >--- a/girepository/gtypelib.c >+++ b/girepository/gtypelib.c >@@ -179,9 +179,6 @@ g_typelib_check_sanity (void) > CHECK_SIZE (RegisteredTypeBlob, 16); > CHECK_SIZE (StructBlob, 32); > CHECK_SIZE (EnumBlob, 24); >- CHECK_SIZE (PropertyBlob, 12); >- CHECK_SIZE (SignalBlob, 12); >- CHECK_SIZE (VFuncBlob, 16); > CHECK_SIZE (PropertyBlob, 16); > CHECK_SIZE (SignalBlob, 16); > CHECK_SIZE (VFuncBlob, 20); Looks wrong too, should ideally be bisectable.
(In reply to comment #17) > (From update of attachment 128591 [details] [review] [edit]) > >--- a/girepository/gtypelib.c > >+++ b/girepository/gtypelib.c > >@@ -179,9 +179,6 @@ g_typelib_check_sanity (void) > > CHECK_SIZE (RegisteredTypeBlob, 16); > > CHECK_SIZE (StructBlob, 32); > > CHECK_SIZE (EnumBlob, 24); > >- CHECK_SIZE (PropertyBlob, 12); > >- CHECK_SIZE (SignalBlob, 12); > >- CHECK_SIZE (VFuncBlob, 16); > > CHECK_SIZE (PropertyBlob, 16); > > CHECK_SIZE (SignalBlob, 16); > > CHECK_SIZE (VFuncBlob, 20); > > Looks wrong too, should ideally be bisectable. Hmmm, thanks for catching that; it looks like a bad merge. Anyways I'll squash the size cahnges together. Regarding comment #15 can you tell me what you saw that isn't valid gtk-doc right now?
There's a SECTION directive in gtk-doc, so you can make all comments you wrote show up in the HTML.
Ok, I fixed these up for comments and committed them all. Leaving this bug open for any new issues we might find before finalizing the typelib.
Seems like this should be closed as fixed?
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]
(In reply to Colin Walters from comment #20) > Leaving this bug open for any new issues we might find before finalizing the > typelib. This bug report been open for any new issues for about six years now. I think we can safely assume it can be closed. If not, please feel free to reopen :)