[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile-gobject/g-wrap status update
From: |
Andy Wingo |
Subject: |
Re: guile-gobject/g-wrap status update |
Date: |
Thu, 9 Oct 2003 18:14:02 +0200 |
User-agent: |
Mutt/1.5.4i |
On Mon, 06 Oct 2003, Andreas Rottmann wrote:
> Hi!
Hi! I was wondering what you were up to ;)
> [BTW: There seem to be two guile-gtk mailing lists ATM - I guess
> people should migrate to the one at GNU...]
Please do.
> I'm ATM working at implementing "glueless" wrapping for g-wrap,
> i.e. instead of using a dedicated C wrapper for each wrapped function
> creating an applicable smob that invokes a general marshaller which in
> turn calls the C function via libffi.
Sounds neat! I wonder, though. What advantages does this have? I suppose
the memory requirements will be lowered (I see libguile-gnome-gw-gtk.so
is 50% bigger than _gtk.so from python). Are there speed increases? I'm
really worried about speed right now. I suppose this will (at some
point) allow applications to dynamically call C functions for which
wrappers have not yet been generated, but speed (not memory footprint)
is really the pressing area right now.
Also I see in the manual, under the low-level dynamic linking chapter,
this:
There is, however, another possibility to get a more thorough access
to the functions contained in a dynamically linked library. Anthony
Green has written `libffi', a library that implements a "foreign
function interface" for a number of different platforms. With it, you
can extend the Spartan functionality of `dynamic-call' and
`dynamic-args-call' considerably. There is glue code available in the
Guile contrib archive to make `libffi' accessible from Guile.
Just so we know!
Anyway, good luck. But what I'm really concerned about right now is
speed in guile-gtk. I'm busy atm wrapping the TreeView/Model/...
properly and hacking out some Marlin bindings (rock!), but I hope
someone really tears into GOOPS to see where the slowness is coming
from.
Ah, so many good things in guile these days! Advanced wrapper libraries,
nice Gnome/gtk/... bindings, threading in the core of HEAD guile...
But we need to expand mindshare of guile programming so we get more
quality hackers. I think the faster we get out some usable Gtk 2
bindings, the more feasible it will be for people to use guile in big
projects. So let's get to work, kids.
Regards,
wingo.