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

[Matthias Koeppe]

Rob Browning <address@hidden> writes:

>> There is no automatic support for "forced coercions".  If you wanted
>> to cast an "int*" to a "double*", you would have to make an
>> appropriate identity function and wrap it:
> 
> So it sounds like right now there's really no way to explicitly
> convert a wrapped pointer of one type to a wrapped pointer of another
> arbitrary type without making all types interchangable.  i.e. swig
> doesn't have any equivalent to:
> 
>   (gw:coerce-wptr foo <gnucash:Bar*>)
> 
> If not, then we'd definitely need a workaround or need to stick with
> g-wrap for now.

I think you got this wrong.  I gave this example:

        %inline %{
           double *foo(int *p) { return (double*) p; }
        %}

The resulting Scheme procedure `foo' would only accept "int *" pointer
objects and always return "double *" pointer objects.  

> Way back, my biggest problem with the typemaps was that they weren't
> quite flexible enough to do some of the things I wanted.  I suppose
> I'll just have to see if all the stuff that's been added is sufficient
> if we decide to give swig a go.  I can't recall what the exact issues
> were, but I do recall that I needed to insert some code in a
> particular place in the generated wrapper, and I couldn't...

Yes, this is indeed the biggest limitation of current SWIG.  There are
two passes ("ignore" or "in", then "check"), in which the arguments
are handled from left to right, where typemaps can emit code to the
wrapper.  This may not be enough for complicated argument conversions
spanning multiple arguments.  It would be trivial to add extra passes,
but I still need to make up my mind on these issues.

How do you tell g-wrap where to put the code pieces?

>> That SWIG uses the "values" of enums and other constants in the
>> wrapper, rather than referring to the constants themselves, is a
>> quirky feature indeed.  I actually don't know the reason for this.
> 
> That's what I was kinda worried about, though I don't know how often
> it would actually be a problem.
> 
> So how do you access an enum value from the scheme side.  I presume
> you don't have to know the relevant integer -- actually I can just go
> check the main docs for this unless swig's guile handling varies from
> the default...

The enum value is treated like a constant, so it is visible in Guile
as a 0-ary procedure returning the constant value.

>> I have tried to avoid emitting wrapper code that depends on the Guile
>> wrappers, because that would make for a maintenance nightmare.  SWIG's
>> output works with Guile 1.3.4 through Guile 1.5.x.  I guess I am
>> forced to make an incompatible change when the gh_ interface is no
>> longer available, but not earlier.
> 
> Hmm, mainly I was just wondering about whether not using guile's
> "official" typedef might cause trouble on some machines (i.e. 64-bit,
> etc.)

Last time I checked, Guile did not seem to be 64-bit capable anyway,
so I didn't care about the "official" types, especially as they seemed
to keep changing (scm_t_bits, scm_bits_t, scm_ubits_t etc. IIRC).

Has the situation stabilized since?

>> SWIG has its own (extended) C preprocessor, it is not using the C
>> compiler's preprocessing step.  I am using it extensively, and I
>> think it is very stable.
>>
>> I would always use the preprocessor, so that I can use the same
>> header file both for the C compiler and SWIG.  I think this is where
>> SWIG's power comes from: You just need to maintain one (annotated)
>> interface, which defines the API both for C and higher-level
>> languages.
> 
> But what bothered me was relying on swig's (non-gcc) preprocessor for
> swig files, and obviously gcc's when you get around to compiling the C
> code.  If they vary *at all* in how they interpret preprocessor
> directives, handle math/pragmas/etc.  It seems like you could get some
> possibly nasty results.

SWIG tries to provide an ANSI C preprocessor.  It is not identical to
gcc's preprocessor, but I think that it is a bad idea to rely on
gcc-isms rather than standardized behaviour, anyway.  

-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe
SWIG makes Guile wrappers for C/C++ libs -- http://www.swig.org
ILISP does module-aware Emacs/Guile interaction -- http://sf.net/projects/ilisp