dbus introspection

dbus introspection

[Max]

Hi all.

Are there some dbus bindings available for guile? Tried to search but found some
ancient code only :(
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 for
functions/signals available for interaction with this service?

cheers,
Max.

Re: dbus introspection

[Neil Jerram]

Max <maxim.suraev@campus.tu-berlin.de> writes:

> Hi all.
>
> Are there some dbus bindings available for guile?

I have some FFI-based client-side bindings in my library at
http://git.savannah.gnu.org/cgit/ossaulib.git/.  The (glib dbus) module
exports 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, and
I hope is simple enough to make the usage clear.

> Tried to search but found some ancient code only :(

What was that?

I know that guile-gnome used to have a dbus module, and possibly still
does.

> 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 for
> functions/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.)

Regards,
        Neil

Re: dbus introspection

[Max]

27.04.2014 15:33, Neil Jerram пишет:
>
> I have some FFI-based client-side bindings in my library at
> http://git.savannah.gnu.org/cgit/ossaulib.git/.  The (glib dbus) module
> exports 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, and
> I 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 differences
between module, library and R6RS-library.

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.

>
>> 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.
Also, if dbus bindings already available via guile-gnome - why develop another library?

>
>> 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 for
>> functions/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.

cheers,
Max.

Re: dbus introspection

[Neil Jerram]

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 at
>> http://git.savannah.gnu.org/cgit/ossaulib.git/.  The (glib dbus) 
>> module
>> exports 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, 
>> and
>> I 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 
> differences
> between 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 
>>> for
>>> functions/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

Re: dbus introspection

[Max]

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.