callback functions in Emacs

callback functions in Emacs

[Michael Albinus]

Hi,

I'm playing a little bit with integration of D-Bus(*) into Emacs. In
order to get this, I'm writing dbusbindings.{h,c}, which are linked to
Emacs.

One of the basic concepts od D-Bus is, that one could register a
callback function which is applied when there bis a signal on the bus
one has registered for. That works fine as long everything is handled on
C level. But I intend to register a callback C function, which calls
then a Lisp function internally (via Ffuncall etc).

Unfortunately, this fails. Feval does abort when evalling the
corresponding Lisp form, because handling_signal is equal 1 (the comment
in eval.c explains, that the Lisp interpreter cannot be called from a
signal handler, because it isn't reentrant).

One possible solution I found is the use of an additional, Emacs
internal network process, installed when registering the callback
function in D-Bus. I can send something to the process when being inside
the callback function. The process filter of this process reads then the
sent string, and calls the corresponding Lisp function.

But that looks ugly to me. Isn't there another, more simple way to
evaluate Lisp code from inside a callback function?

(*): http://dbus.freedesktop.org

TIA, and best regards, Michael.

Re: callback functions in Emacs

[David Kastrup]

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

> But that looks ugly to me. Isn't there another, more simple way to
> evaluate Lisp code from inside a callback function?

Use an idle timer for that?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: callback functions in Emacs

[Davis Herring]

> One of the basic concepts od D-Bus is, that one could register a
> callback function which is applied when there bis a signal on the bus
> one has registered for. That works fine as long everything is handled on
> C level. But I intend to register a callback C function, which calls
> then a Lisp function internally (via Ffuncall etc).

I would use `special-event-map' for this, like real signals do.  (That is,
insert new symbols like "d-bus-go" but with better names into the input
stream and let the command loop handle calling into Lisp.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: callback functions in Emacs

[Stefan Monnier]

>> One of the basic concepts od D-Bus is, that one could register a
>> callback function which is applied when there bis a signal on the bus
>> one has registered for. That works fine as long everything is handled on
>> C level. But I intend to register a callback C function, which calls
>> then a Lisp function internally (via Ffuncall etc).

> I would use `special-event-map' for this, like real signals do.  (That is,
> insert new symbols like "d-bus-go" but with better names into the input
> stream and let the command loop handle calling into Lisp.)

Agreed: if dbus signals can be made into events that's probably ideal.


        Stefan

Re: callback functions in Emacs

[Richard Stallman]

    I'm playing a little bit with integration of D-Bus(*) into Emacs.

It isn't feasible for me to browse a web site--what is D-Bus?  Why do
we want to control it from Emacs, and do it by adding C code?

    One of the basic concepts od D-Bus is, that one could register a
    callback function which is applied when there bis a signal on the bus
    one has registered for.

