Ken Brown <kbr...@cornell.edu> writes:
>> I'm confused: do you mean, the problem is happening when the system bus
>> is running, or when it is *not* running? I suspect the latter case.
>
> I really meant it the way I said it: The problem occurs if the system
> bus *is* running. I've done some further testing, and here are the
> results, all with a build of emacs from the trunk, starting in the
> emacs src directory.
Oops.
> 1. With the system bus not running, I start Emacs via 'dbus-launch
> ./emacs.exe -Q&' and load dbus.el. In the *scratch* buffer I evaluate
> some of the expressions that you suggested in your earlier email:
>
> (dbus-get-unique-name :session)
> ":1.0"
> (defun my-dbus-signal-handler (&rest args)
> (message "Signal from bus %s received: %s"
> (dbus-event-bus-name last-input-event) args))
> my-dbus-signal-handler
> (dbus-register-signal
> :session dbus-service-dbus dbus-path-dbus dbus-interface-dbus
> "NameOwnerChanged" 'my-dbus-signal-handler)
> ((:session "org.freedesktop.DBus" "NameOwnerChanged")
> ("org.freedesktop.DBus" "/org/freedesktop/DBus"
> my-dbus-signal-handler))
>
> Now I try 'dbus-monitor --session' in the xterm window from which I
> started emacs. This produces output in the xterm window, but I don't
> see anything in Emacs.
No surprise. You have started an own session bus for Emacs, which is not
known to dbus-monitor. You shall do
# eval `dbus-launch --auto-syntax`
dbus-launch returns some environment variables to be set, which is done
by the eval command. The most interesting one is $DBUS_SESSION_BUS_ADDRESS
# emacs &
Emacs will find the session bus via $DBUS_SESSION_BUS_ADDRESS. Load
dbus.el, and eval the expressions as suggested.
# dbus-monitor --session
This is also a D-Bus client, which connects to the *same* session bus as
Emacs did due to $DBUS_SESSION_BUS_ADDRESS. Now you should see the
signal sent by dbus-monitor in Emacs.
> Back to *scratch*:
>
> (dbus-get-unique-name :system)
>
> This throws me into the lisp debugger with the error (dbus-error
> "Failed to connect to socket /var/run/dbus/system_bus_socket:
> Connection refused"). I guess this is to be expected, since the
> system bus is not running. I now start the system bus via 'net start
> messagebus' in a shell, and I try again:
>
> (dbus-get-unique-name :system)
> ":1.0"
>
> Is this to be expected, that I get the same name for :system that I
> got for :session?
It is not "the same name", it simply looks like :-) Any D-bus daemon
counts the registered clients. In both cases, Emacs has been the first
one, so you've got the same identity name.
The good message is that dbusbind.c is able to speak to both buses under
Cygwin!
> 2. With the system bus running, I start Emacs as above and load
> dbus.el. The cursor stops blinking, and Emacs becomes unresponsive. I
> can type C-g and hear a bell, and I can type C-x C-c to exit, but I
> can't get a response to any other key presses.
That I need to debug. Hmm, no system available next days.
Maybe you can compile dbusbind.c with the compiler flag DBUS_DEBUG,
something like this in the Emacs source tree:
# MYCPPFLAGS='-DDBUS_DEBUG' make
This enables test traces sent to Emacs' stdout (the shell where you have
started it). I've introduced this flag while testing dbusbind.c, when it
has blocked Emacs, and I didn't want to start gdb ...
Maybe I can see something suspicious in the traces.
> I'm willing to try anything else you suggest. Otherwise, I hope
> you're able to debug this when you return from your travels. The
> unstripped emacs-X11.exe binary (Emacs 23.2) is at
>
> http://www.math.cornell.edu/~kbrown/emacs-X11.exe.bz2
>
> and the binary for my build from the trunk is at
>
> http://www.math.cornell.edu/~kbrown/emacs.exe.bz2
>
> Ken
Thanks, and best regards, Michael.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
