Re: [guppi-list] New Guppi Snapshot

[linas linas org]

Just to give you a flavour of what the g-wrap IDL looks like:

(make-pointer-token-type 'Account* "Account*")

(new-function
 'gnc:account-get-id
 'int "xaccGetAccountID" '((Account* a))
 "Retrieve an account's ID.")

(new-function
 'gnc:account-insert-split
 'void "xaccAccountInsertSplit" '((Account* a) (Split* s))
 "Insert the split s into account a. If the split already belongs
to another account, it will be removed from that account first.")

(new-function
 'gnc:account-set-name
 'void "xaccAccountSetName" '((Account* a) (const-string name))
 "Set account name")

(new-function
 'gnc:account-get-name
 'const-string "xaccAccountGetName" '((Account* a))
 "Get the brief name for the account.")


--linas


It's been rumoured that Rob Browning said:
> 
> Andrew Chatham <andrew.chatham@duke.edu> writes:
> 
> > I don't really know anything about Guile other than what I've learned turning
> > the guile bindings for guppi into Python bindings (I adjusted James
> > Henstridge's wrapper generators for PyGTK), but what are the problems with
> > SWIG? 
> > 
> > Was it the problem of dealing with complex datatypes and arrays? You
> > didn't like the interface files? It sounds like what you're describing is
> > another version of SWIG, which I'm sure it's not, but I'm curious what the
> > problems were and the differences are.
> 
> The main problem was that when I came along a year or two ago and
> needed a guile tool for this job, I tried contacting the swig
> developers to see if they were interested in work on the guile
> backend.  No one responded, and from poking around the lists, it
> didn't look like there was much interest in real support for guile.
> Christopher Lee (of g-wrap), on the other hand, was very responsive
> and I was able to move forward quite easily.  That's about it.
> 
> g-wrap also has some other features that you might consider advantages
> that make me prefer it at least for wrapping libs for guile.
> 
>   1) it's small, and though not that easy to understand ATM, could be
>      reworked to be very clear without much hassle.
> 
>   2) it doesn't fall down the rathole of trying to parse C code.  The
>      API spec file is separate, and fairly clean (though it could be
>      cleaner), and ideally, it should eventually capture all the
>      relevant information about the C API, including a lot of things
>      you can't tell from just scanning prototypes.
> 
>   3) Since the API spec is just scheme forms, writing tools to parse
>      it and do whatever you want is a *lot* easier than trying to
>      parse the ad-hoc curly-brace syntax of C and SWIG, and as a
>      personal matter, swig has just seemed to have a little too much
>      of the perl "whatever works" feel to it.  (Don't get me wrong.
>      Perl's a useful language - too useful to ignore in fact - but
>      it's no asthetic marvel.)
> 
> IMO, YMMV, and all that...
> 
> One of the things we're about to add is support for glib <-> guile
> data types, including lists, vectors, maybe hashes, etc.
> 
> -- 
> Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
>