On 2014-04-28 13:49, Max wrote:
27.04.2014 15:33, Neil Jerram пишет:I have some FFI-based client-side bindings in my library athttp://git.savannah.gnu.org/cgit/ossaulib.git/. The (glib dbus) moduleexports procedures for - making a synchronous or asynchronous dbus call - registering a Scheme procedure to be called when a dbus signal occurs.(ofono modem) is a library module that uses those dbus- procedures, andI hope is simple enough to make the usage clear.Excellent. Looks pretty clear to me. I'll just have to go through some basic guile docs on using external libraries.Could you point me to appropriate documentation? I'm kinda lost with differencesbetween module, library and R6RS-library.
"library" and "R6RS-library" are R6RS/R7RS terminology. My code is written with Guile's traditional module syntax, so (use-module ...) is the right way to use it. (Sorry for saying "library module" above - I can see now that that's confusing.)
http://www.gnu.org/software/guile/manual/html_node/Using-Guile-Modules.html#Using-Guile-Modules has general doc in this area.
In ofono-modem it's simply used as (use-module (glib dbus)) - does it mean that I have to copy it to some standard location? What's there procedure to "install" library so it becomes visible to guile-gnome-2? Is there way to make your library available to particular user instead of system-wide availability?I've tried to set GUILE_LOAD_PATH to ~/source/ossaulib but no luck so far.
For Guile in general I believe that should work; of course you also need "export GUILE_LOAD_PATH".
Don't know about guile-gnome-2, though - possibly guile-gnome-2 is also setting GUILE_LOAD_PATH and so overriding your setting.
If you have a top level script, you could instead write
(set! %load-path (append %load-path '("~/source/ossaulib")))
before any (use-module ...) forms. You might also need to expand the
"~", as I don't think Guile does that automatically.
Tried to search but found some ancient code only :(What was that?https://code.launchpad.net/~andywingo/guile-gnome/dbus - this one.I know that guile-gnome used to have a dbus module, and possibly still does.Could you share some links? I've found nothing so far unfortunately.
Same here; my knowledge dates back to the same time as that launchpad link - when guile-gnome was managed in a bzr repository.
Also, if dbus bindings already available via guile-gnome - why develop another library?
Thanks for raising this. It's because the build/deployment process becomes massively simpler, especially on embedded devices.
I worked with guile-gnome, some years ago, for my Nokia 770 and N800 devices. Unfortunately even core Guile wasn't pre-built in the (armel) repositories for those devices, so I had myself to build Guile, then slib, then g-wrap, and then guile-gnome, all using a tricky scratchbox-based build and package installation process; then copy and install all the packages on the devices themselves. (It took a long time too.)
Now I'm working on my GTA04 phone (armhf). Happily the latest stable Guile is pre-built by Debian for armhf, as are the gio/glib/gdbus libraries. So with an FFI approach all I need is to "aptitude install" the right -dev packages, then write and deploy some Guile Scheme code. I find that much simpler.
Also is there some tool similar to vala-dbus-binding-tool which could connect to a given dbus service and using introspection generate guile stub code forfunctions/signals available for interaction with this service?Not that I know of. Should be quite easy to build on top of my client-side bindings, though. (Or on top of any set of client-side bindings.)Yepp, I've just hoped someone already made it :) Can't really imagine how to use dbus without such a convenience tool.
Can you sketch how you'd want your Scheme code to end up looking? "(dbus-call INTERFACE METHOD . PARMS)" is already fairly simple, and I think it would be easy to make INTERFACE applicable to get "(INTERFACE METHOD . PARMS)". What do you have in mind?
Regards,
Neil