By "signal" do you mean the C-level signals that are handled
by `sigaction'?

    But that looks ugly to me. Isn't there another, more simple way to
    evaluate Lisp code from inside a callback function?

What do you mean by "a callback function"?  That is not an Emacs
concept, so it doesn't specify the most relevant facts.  What exactly
is going to call this function, when?

If you're talking about C-level signal handlers, the usual way for
them to run Lisp code is by queuing input events.

Re: callback functions in Emacs

[Michael Albinus]

Richard Stallman <rms@gnu.org> writes:

>     I'm playing a little bit with integration of D-Bus(*) into Emacs.
>
> It isn't feasible for me to browse a web site--what is D-Bus?  Why do
> we want to control it from Emacs, and do it by adding C code?

Quoting from the introduction on dbus.freedesktop.org:

---

D-Bus is an inter-process communication mechanism--a medium for local
communication between processes running on the same host. (Inter-host
connects may be added in the future, but that is not what D-Bus is
meant for). D-Bus is meant to be fast and lightweight, and is designed
for use as a unified middleware layer underneath the main free desktop
environments.

Unlike more heavyweight conventional messaging middleware, D-Bus is
non-transactional. It is stateful and connection-based, however,
making it "smarter" than low-level message-passing protocols such as
UDP. On the other hand, it does carry messages as discrete items--not
continuous streams of data as is the case with TCP. Both one-to-one
messaging and publish/subscribe communication are supported.

D-Bus has a structured view of the data it carries, and deals with
data in binary form: integral numbers of various widths,
floating-point numbers, strings, compound types, and so on. Because
data is not just "raw bytes" to D-Bus, messages can be validated and
ill-formed messages rejected. In technical terms, D-Bus behaves as an
RPC mechanism and provides its own marshaling.

There are two major components to D-Bus: a point-to-point
communication dbus library, which in theory could be used by any two
processes in order to exchange messages among themselves; and a dbus
daemon. The daemon runs an actual bus, a kind of "street" that
messages are transported over, and to which any number of processes
may be connected at any given time. Those processes connect to the
daemon using the library, and it probably wouldn't make much sense to
use the library for anything else. We'll be looking mostly at the
situation where applications (or more generally, clients) connect to a
full-blown bus.

Multiple buses may be active simultaneously on a single system. D-Bus
was first built to replace the CORBA-like component model underlying
the GNOME desktop environment. Similar to DCOP (which is used by KDE),
D-Bus is set to become a standard component of the major free desktop
environments for GNU/Linux and other platforms. A GNOME environment
normally runs two kinds of buses: a single system bus for
miscellaneous system-wide communication, e.g. notifications when a new
piece of hardware is hooked up; and a session bus used by a single
user's ongoing GNOME session. A session bus normally carries traffic
under only a single user identity, but D-Bus is aware of user
identities and does support flexible authentication mechanisms and
access controls. The system bus may see traffic from and to any number
of user identities.

---

If you run GNU/Linux (what I guess), you can see D-Bus messages by
calling "dbus-monitor --session" or "dbus-monitor --system" from a
shell (the latter one only if you're running Gnome or KDE).
dbus-monitor is contained in the Debian package dbus-1-utils, for
example.

Linux' HAL and HotPlug are implemented on top of the D-Bus system bus,
as interface org.freedesktop.Hal .

For Emacs, the D-Bus session bus is more appropriate. Very rough
examples how Emacs could use D-Bus:

- Work as server. Register in the D-Bus session bus an interface
  org.gnu.emacs (which is derived from default interfaces
  org.freedesktop.TextEditor and org.freedesktop.FileHandler). The
  implementation is parallel to the emacs server, but would react on
  D-Bus messages towards such an interface instead of emacsclient
  events. This would allow applications to contact Emacs directly,
  without even knowing that Emacs is the text editor to be called.

- Work as client. Communicate with the registered interface
  org.gnome.Keyring in order to retrieve passwords and keys from this
  data store on a reliable way.

- React on bus signals. Register for the session bus interface
  org.gnome.ScreenSaver. The signal SessionPowerManagementIdleChanged
  toggles between true and false; depending on that signal there could
  be an extension of run-with-idle-timer. It wouldn't check only for
  user input, but runs when the session is really idle.

A lot of other use cases are possible, this shall show you just the
possibilities. Given, that D-Bus is used by Gnome and KDE, I believe
Emacs would benefit from being plugged in into D-Bus.

>     One of the basic concepts od D-Bus is, that one could register a
>     callback function which is applied when there bis a signal on the bus
>     one has registered for.
>
> By "signal" do you mean the C-level signals that are handled
> by `sigaction'?

No. It is a special D-Bus message one can register for.

>     But that looks ugly to me. Isn't there another, more simple way to
>     evaluate Lisp code from inside a callback function?
>
> What do you mean by "a callback function"?  That is not an Emacs
> concept, so it doesn't specify the most relevant facts.  What exactly
> is going to call this function, when?

