headers
Michael Albinus | 17 Jul 2009 21:30
Picon
Picon
Gravatar

dbusbind.el

Zajcev Evgeny <lg.zevlg <at> gmail.com> writes:

> Michael Albinus <michael.albinus <at> gmx.de> writes:
>
>> Sebastian Freundt <hroptatyr <at> sxemacs.org> writes:
>>
>>> I wouldn't call our dbus support an API yet.  It is the product of 1 hour
>>> of work with a very specific goal, getting empathy to work.  We haven't
>>> considered anything yet, let alone thought about a possible collaboration.
>>> Consider our dbus support a design study, more or less a proof that our
>>> FFI concept is flexible enough to furtherly support it.
>>
>> I see. I do not understand whether you support also receiving signals
>> and method calls. This would require a kind of mainloop integration; is
>> this possible with FFI?
>
> yes, we have an ability to integrate glib's event loop into SXEmacs,
> thats how i've got sxempathy to work.  This integration not yet in
> ffi-dbus AFAIR

Porting dbusbind.c to dbusbind.el has progressed last weeks. Arguments
marshalling / unmarshallings works for arbitrary D-Bus types, I can call
D-Bus methods and show the result, I can subscribe to signals, read
them, and see them as misc-user events.

What I don't know is how to integrate into the SXEmacs mainloop. I'm NOT
speaking about dbus-glib , that is not used. There is a Lisp function
(xd-read-queued-messages) which checks the system and session buses for
new incoming messages, reads them, and transforms them into a misc-user
event. This function must be called regularly in the SXEmacs main
(Continue reading)

Permalink | Reply | 25 comments |
headers
Steve Youngs | 18 Jul 2009 08:01
X-Face
Face
Gravatar

Re: dbusbind.el

* Michael Albinus <michael.albinus <at> gmx.de> writes:

  > Porting dbusbind.c to dbusbind.el has progressed last weeks. Arguments
  > marshalling / unmarshallings works for arbitrary D-Bus types, I can call
  > D-Bus methods and show the result, I can subscribe to signals, read
  > them, and see them as misc-user events.

Excellent!

  > What I don't know is how to integrate into the SXEmacs mainloop. I'm NOT
  > speaking about dbus-glib , that is not used. There is a Lisp function
  > (xd-read-queued-messages) which checks the system and session buses for
  > new incoming messages, reads them, and transforms them into a misc-user
  > event. This function must be called regularly in the SXEmacs main
  > loop. How do I get this?

<caveat>
  What I know about D-Bus could be written on the back of a postage
  stamp (verbosely)
</caveat>

Why does #'xd-read-queued-messages need to be called in the SXEmacs
mainloop?  Is it so there is less chance of if getting blocked,
interrupted, or missed?  Maybe we could plonk it on its own "worker"
thread like we can do with audio playback (SXEmacs can play audio
asynchronously). 

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|       SXEmacs - The only _______ you'll ever need.       |
(Continue reading)

Permalink | Reply | 24 comments |
headers
Michael Albinus | 18 Jul 2009 10:41
Picon
Picon
Gravatar

Re: dbusbind.el

Steve Youngs <steve <at> sxemacs.org> writes:

>   > What I don't know is how to integrate into the SXEmacs mainloop. I'm NOT
>   > speaking about dbus-glib , that is not used. There is a Lisp function
>   > (xd-read-queued-messages) which checks the system and session buses for
>   > new incoming messages, reads them, and transforms them into a misc-user
>   > event. This function must be called regularly in the SXEmacs main
>   > loop. How do I get this?
>
> <caveat>
>   What I know about D-Bus could be written on the back of a postage
>   stamp (verbosely)
> </caveat>

I've started with even less knowledge, 2 years ago.

> Why does #'xd-read-queued-messages need to be called in the SXEmacs
> mainloop?  Is it so there is less chance of if getting blocked,
> interrupted, or missed?  Maybe we could plonk it on its own "worker"
> thread like we can do with audio playback (SXEmacs can play audio
> asynchronously). 

