28.04.2014 15:51, Neil Jerram пишет:
>
> 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.
Seems like it is - at least I didn't manage to make it work properly with env.
variable.
>
> 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.
Yepp, sadly I need. Don't like hardcoding paths but apparently there's nothing
like
.clisprc - some configuration file where I can instruct guile-gnome-2 to look
for
additional libraries.
>
>
> 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.
Sounds nostalgic - I still have my GTA02+ lying around somewhere :)
Anyway, seems like dbus was removed from guile-glib for some reason. At least
I'm
unable to find anything regarding it at
https://www.gnu.org/software/guile-gnome/docs/glib/html/
>
>
>> 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?
Well, you're right - there's nothing such tool could provide which can't be done
manually. It's just rather tedious work. For example have a look at
/org/freedesktop/secrets org.freedesktop.Secret.Service - it has 8 methods and 3
signals, with plenty of parameters which I don't remember so I have to look it
up
through d-feet or some other tool and than create corresponding .scm, hopefully
not
mixing smth up or forgetting about some parameter or signal or whatever.
I would rather call "guile-dbus-binding-tool /org/freedesktop/secrets
org.freedesktop.Secret.Service" and receive org.freedesktop.secrets.scm with
autogenerated (via dbus introspection) code for module secret-service which
export
functions like (set-alias), (unlock), (get-secrets) etc. and let me register my
functions for callbacks on (collection-changed) and other signals.
Yes, it could be done manually but it's always better to have boilerplate code
autogenerated.
cheers,
Max.