There are two cases a callback function is used. You can offer an
interface to the session bus, and register a service in the session
bus which implements this interface. "Registering" means that you must
specify a C function which is called when another application sends a
message to this service. Let's say you implement a C function
"open_file", and register it in the session bus as method "OpenFile"
of interface "org.freedesktop.TextEditor". Another application, which
wants to open a file, sends a message to that method, and Emacs opens
the file. The file name to be opened is passed inside the
message. Because the other application sends the message to the
standard interface, it doesn't need to care _which_ editor will do the
job.

The other case is when you register for a dbus signal. A signal can be
regarded as a multicast message send from an application to the
session bus. Emacs could register the C function "idle_changed" to the
signal "SessionPowerManagementIdleChanged" of interface
"org.gnome.ScreenSaver". Whenever the Gnome screen saver changes its
status, it sends the dbus signal (multicast message)
"SessionPowerManagementIdleChanged" with the parameter true or false,
and every registered function, including our "idle_changed", is called.

> If you're talking about C-level signal handlers, the usual way for
> them to run Lisp code is by queuing input events.

That's the way I will go.

Thanks to everybody who gave me information, and best regards, Michael.

Re: callback functions in Emacs

[Miles Bader]

Michael Albinus <michael.albinus@gmx.de> writes:
> If you run GNU/Linux (what I guess), you can see D-Bus messages by
> calling "dbus-monitor --session" or "dbus-monitor --system" from a
> shell

Hmmm quite cool -- I see messages (on the "system" bus) when I plug in a
usb stick... :-)

-miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: callback functions in Emacs

[Michael Albinus]

Miles Bader <miles.bader@necel.com> writes:

> Hmmm quite cool -- I see messages (on the "system" bus) when I plug in a
> usb stick... :-)

If you like to play, try this:

# dbus-send --print-reply --system --dest=org.freedesktop.Hal /org/freedesktop/Hal/Manager org.freedesktop.Hal.Manager.GetAllDevices

# dbus-send --print-reply --system --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.GetPropertyString string:'system.vendor'

Just to give you an idea.

> -miles

Best regards, Michael.

Re: callback functions in Emacs

[Thien-Thi Nguyen]

() Michael Albinus <michael.albinus@gmx.de>
() Wed, 05 Sep 2007 10:43:43 +0200

   - Work as server.
   - Work as client.
   - React on bus signals.

how about extending emacsclient to communicate d-bus messages?
that should be able to handle all three of these cases, and
furthermore handle disambiguation of multiple emacs instances.

thi

Re: callback functions in Emacs

[Michael Albinus]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> how about extending emacsclient to communicate d-bus messages?
> that should be able to handle all three of these cases, and
> furthermore handle disambiguation of multiple emacs instances.

Anything goes. But first I need to do the dirty part: communicate with
dbus. At least I'm able already to see all registered services, and
to react on the screensaver signal.

That makes me happy :-)

Btw, dbus has a concept of "queued registration". If several
applications register for the same service, just the first
registration is active. All requests to this service are forwarded to
this application. If the application disappears, the next registration
from the queue will be active.

This would solve indeed the Emacs server disappearance problem,
because the next Emacs instance would take over control automagically.

> thi

Best regards, Michael.

Re: callback functions in Emacs

[Davis Herring]

> how about extending emacsclient to communicate d-bus messages?
> that should be able to handle all three of these cases, and
> furthermore handle disambiguation of multiple emacs instances.

Perhaps I misunderstand D-Bus (having only glanced at its front page), but
I believe that messages can only be delivered to processes (that already
exist).  We'd have to have some sort of emacsclientserver (perhaps within
Emacs) that listened for them and translated them into emacsclient
invocations.  Of course, if such a server is in Emacs, it prevents having
another program to customize, but then it might as well do what the OP
suggests and handle the messages itself.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: callback functions in Emacs

[Michael Albinus]

"Davis Herring" <herring@lanl.gov> writes:

> Perhaps I misunderstand D-Bus (having only glanced at its front page), but
> I believe that messages can only be delivered to processes (that already
> exist).  We'd have to have some sort of emacsclientserver (perhaps within
> Emacs) that listened for them and translated them into emacsclient
> invocations.  Of course, if such a server is in Emacs, it prevents having
> another program to customize, but then it might as well do what the OP
> suggests and handle the messages itself.

