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

[Andreas Rottmann]

Andy Wingo <address@hidden> writes:

> 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.
>
No, the argument types are described in terms of libffi types in the
dynamic case:

struct _GWTypeInfo
{
    const char *name;
    const char *class_name;

    ffi_type *type; /* if non-NULL, this type may passed dynamically */
    
    GWFromScmFunc from_scm;
    GWToScmFunc to_scm;
    GWDestructorFunc destructor;
};

struct _GWFunctionInfo
{
    int dynamic; /* set if all arg types are dynamic and we should
                  * create the function dynamically. */
    
    void *proc;            /* Wrapper function (if !dynamic) or real C
                            * function */
    int n_required_args;
    int n_optional_args;
    int use_extra_args;

    GWTypeInfo *ret_type;
    GWTypeSpec ret_typespec;
    
    int nargs;
    GWTypeInfo **arg_types; /* array */
    GWTypeSpec *arg_typespecs;
    
    const char *proc_name;
    const char *generic_name;

    /* private */
    void *data; /* This is used for the dynamic-call info */
};


>>   * 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?
>
No, varargs are not support by libffi. As I said, those three
arguments are only meaningful for traditional wrappers.

> Also, does this allow optional args at the end in the sense of "int,
> default 1"?
>
That would be possible with libffi.

> 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?
>
It reduces the code produced, which can be a good thing. The current
vannilla g-wrap, for instance, duplicates the wrapping code in each
function and also duplicates stuff related to a type (e.g. ranges for
integer type limits) in each wrapset that uses the type, so for a
wrapset building upon another and using a lot of types from the other,
the win can be very high.

For example, the the C code generated has shrunk from ~140K lines to
~20K lines with runtime-wrappers for the GTK+ binding.

You can turn this feature on and off on a per-wrapset basis. It could
also serve as the basis for creating wrappers in pure scheme.

>> 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.
>
I now just pass the typespec to the type-specific functions
(e.g. scm->c), as done in vannilla g-wrap, too.

>> 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. 
>
Well, as already said before, I've reverted my opinion on this. The
marshaller is type-agnostic, all type-specific stuff is done in the
types' functions.

>> [0] maybe "runtime" vs. "compiled" is better than "dynamic"
>>     vs. "static" -- opinions?
>
> I like that (runtime/compiled) best.
>
I tend to agree.

> 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).
>
Cool!

> 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?
>
Hmm, I'd like to see the g-wrap issues sorted out first (gw-standard
duplication), however, this may take too long due to Rob being slow.

Regards, Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://www.8ung.at/rotty | GnuPG Key: http://www.8ung.at/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

Latein ist das humanoide Äquivalent zu Fortran.
   -- Alexander Bartolich in at.linux