unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neil@ossau.homelinux.net>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel@gnu.org
Subject: Re: [PATCH] Doc: protecting procedure->pointer pointers from GC
Date: Tue, 31 Jan 2012 23:06:36 +0000	[thread overview]
Message-ID: <8739avcw03.fsf@neil-laptop.ossau.uklinux.net> (raw)
In-Reply-To: <87zkd4uryp.fsf@pobox.com> (Andy Wingo's message of "Tue, 31 Jan 2012 10:44:14 +0100")

Andy Wingo <wingo@pobox.com> writes:

> On Mon 30 Jan 2012 22:32, Neil Jerram <neil@ossau.homelinux.net> 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)
hotchpotch:

- 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
continues...

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
anymore?

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 http://git.savannah.gnu.org/cgit/ossaulib.git/.  The
main script is at scripts/phone.

        Neil



  reply	other threads:[~2012-01-31 23:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-30 21:32 [PATCH] Doc: protecting procedure->pointer pointers from GC Neil Jerram
2012-01-31  9:44 ` Andy Wingo
2012-01-31 23:06   ` Neil Jerram [this message]
2012-02-02 21:21     ` Ludovic Courtès
2012-02-03  8:56       ` Neil Jerram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8739avcw03.fsf@neil-laptop.ossau.uklinux.net \
    --to=neil@ossau.homelinux.net \
    --cc=guile-devel@gnu.org \
    --cc=wingo@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).