[Top][All Lists]

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

Re: [PATCH] Doc: protecting procedure->pointer pointers from GC

From: Neil Jerram
Subject: Re: [PATCH] Doc: protecting procedure->pointer pointers from GC
Date: Tue, 31 Jan 2012 23:06:36 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Andy Wingo <address@hidden> writes:

> On Mon 30 Jan 2012 22:32, Neil Jerram <address@hidden> writes:
>> Following debugging of a strange issue where oFono appeared to be
>> sending a D-Bus signal from the wrong object, but I eventually realised
>> that the problem was in my own code...
> The docs are good, but the example is irritating ;)  Is there a reason
> you are unable to use guile-gnome for the object wrapping?  You can use
> the FFI to call scm_from_gtype_instance or whatever it's called, after
> loading (gnome gobject).

Because Ludo and you have made it so easy to be productive with just
(system foreign) !

But your implication is right, it is a more interesting and complex
question than just that.

My current project is a phone application for the GTA04, which is an ARM
device with most of the promising software stacks being Debian-based.
Hence, aside from Guile itself - where I still have some fixing and
upstreaming to do - I'd ideally like not to take on any dependencies
other than things that are already available for ARM in Debian unstable.
I didn't actually go ahead and check beforehand whether a Guile
2-compatible guile-gnome was available, but I know that guile-2.0 itself
has only recently landed in Debian, so I guess I assumed a compatible
guile-gnome was very unlikely to be available yet.  (And, on checking, I
believe that's still correct.)

So then it would be a matter of building and packaging guile-gnome for
my device.  I remember that from Nokia 770 days...  It's quite doable,
but it takes time (and requires slib and g-wrap first, IIRC), and
compared with that it's way easier, and doesn't impede the hack, just to
grab the entry points that I need using pointer->procedure.

Another relevant factor is that I need relatively few guile-gnome entry
points because I'm only using gobject/glib to get gdbus, and the UI is
built with Edje, not Gtk/Gnome.  In fact it's a strange (but IMO fun)

- Edje/Evas for the UI (using 17 pointer->procedures)

- GDBus to access the oFono D-Bus API (using pointer->procedures: 3
  for basic GObject stuff, 11 for GVariant handling, and 2 for GDBus).

and I will probably add in more stuff for audio routing (PulseAudio?)
and accessing contact information (whatever the latest evolution of
Evolution Data Services is).

But even if I needed a lot more guile-gnome APIs, I'd (at least
initially) be tempted to grab a .defs file and try to hack something
based on that, rather than compiling C code...

I think the key benefit is that the (system foreign) approach is so
immediate.  I just add whatever API I need there, and the hack

My only reservation - and quite a big one - is that it's a bit like
going back in time to when compilers had no type checking for pointers.
In that sense it is rather fast and loose, compared to C programming.

But overall I love it, and I'd suggest that an alternative question (to
the one you asked above) would be why do you think we need bindings

Well I hope that's of interest, and I'm sure you'll have interesting
counter-thoughts...  In case you or anyone wants to look at the code,
I've pushed it to  The
main script is at scripts/phone.


reply via email to

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