Changeset: Dynamic types [long]

[Andreas Rottmann]

[ CC'ing guile-gtk, because some parts are relevant for guile-gobject,
  too. In general, IMHO, people interested in guile-gobject
  development should also join g-wrap-dev, since these projects are
  quite tightly coupled at some spots.

  First of all, I re-announce the tla commands for accessing my g-wrap
  branch (see also
  http://mail.nongnu.org/archive/html/g-wrap-dev/2003-11/msg00003.html).

  tla register-archive address@hidden 
http://stud3.tuwien.ac.at/~e9926584/arch/2003-main
  tla get address@hidden/g-wrap--rotty--0.2 g-wrap

  This will create a directory named g-wrap, containing the
  source. Use autogen.sh as usual. ]

Finally, here is the *big* changeset. It might be that a changelog
entries misses for some changes to g-wrap.scm; I did my best, but
there are lots of changes, and I did changelogging, opposed to my
normal habits, after doing the changes, not while hacking on them.

Anyway, the show-changeset output is attached. Highlights include:

* Improvements in the size of the generated code:
  - By not checking the error code that often 
    (e.g. for procedure creation).
  - By factoring out code into a runtime library (e.g. enum wrapping)
  - By the "dynamic" type feature (outlined below)

* Dynamic type feature: There is a new function
  'gw:wrap-dynamic-type', that has a simpler (and less general)
  interface than 'gw:wrap-type', but allows the vast majority of
  types, incluing simple and wct types to be described - both are now
  automatically created as dynamic types. For simple types, the
  wrapper function needs an extra argument containg the ffi type name
  (e.g. pointer, sint, uin64, ..). Things that can not yet be dynamic
  types include Glists (require nested typespecs) and GError (requires
  argument hiding).

  OK, now what does this all gain us? Functions functions only having
  dynamic type arguments and return type can be called dynamically,
  via libffi. This means we don't _have to_ (though we still can)
  produce a C wrapper function for these functions anymore! This is a
  huge gain for the GTK+2 wrappers, for instance - it makes the code
  shrink from ~140K lines to ~22K lines. gcc 3.3.2 can't really cope
  with such a big file with -O2 turned on, even on a reasonable
  machine.

  Furthermore, this means we don't need to spit out code for types
  that are in another wrapset we depend on, iff those are dynamic and
  not used in non-dynamic functions, since the depended-on wrapset
  already has it - we only need to look the type up in there. For
  details refer to g-wrap-runtime.c, mostly.

* GOOPSiness of wrappers increased: you can specify a class name for
  each wrapped type and a generic name for each function. g-wrap will
  automatically generate specialized generics in applicable cases.

My changeset posts up to now, icnlduing this one, contain all
changes i've made to g-wrap so far. On my to do list are:

* Making news entries (take the above as a start) for my changes and
  documenting them (which would include updating the existing docs,
  which I am not really keen on - any takers for that one?)

* completing the transition to generating/using code that is not
  deprecated in Guile 1.7 but runs on both 1.6 and 1.7 (do we really
  want to keep support for 1.4? My changes almost certainly break on
  1.4...)

* Sketching out the further route for g-wrap to go. I'd like to make
  g-wrap itself use GOOPS (it already supports GOOPSy wrappers up to a
  degree with my changes). We should thus come up with some design for
  g-wrap's architecture; how it looks like now, including things that
  should be cleaned up; what changes we need to make the design
  cleanly expressable using GOOPS classes/generics; what changes we
  need for the C-as-scheme expression changes Rob has in mind; how
  this relates to the h2def.py tool guile-gobject uses (we can
  probably suck that into g-wrap or rewrite it using the proposed
  C-code parser).

0.2-patch-3.changes
Description: Text document

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

Say NO to Software Patents! -- http://petition.eurolinux.org/