[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Roadmap to 2.8 platform bindings
From: |
Andreas Rottmann |
Subject: |
Re: Roadmap to 2.8 platform bindings |
Date: |
Tue, 11 May 2004 11:56:28 +0200 |
User-agent: |
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux) |
Andy Wingo <address@hidden> writes:
> Yo,
>
> 1. The module split. I assume rotty's on this and it will happen
> magically ;)
>
This is mostly done and working now. I wrote a mail about that, but it
seems that got lost, I'll resend it; the relevant part in this context
is:
tla get address@hidden/dists--dev--0 guile-gnome
cd guile-gnome
tla build-config -r configs/gnu.org/dev
cd src
./autogen.sh --noconfigure
mkdir ../_build && cd ../_build
../src/configure
make
> 3. Define the public namespace to be (gnome FOO): (gnome
> source-view), (gnome pango), etc. Honest sub-modules can exist,
> for example (gnome extra repl), (gnome gobject types), but I
> don't like having (gnome gtk glade); it should be (gnome glade).
> Where we put the g-wrapped libs is not important for the
> purposes of the platform bindings, because they're private to
> the bindings generator, which we're not declaring stable.
>
This is already solved in the split modules; there is a (gnome gw FOO)
and a (gnome FOO) namespace; the latter should just contain hand-coded
stuff.
> 4. We need to go through the gobject API with a fine-toothed comb
> to see if there's anything that could bite us later, or that
> needs to be reimplemented. I think that breaking
> primitives/non-primitives into separate modules (object,
> parameters, enums/flags, gtype, typed values) will force us to
> do this.
> 5. We need to briefly visit the other APIs to see if there are any
> problems. It would be useful to identify all types that are
> inputs to functions but are opaque and can't be produced by
> scheme, and then disable those functions because they can't
> work. I'm thinking of all those int* parameters in
> libgnomecanvas. What a pain. An intelligent g-wrap could help
> here.
>
Assuming those "gint*" are pure output parameters, this can already be
solved with G-Wrap TNG; the following is from glib-spec.scm:
(add-type-rule! ws '(("gint*" "*")) '(int out))
This adds a rule that all parameters of type "gint*" (regardless of
their name; "*" is a globbing pattern) to be "int" output
parameters. The return value and output parameters are then delivered
with (values ...) to the caller (if there are more than 1 values to be
delivered).
The other thing that needs to implemented in G-Wrap proper is combined
arguments (e.g. pointer + int = array).
Andy
--
Andreas Rottmann | address@hidden | address@hidden | address@hidden
http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62
Python is executable pseudocode, Perl is executable line-noise.