- To: Ariel Rios <jarios at usa dot net>
- Subject: g-wrap and guile-gnome/gtk
- From: Rob Browning <rlb at cs dot utexas dot edu>
- Date: 02 Nov 2000 13:28:49 -0600
(Feel free to forward this wherever appropriate.)
Hi, Ariel. I don't know if you remember me, but we met at the Chicago
Linux show. I was one of the gnucash people in the booth next to you.
In any case, I've finally gotten around to looking at guile-gnome/gtk
again, and realized that we should probably talk. I didn't know if
there was a "most appropriate" list to discuss this, so I figured I'd
just contact you first.
Here's the issue. In guile-gnome/gtk, you have the *.defs files.
When I looked at them, I was stunned. I don't know if you know, but
I'm now the upstream maintainer for g-wrap, and your .defs files look
nearly identical to g-wrap's .gwp spec files. I've included a snippet
of the gnucash .gwp file below. In that code, "[...]" just represents
stuff I cut out for the example.
What I'm wondering is if we ought to at least discuss whether or not
we could collaborate on a common solution. Right now I think your
solution has a few things g-wrap doesn't and vice-versa.
Since I'm getting geared up to add a bunch more things to g-wrap, I
figured now might be an excellent time to talk. One of the things I'm
about to add is a much more extensible C<-->scheme type addition
mechanism that will let us wrap up functions that take (or return as
arguments) the glib container types and (optionally) present/convert
those to equivalent scheme types (lists, hashes, etc.) on demand. To
do this, I'm trying to design a mechanism that's flexible enough to
handle not just glib types, but many other libs given a small "type
specification".
One thing g-wrap may have that your solution doesn't is a lot of
flexibility about how it handles C-side memory allocation. You can
set defaults for a given new type, telling g-wrap that by default it
should or shouldn't handle cleaning up (freeing or whatever's
appropriate) the temporaries that it generates to pass across the
C/scheme boundary, and you can override those defaults on a
per-function basis in your "new-function" spec (see below).
One difference I can see between your and our spec file formats is
that our spec file is just plain old guile code, not a set of forms to
be parsed. While this makes it harder to enforce certain things, it
has the nice advantage of being quite flexible, and we've used it to
have sections of the file that are conditionally included based on
checks of environment variables, etc.
Regardless, I think it'd be trivial to write some guile code that
would translate either of our formats to the other (or to a slightly
different common format) since both are just scheme forms.
My ultimate goal is to create a guile/C extension tool that would
allow you to wrap nearly all, if not all, of the interesting C
libraries (a la CPAN for perl), and I've recently investigated
modifying g-wrap to use guiles dynamic library loading code
(i.e. dlopen) so that you'd be able to load C libraries and their
wrappers directly from a vanilla guile, without having to compile a
new guile "shell".
Basically, in the end I want to see this work properly:
(use-modules (gwp opengl))
;; User's fancy amazing graphics goes here...
or
(use-modules (gwp ncurses))
;; User's fancy text terminal app code goes here...
etc.
The snippet of the gnucash g-wrap .gwp spec file is below.
Thanks
;;; -*- scheme -*-
(define current-gnc-compile-flavor #f)
[...]
(gwrap-open-module "gnc" '(guile-module #f))
(use-modules (site g-wrap pointer))
;; new types...
(add-type 'time-pair "Timespec"
;; fn-convert-to-scm
(lambda (x) (list "gnc_timespec2timepair(" x ")"))
;; fn-convert-from-scm
(lambda (x) (list "gnc_timepair2timespec(" x ")"))
;; fn-scm-is-a
(lambda (x) (list "gnc_timepair_p(" x ")")))
(add-type 'guid-scm "GUID"
;; fn-convert-to-scm
(lambda (x) (list "gnc_guid2scm(" x ")"))
;; fn-convert-from-scm
(lambda (x) (list "gnc_scm2guid(" x ")"))
;; fn-scm-is-a
(lambda (x) (list "gnc_guid_p(" x ")")))
[...]
(gwrap-generate-wrapped-header "gnc-autogen.h")
;; This is the usual way to add a local header file to the glue code
(gwrap-include-global-header "glib.h")
(gwrap-include-global-header "g-wrap.h")
(gwrap-include-global-header "gnucash.h")
[...]
(make-pointer-token-type 'Account* "Account*")
(make-pointer-array-type 'Account** "Account**" 'Account*)
(make-pointer-token-type 'AccountGroup* "AccountGroup*")
(make-pointer-token-type 'Query* "Query*")
(make-pointer-token-type 'GList* "GList*")
[...]
(new-function
'gnc:transaction-get-guid
'guid-scm "gnc_trans_get_guid" '((Transaction* trans))
"Return the guid of the given transaction.")
(new-function
'gnc:transaction-lookup
'Transaction* "gnc_trans_lookup" '((guid-scm guid))
"Lookup a transaction given a guid.")
(new-function
'gnc:split-get-guid
'guid-scm "gnc_split_get_guid" '((Split* split))
"Return the guid of the given split.")
[...]
(new-function
'gnc:account-type->symbol
'(string-as-symbol no-cleanup)
"xaccAccountTypeEnumAsString" '((int type))
"Convert the account type to a symbol.")
[...]
(let ((docstr "The gnc:account-begin-edit and gnc:account-commit-edit
subroutines provide a psuedo-two-phase-commit wrapper for account
updates. They are mildly useful for detecting attempted updates
outside of their scope. However, they do not provide any true
two-phase-anything in the current implementation. The defer flag, if
set, will defer all attempts at rebalancing of accounts until the
commit."))
(new-function
'gnc:account-begin-edit
'void "xaccAccountBeginEdit" '((Account* a))
docstr)
(new-function
'gnc:account-commit-edit
'void "xaccAccountCommitEdit" '((Account* a))
docstr))
(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.")
[...]
;; Finish up
(gwrap-close-module)
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930