No special need for the mainloop. It simply must be called in "real
time" (whatever this means), in order to check for pending incoming
D-Bus messages.

Best regards, Michael.
Permalink | Reply | 23 comments |
headers
Sebastian Freundt | 18 Jul 2009 15:11
X-Face
Face
Gravatar

Re: dbusbind.el

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Steve Youngs <steve <at> sxemacs.org> writes:
>
>>   > What I don't know is how to integrate into the SXEmacs mainloop. I'm NOT
>>   > speaking about dbus-glib , that is not used. There is a Lisp function
>>   > (xd-read-queued-messages) which checks the system and session buses for
>>   > new incoming messages, reads them, and transforms them into a misc-user
>>   > event. This function must be called regularly in the SXEmacs main
>>   > loop. How do I get this?
>>
>> <caveat>
>>   What I know about D-Bus could be written on the back of a postage
>>   stamp (verbosely)
>> </caveat>
>
> I've started with even less knowledge, 2 years ago.
>
>> Why does #'xd-read-queued-messages need to be called in the SXEmacs
>> mainloop?  Is it so there is less chance of if getting blocked,
>> interrupted, or missed?  Maybe we could plonk it on its own "worker"
>> thread like we can do with audio playback (SXEmacs can play audio
>> asynchronously). 
>
> No special need for the mainloop. It simply must be called in "real
> time" (whatever this means), in order to check for pending incoming
> D-Bus messages.

How frequent do you need this to be called?  And what's the additional
load when 1. there are no events and 2. there are events?  The usual way
(Continue reading)

Permalink | Reply | 22 comments |
headers
Michael Albinus | 19 Jul 2009 00:32
Picon
Picon
Gravatar

Re: dbusbind.el

Sebastian Freundt <hroptatyr <at> sxemacs.org> writes:

>> No special need for the mainloop. It simply must be called in "real
>> time" (whatever this means), in order to check for pending incoming
>> D-Bus messages.
>
> How frequent do you need this to be called?  And what's the additional
> load when 1. there are no events and 2. there are events?  The usual way
> for lisp code to get invoked regularly is itimers, is that an option? 

Frequency: it depends, how reactive SXEmacs shall be. Signals come in
asynchronously; you can call methods asynchronously and want to see the
result when available, and alike.

It would be good to poll the message queue every (x) tenth of a
second. One second shall be the absolute maximum between two checks (but
likely, this is too long).

I have no figures about additional load. There are at least two calls of
dbus_connection_read_write() and dbus_connection_pop_message() per bus
(system bus and session bus). If there are incoming messages, they must
be decoded; load depends on parameters. And an associated handler, a
Lisp function, can be called - everybody can register.

What I can say is that nobody has ever claimed too heavy load in GNU
Emacs because of this - the code has been added back in December 2007.

itimers might be an option, I'll give them a try.

> Sebastian
(Continue reading)

Permalink | Reply | 21 comments |
headers
Steve Youngs | 19 Jul 2009 03:18
X-Face
Face
Gravatar

Re: dbusbind.el

* Michael Albinus <michael.albinus <at> gmx.de> writes:

  > Sebastian Freundt <hroptatyr <at> sxemacs.org> writes:
  >>> No special need for the mainloop. It simply must be called in
  >>> "real time" (whatever this means), in order to check for pending
  >>> incoming D-Bus messages.
  >> 
  >> How frequent do you need this to be called?  And what's the
  >> additional load when 1. there are no events and 2. there are
  >> events?  The usual way for lisp code to get invoked regularly is
  >> itimers, is that an option?

  > Frequency: it depends, how reactive SXEmacs shall be. Signals come
  > in asynchronously; you can call methods asynchronously and want to
  > see the result when available, and alike.

  > It would be good to poll the message queue every (x) tenth of a
  > second. One second shall be the absolute maximum between two checks
  > (but likely, this is too long).

Floats can be used for itimer values so firing this every 0.1s is
feasible.

  > What I can say is that nobody has ever claimed too heavy load in GNU
  > Emacs because of this - the code has been added back in December
  > 2007.

