Matt, further to the conversation today.
When you run the tests (make -C gobject check) you'll find it now
prints the descriptive message:
"GObject bind tests skipped: Int64, OInt64 and OStringList are all
broken"
That nicely sums up the first two problems.
(1) When I tested passing the full range of int64, it turns out to be
broken. There are probably two layers of brokenness, ie. Javascript
itself has broken integers as a design failure of the language, but
also I convinced myself at some point that something in GObject
truncates all integers to 32 bits. BTW also check it works on a 32
bit architecture.
(2) OStringList: IIRC I added this type to the generator but was
unable / didn't have time to add it to the GObject bindings.
(3) Stability of the API: GObject doesn't understand the
once_had_no_optargs feature of the generator, which means that
converting a no-optargs call to an optargs call (which is now
permitted) will break the GObject API. You may or may not care about
this.
(4) Coverity found a potential bug in header inclusion. It seems that
GObject headers recursively include themselves. Both Ondrej and I
tried different approaches to fixing this but were unable to make it
work.
(5) I heavily refactored the code in generator/gobject.ml. Although I
checked that the output of the generator didn't change, you might also
want to check those commits for sanity.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top
