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

[Andreas Rottmann]

Rob Browning <address@hidden> writes:

> Andreas Rottmann <address@hidden> writes:
>
>> [CCing Rob, as I don't know if he's on the new list already]
>
> Actually I'm not yet (so please cc me), but I'm about ready to try and
> answer a number of messages (including yours) that have been pending
> for a while, and also expound on some (possibly wrong-headed) ideas so
> others can help me tell whether or not they have any merit.
>
> ...but *before* I do that, I wanted to figure out *where* I should do
> that.  It seems like a separate g-wrap list might be the best idea,
> but then again, it'd be nice not to have to administer a new list, and
> it may well be that guile-gtk is (and will be) the primary customer
> for now.
>
Hmm, administering a mailing list isn't really a big hazzle, if it's
hosted on savvannah, /methinks. I also like the idea of a separate
mailing list for g-wrap.

About the glueless code's status: I've been hacking on this quite lot
the last days, and have arrived at a point where I have the code
working to a certain extent. Typespecs are not yet implemented, but I
had up to now not really needed them (as I only made all simple-types
dynamic as well as the wct stuff). For the benefits that this approach
can offer (as far as I've seen up to now):

* Avoid creating huge amounts of C glue code (e.g. for GTK+) (this was
  my primary goal)

* Avoid spitting out glue code already in a wrapset that we depend on,
  as the dependend-on wrapset's code can be re-used.

What it costs:

* More data must kept around at runtime to marshall
  arguments/retvals. I hope this one is compensated by reducing code
  size.

* The invocation of a wrapped procedure is probably slower, but I
  don't think this will very matter much; it works like this:
  - The former procedure (gsubr) now is a applicable smob
  - The sombs apply function receives all arguments and has a 
    pointer to information about the function (and its argument 
    types/return type). It uses this info to marshall all its 
    argument from SCM to C by invoking the arguments types 
    conversion function. ATM the data is marshalled to a 
    per-function area on the heap, so this is not yet thread-safe.
    Then the function is invoked via libffi, and reverse marshalling is 
    done for the return value.

* The marshalling model is very simple at the moment and can not cope
  yet with in-out C arguments and similiar stuff. All types that can
  not yet be marshalled are wrapped using the conventional technique.
  I intend to step-by-step increase the complexity of the marshalling
  model to accomodate at least all that GTK+ 2.0 needs.

Note that the user of g-wrap can decide not to use dynamic calls on a
per-wrapset basics. The only overhead then is the additional
information, which is created nevertheless, since depending wrapsets
may need it.

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

Python is executable pseudocode, Perl is executable line-noise.