Good. :-)

  > itimers might be an option, I'll give them a try.
(Continue reading)

Permalink | Reply | 20 comments |
headers
Michael Albinus | 19 Jul 2009 09:58
Picon
Picon
Gravatar

Re: dbusbind.el

Steve Youngs <steve <at> sxemacs.org> writes:

>   > It would be good to poll the message queue every (x) tenth of a
>   > second. One second shall be the absolute maximum between two checks
>   > (but likely, this is too long).
>
> Floats can be used for itimer values so firing this every 0.1s is
> feasible.

I've added

(unless (get-itimer "dbusbind")
  (start-itimer "dbusbind" 'xd-read-queued-messages 0.1 0.1))

That works perfectly. I'll watch it next days, how it behaves under
pressure.

> Is D-Bus something we could treat like a network process?  I'm thinking
> #'open-network-stream, and #'open-network-server-stream.

Yes, one could implement the low-level protocol. But libdbus, used via
ffi, is much more convenient.

Best regards, Michael.
Permalink | Reply | 19 comments |
headers
Steve Youngs | 19 Jul 2009 10:42
X-Face
Face
Gravatar

Re: dbusbind.el

* Michael Albinus <michael.albinus <at> gmx.de> writes:

  > Steve Youngs <steve <at> sxemacs.org> writes:
  >> > It would be good to poll the message queue every (x) tenth of a
  >> > second. One second shall be the absolute maximum between two checks
  >> > (but likely, this is too long).
  >> 
  >> Floats can be used for itimer values so firing this every 0.1s is
  >> feasible.

  > I've added

  > (unless (get-itimer "dbusbind")
  >   (start-itimer "dbusbind" 'xd-read-queued-messages 0.1 0.1))

  > That works perfectly. I'll watch it next days, how it behaves under
  > pressure.

OK, looking forward to hearing how it goes.

  >> Is D-Bus something we could treat like a network process?  I'm thinking
  >> #'open-network-stream, and #'open-network-server-stream.

  > Yes, one could implement the low-level protocol. But libdbus, used via
  > ffi, is much more convenient.

OK, cool.

--

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
(Continue reading)

Permalink | Reply | 18 comments |
headers
SXEmacs Issue Tracking | 20 Jul 2009 16:51

[Bug 113] New: ffi does not handle short strings correctly

http://issues.sxemacs.org/show_bug.cgi?id=113

           Summary: ffi does not handle short strings correctly
           Product: SXEmacs
           Version: 22.1.10
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Core Lisp
        AssignedTo: steve <at> sxemacs.org
        ReportedBy: michael.albinus <at> gmx.de
         QAContact: sxemacs-devel <at> sxemacs.org

Short strings (less than 4 bytes) are not handled correctly by ffi:

Debugger entered--Lisp error: (error "storage size too small to store type" (2
:string))
  make-ffi-object(:string 2)
  ffi-create-fo(:string "/")
  setarg(:string "/")
  mapcar*(setarg (:string :string :string :string) ("org.freedesktop.Avahi" "/"
"org.freedesktop.Avahi.Server" "ResolveService"))
  dbus:message-new-method-call("org.freedesktop.Avahi" "/"
"org.freedesktop.Avahi.Server" "ResolveService")

--

-- 
Configure bugmail: http://issues.sxemacs.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
(Continue reading)

Permalink | Reply | 8 comments |
headers
SXEmacs Issue Tracking | 21 Jul 2009 06:51

[Bug 113] ffi does not handle short strings correctly

http://issues.sxemacs.org/show_bug.cgi?id=113

Horst Burkhardt <horst.burkhardt <at> optusnet.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |horst.burkhardt <at> optusnet.co
                   |                            |m.au

--- Comment #1 from Horst Burkhardt <horst.burkhardt <at> optusnet.com.au>  2009-07-21 14:47:19 EST ---
can we have steps to reproduce?

--

-- 
Configure bugmail: http://issues.sxemacs.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Permalink | Reply | 0 comments |

Gmane