guile-gtk-general
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]