Mail Archives: cygwin/2010/08/27/10:24:38
On 8/27/2010 3:41 AM, Michael Albinus wrote:
> Ken Brown<kbrown AT cornell DOT edu> writes:
>
>>> 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.
>>
>> OK, I started the session bus the right way this time, but I still
>> didn't see any signal from dbus-monitor in Emacs. I assume I should
>> have seen something in the echo area?
>
> Yes. You could test whether both Emacs and dbus-monitor use the same bus
> by reordering the calls:
>
> - apply dbus-launch as described
> - echo $DBUS_SESSION_BUS_ADDRESS
> - in *another* shell, set $DBUS_SESSION_BUS_ADDRESS to this value, and
> start dbus-monitor
> - start Emacs in the first shell, and load dbus.el. You shall see in
> the other shell output from dbus-monitor, telling that an application
> has started. It will also tell you the name of that application, like
> ":1.2".
This doesn't happen. Is it possible that dbus.el doesn't complete its
initialization because the system bus isn't running? (Keep in mind that
I can't do *anything* with dbus in Emacs unless I load dbus.el before
starting the system bus.) I note that when I use the version of Emacs
built with MYCPPFLAGS='-DDBUS_DEBUG', loading dbus.el results in the
following error message in the echo area:
D-Bus error: "Failed to connect to socket
/var/run/dbus/system_bus_socket: Interrupted system call"
> - apply (dbus-get-unique-name :session) in Emacs. The result shall be
> the same name.
> - start dbus-monitor in the same shell as Emacs. In the other
> dbus-monitor, you should be notified, that an application has been started.
>
>>> 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.
>>
>> There's very little there. It prints the two lines
>>
>> xd_add_watch: fd 8
>> xd_add_watch: fd 9
>>
>> and no more. Does this tell you anything?
>
> It's the initialization phase. Two watch functions are installed on file
> descriptors 8 and 9 (connected to the system and session buses), polling
> for incoming messages in Emacs' mainloop.
>
> When you call dbus-get-unique-name, there shall be more output. But this
> works, as you have confirmed, so this is not the interesting case.
>
> I've hoped to see more :-( Did you play with the running/non-running
> system bus?
Yes, the traces above were produced when starting Emacs with the system
bus running. I'm stuck at that point and can't do anything to produce
more traces.
Ken
--
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
- Raw text -