Emacs client can play its role, but for D-Bus it isn't necessary I
believe. When Emacs is started, it registers during the initialization
phase at the D-Bus for a given service. Then an application can send a
message directly to this service, and Emacs is in.

A concept of D-Bus (I haven't mentioned yet) is that it even can start
an application for a service if it doesn't find a registered
one. Example (I assume you run Linux):

Save the following lines as file /usr/share/dbus-1/services/emacs.service

[D-BUS Service]
Name=org.gnu.emacs.TextEditor
Exec=/usr/local/bin/emacs

Send from a shell the command

# dbus-send --session --print-reply --dest=org.gnu.emacs.TextEditor /org/gnu/emacs/TextEditor org.gnu.emacs.TextEditor

The command is just an emulation of a message any application can send
to the session bus.

Then a fresh Emacs will be started. D-Bus waits for a given time that
this Emacs registers the service org.gnu.emacs.TextEditor, and would
provide the message then. You will see that it doesn't work in this
case, there is a timeout because Emacs doesn't register in time (yet).

No need for Emacs client when using D-Bus.

> Davis

Best regards, Michael.

PS: the implementation of callback functions via special-event-map is
already running, but it needs some more tuning. Thanks again for the
hint.

Re: callback functions in Emacs

[Stefan Monnier]

> one. Example (I assume you run Linux):

Please write GNU/Linux when you talk about the system rather than just
the kernel.  Thank you,


        Stefan

Re: callback functions in Emacs

[Thien-Thi Nguyen]

() "Davis Herring" <herring@lanl.gov>
() Wed, 5 Sep 2007 07:30:11 -0700 (PDT)

   We'd have to have some sort of emacsclientserver (perhaps within
   Emacs) that listened for them and translated them into emacsclient

that's the spirit!

so, given that emacs does -batch (and now -script),
the race is on: who will post emacsclient reimplemented
in elisp?  anyone?  can't be more than a couple dozen
lines and a few weeks of testing (ttn sez, optimistically).

(sorry this is only tangentially related to d-bus support.
 however, once you get into proxy server space everything
 is only tangentially related. ;-)

thi

Re: callback functions in Emacs

[dhruva]

Hi,

On 9/5/07, Thien-Thi Nguyen <ttn@gnuvola.org> wrote:
> so, given that emacs does -batch (and now -script),
> the race is on: who will post emacsclient reimplemented
> in elisp?  anyone?  can't be more than a couple dozen
> lines and a few weeks of testing (ttn sez, optimistically).

I had put in a dirty hack a while ago when emacsclient was still not
ported on M$ in it's current from. I posted it on this list too, the
response was "no point in loading a full blown emacs to interpret the
elisp script and execute as a client".

Well, it has both the server and client implementation as I wanted to
handle some auth and stuff that came on th elist. It is very basic and
a beginners attempt to write one, I stopped working on it and has been
dormant ever since.

FWIW, the script it still at:
http://dhruvakm.googlepages.com/emacsserver.el

-dky

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

Re: callback functions in Emacs

[Leo]

On 2007-09-04 21:27 +0100, Michael Albinus wrote:
> I'm playing a little bit with integration of D-Bus(*) into Emacs. In
> order to get this, I'm writing dbusbindings.{h,c}, which are linked to
> Emacs.

I wonder the if it is now time to include the "dynamically loadable
extension modules" patch.

(The discussion in "A plea for dynamically loadable extension modules" in
http://news.gmane.org/group/gmane.emacs.devel/thread=15734/force_load=t/focus=76783)

-- 
Leo <sdl.web AT gmail.com>                (GPG Key: 9283AA3F)

      Gnus is one component of the Emacs operating system.

Re: callback functions in Emacs

[Richard Stallman]

    I wonder the if it is now time to include the "dynamically loadable
    extension modules" patch.

I am still looking at the legal implications of it.
I have not decided whether we should ever install it.