[resending to the list because i borked the address]
Hi Andreas and all,
Yesterday I fixed a longstanding bug in guile-gnome that prevented
automatic recognition of output arguments in many cases. This led to
more functions that needed to be written out as C, instead of using the
RTI system. It also brought out a bug, in which unwrap forms that depend
on static definitions only work in the module in which they are defined.
That is to say, I can unwrap GdkRectangle always within the gdk wrapset,
outside the wrapset in functions that use the RTI interface, but if a
function outside gdk has to inline unwrapping code, it fails to compile
because it can't reference the static definitions.
I see two solutions two this problem; one would be to fix the part of
guile-gnome that causes some unwrap forms to depend on static
definitions (those from `wrap-custom-boxed!'). This is a valid solution.
The other side of me thinks that inlining unwrap code into generated
functions is wasteful. It would be nice to be able to use RTI for
everything; as a side effect, we use G-Wrap's namespacing, not C's, and
we simplify code.
The major obstacle to using RTI is that the Guile implementation does
not support optional, out, or invisible arguments.
Invisible arguments (of which GError is the only example that I am aware
of) can be supported via calling unwrap_value() on UNSPECIFIED, and
having destruct_value() check to see if the value was set.
Out arguments can be supported easily; it's a question of checking a
flag, and if so, returning `values'.
Optional arguments are more difficult. You need default values, and
those have to be compiled into the C code, per-function. We can add them
when we are making the typespecs in the wrapset register functions, like
this:
static boolean arg2_default = TRUE;
const void *arg_defaults[1];
arg_defaults[0] = (void*)&arg2_default;
gw_add_function(..., arg_defaults)
Then the dynsmob_apply can dereference and copy over the defaults,
depending on the size of the value.
My battery dies, so I send this now. What do you think, Andreas? This
could simplify g-wrap considerably.
Regards,
Andy.
--
http://wingolog.org/
_______________________________________________
g-wrap-dev mailing list
g-wrap-dev@nongnu.org
http://lists.nongnu.org/mailman/listinfo/g-wrap-dev
