[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[MIT-Scheme-devel] callbacks
From: |
Matt Birkholz |
Subject: |
[MIT-Scheme-devel] callbacks |
Date: |
Sat, 19 Mar 2005 01:13:29 +0000 |
> From: Chris Hanson <address@hidden>
> Date: Fri, 18 Mar 2005 14:44:47 -0500
>
> [...]
> If you really are interested in accessing GTK+/GNOME and not more
> general stuff, there's a simpler way to do this: implement a C program
> that runs in a separate process and talks to Scheme via pipes or a
> socket. In fact, someone already has one of these:
>
> http://www.turtle.dds.nl/gtk-server/
That is tempting -- like Scheme->C's graphics server Ezd. I
appreciate the similarity to the callback enqueue/fetch scheme of
SWAT. But I am not giving up on closer integration with GTk.
> [...]
> You aren't duplicating any work here, except the aforementioned FFI
> project, which is one way to solve the problem.
I assume you mean the FFI project will provide a piece of the
solution. Does it enqueue callbacks for a Scheme primitive to fetch?
Perhaps the project also has GTk in its sights? Does it reflect
GObjects in Scheme, and provide for their finalization? Does it get
Scheme's select registry (e.g. test-select-registry primitive) to
cooperate with GLib's main loop (e.g. GMainContext's poll function)?
Given what I have learned this past week, the latter trick looks
doable. I already have a couple threads (a console REPL and Edwin)
running, time-sliced, in an idle function of Gtk's main loop, with a
GTk main window displaying the slice count. A GTk-based select
registry should complete the picture. Wish me luck?
[MIT-Scheme-devel] callbacks, Chris Hanson, 2005/03/18