[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future of g-wrap (and guile wrappers in general).

From: Alex Shinn
Subject: Re: Future of g-wrap (and guile wrappers in general).
Date: 20 Aug 2001 15:39:17 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.104

>>>>> "Rob" == Rob Browning <address@hidden> writes:

    Rob> So the first question I'd like to ask is does Guile need a
    Rob> wrapper generator at all?

Absolutely.  Although I consider it a necessary learning experience
for getting used to the Guile C API, I am now very sorry that
guile-sdl was written without a wrapper generator.  There are over 150
functions wrapped, and though at the time writing it was very simple,
mostly cut&paste and some general utility functions and macros,
maintaining it will now prove difficult.  For example, when we moved
from using integers for enums and flags to the combined integer/symbol
approach of guile-gtk, I had to go through and change every function
that accepted or returned such a value.

On the other hand, guile-sdl uses a lot of default values and
behaviour that isn't easy to reproduce with a wrapper generator.  For
instance, the SDL_ttf module provides the functions

  TTF_RenderText_Solid(font, text, fg);
  TTF_RenderText_Shaded(font, text, fg, bg);
  TTF_RenderText_Blended(font, text, fg);

and similar variations for rendering utf8 text and individual glyphs.
Solid just creates a surface holding text in the color fg, with a
transparent background.  Shaded produces the text anti-aliased over
the given background color, and blended produces the text anti-aliased
over a transparent background.  At the risk of alienating people
expected a direct mapping to the C API, it seemed the most natural
Scheme way to express this was

  (sdl-render-text font text fg [bg])

where if no bg is specified it uses the _Solid variant, but if bg is
given then it is used as the background color to blend over, with #t
meaning transparent.

So providing a good wrapper from such a high-level language as Scheme
to such a low-level one as C is very difficult.  The best tool will
let you automate the redundant parts and override where necessary.

    Rob> Overall it seems like dropping g-wrap in favor of SWIG,
    Rob> presuming that's even an option, would have the advantage of
    Rob> putting effort into making Guile's SWIG support stronger, but
    Rob> we might end up (as far as wrapping C functions goes) with a
    Rob> less tightly integrated solution than we'd have if we stuck
    Rob> with something more guile-specific.  With g-wrap we've been
    Rob> able to tailor the wrapping of specific types very closely
    Rob> with Guile smobs or native types using libguile directly.
    Rob> I'm not sure that would be as possible with SWIG.

As I see it, the advantages of SWIG are that it's very mature and well
documented, and any wrappers for one language in SWIG are fairly close
to being ported to another language.  An automated tool for creating a
SWIG specification isn't really necessary, since SWIG uses a variant
of C's .h syntax, which can be adapted from the library's header file
(if the header doesn't work out of the box).  Also people coming from
other languages may be familiar with SWIG, which will get the up to
speed writing Guile wrappers quicker.

The advantages of g-wrap are that since it is written in Guile and is
Guile-specific, it is much easier to extend and add features to.
Also, since the g-wrap definitions are actually a Guile script it is
easy to add in local extensions and use ad-hoc logic in your wrapper
generation where needed.  It seems that for Guile we can get a lot
farther and quicker with g-wrap than with SWIG.

Alex Shinn <address@hidden>

reply via email to

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