Re: [g-wrap] Changes needed by the "glueless" approach

[Andy Wingo]

On Wed, 15 Oct 2003, Andreas Rottmann wrote:

> [CCing Rob, as I don't know if he's on the new list already]

Get on the list! (maybe we can sucker you into guile-gtk development,
too ;)

> So far I've got this information to be stored:
[...]
> - For each function:
[...]
>   * proc void *: either normal wrapper (accepting SCM values) -- this 
>     is what I call static wrapper -- or the pointer to the 
>     to-be-wrapped C function in the dynamic case.

Does this take GType ids for some arguments? It would make sense for the
argument list to be prototyped as ("GObject of type GtkTreeView", "Boxed
of type GtkTreeIter", ...) -- the glue code is the same, the ABI is the
same, it's only the dynamic type-checking that's different.

>   * number of {required, optional} args + if we use the 
>     extra args list (only relevant for the static wrappers)

Ooh! Does this allow varargs? Of course the varargs have to be
structured (e.g. "a list of strings", "a list of string-SCM pairs").
Dunno how possible this is. Can you call varargs functions from libffi?

Also, does this allow optional args at the end in the sense of "int,
default 1"?

BTW. gcc (GCC) 3.3.2 20030908 (Debian prerelease) compiles things fast
for me now, no more 10 minutes waiting for an OOM kill. What are you
doing this for, anyway?

> At this point, I wonder about what to do with typespecs -- those
> describe additional properties of a type (e.g.  that it's caller-owned
> for a char *) and can vary from argument to argument. It is clear that
> we need typespecs at the marshaller level, too. This means we have to
> convert them to a C bit field or something like that.

Yeah. It would still be OK to have a static array of argument info (hey,
think of them like GParamSpecs) in the wrapper lib, and a pointer to
this param-spec data is passed to the marshaller to e.g. verify the
proper GType of a GObject* pointer.

> My impression reading the code was, however, that the c->scm, scm->c
> and c-destructor ccgs are only used internally by the type wrapper
> implementations and it should be thus be possible to change their
> semantics so that they don't require a typespec.

Should be, but I'm not one for g-wrap design issues. 

> [0] maybe "runtime" vs. "compiled" is better than "dynamic"
>     vs. "static" -- opinions?

I like that (runtime/compiled) best.

Unsolicited opinions abound from Mr. Wingo! I'm going to get back to
making our TextView/Buffer/Iter/... wrappers work properly (Tree* seems
to work fine now).

I want to release after I get guile-gtk-demo in to CVS (should happen by
the time you see this mail), any way that could be possible, Marius?

Regards,

wingo.