From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan Moringen Newsgroups: gmane.emacs.devel Subject: Re: Automatic value conversion in DBus bindings Date: Mon, 27 Jul 2009 07:49:50 +0200 Message-ID: <13232_1248674000_ZZg0A7P405NBX.00_1248673790.13837.92.camel@localhost.localdomain> References: <22440_1248662818_ZZg0A4O3jD8Bt.00_1248662661.13837.61.camel@localhost.localdomain> <87zlaq7n26.fsf@gmx.de> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 7BIT X-Trace: ger.gmane.org 1248696556 8562 80.91.229.12 (27 Jul 2009 12:09:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2009 12:09:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 14:09:09 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MVP0s-0003Dr-J5 for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 14:09:08 +0200 Original-Received: from localhost ([127.0.0.1]:51214 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVP0s-0006q1-0i for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 08:09:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVJCy-000331-LH for emacs-devel@gnu.org; Mon, 27 Jul 2009 01:57:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVJCu-00032p-Ly for emacs-devel@gnu.org; Mon, 27 Jul 2009 01:57:12 -0400 Original-Received: from [199.232.76.173] (port=48354 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVJCu-00032m-CN for emacs-devel@gnu.org; Mon, 27 Jul 2009 01:57:08 -0400 Original-Received: from mux1-unibi-smtp.hrz.uni-bielefeld.de ([129.70.204.65]:63940) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVJCt-0003vn-LG for emacs-devel@gnu.org; Mon, 27 Jul 2009 01:57:08 -0400 Original-Received: from pmxchannel-daemon.mux1-unibi-smtp.hrz.uni-bielefeld.de by mux1-unibi-smtp.hrz.uni-bielefeld.de (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) id <0KNF00300F0WCP00@mux1-unibi-smtp.hrz.uni-bielefeld.de> for emacs-devel@gnu.org; Mon, 27 Jul 2009 07:53:20 +0200 (CEST) Original-Received: from [192.168.36.101] ([212.100.50.62]) by mux1-unibi-smtp.hrz.uni-bielefeld.de (Sun Java(tm) System Messaging Server 6.3-6.03 (built Mar 14 2008; 32bit)) with ESMTPPSA id <0KNF00MFFEV8EF50@mux1-unibi-smtp.hrz.uni-bielefeld.de>; Mon, 27 Jul 2009 07:53:19 +0200 (CEST) In-reply-to: <87zlaq7n26.fsf@gmx.de> X-Mailer: Evolution 2.27.4 X-EnvFrom: jan.moringen@uni-bielefeld.de X-PMX-Version: 5.5.1.360522, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.7.27.54216, pmx8 X-Connecting-IP: 212.100.50.62 X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-Mailman-Approved-At: Mon, 27 Jul 2009 08:07:57 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:113212 Archived-At: Hi Michael. Thank you for the quick reply. Maybe I wasn't clear enough about this in my first message. I think there are two separate problems. I tried to demonstrate the first with the code below. > > While playing around with the DBus bindings, I came across some problems > > related to the automatic conversion between LISP and DBus values. > > > > The first problem can be demonstrated by running the following code: > > > > (require 'dbus) > > > > (defun test () > > nil) > > > > (dbus-register-method > > :session "org.gnu.emacs" "/org/gnu/emacs" "org.gnu.Emacs" "test" > > #'test) > > > > (dbus-call-method-non-blocking > > :session "org.gnu.emacs" "/org/gnu/emacs" "org.gnu.Emacs" "test") > > If you don't want to get a return value, you shall call > > (dbus-call-method-asynchronously > :session "org.gnu.emacs" "/org/gnu/emacs" "org.gnu.Emacs" "test" 'ignore) In this case (the code above) the problem is not whether the caller receives a return value or not, but whether the call returns at all. It does return fine as long as `test' does not return nil. A value of nil causes an infinite loop in `dbus-call-method-non-blocking' as I explained: > (while (not (gethash key dbus-return-values-table nil)) > (read-event nil nil 0.1)) > > Here, the return value nil cannot be distinguished from "no return > value > yet". The second problem is not being able to not return any values from a DBus-invokable function. > > The original motivation for my experiments was writing a function that > > should receive DBus calls but not return a value. This was necessary > > since another process (Empathy) would call the method via DBus and > > complain if it returned anything. > > How is your function called from Empathy? If it is > dbus_connection_send_with_reply_and_block or > dbus_connection_send_with_reply, you *must* return a value. In the case > of dbus_connection_send (that's what I suspect) it doesn't matter, I believe. I think that a *reply* is required, too. The problem seems to be, that it must not have *return values* in it. I could not find the call in the Empathy source (they seem to use gobject DBus proxies and other stuff that I am not familiar with), but I recorded two dumps with dbus-monitor, that hopefully illustrate the problem. The general setup is as follows: The Emacs process takes the bus name org.gnome.Empathy.StreamTubeHandler.x_rudel_infinote and registers an object /org/gnome/Empathy/StreamTubeHandler/x_rudel_infinote with a method org.gnome.Empathy.TubeHandler.HandleTube. This method is invoked by Empathy. The following dump shows a successful attempt in which the Emacs process sent a method return message that does not include any return values. I produced this with the patch from my first message applied. ---------------------------------------------------------------------- method call sender=:1.0 -> dest=org.gnome.Empathy.StreamTubeHandler.x_rudel_infinote serial=112 path=/org/gnome/Empathy/StreamTubeHandler/x_rudel_infinote; interface=org.gnome.Empathy.TubeHandler; member=HandleTube string ":1.4" object path "/org/freedesktop/Telepathy/Connection/gabble/jabber/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" object path "/org/freedesktop/Telepathy/Connection/gabble/jabber/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/StreamTubeChannel_2_1647872899" uint32 1 uint32 2 method return sender=:1.10 -> dest=:1.0 reply_serial=112 ---------------------------------------------------------------------- The following dump show an unsuccessful attempt. The method call is identical but this time the patch wasn't in place and thus the function in the Emacs process was forced to return a value. I arbitrarily decided to return 1. This return value is sent to Empathy as the method return message indicates. However Empathy seems to insist on a method return message that has no return values in it (see below). ---------------------------------------------------------------------- method call sender=:1.0 -> dest=org.gnome.Empathy.StreamTubeHandler.x_rudel_infinote serial=124 path=/org/gnome/Empathy/StreamTubeHandler/x_rudel_infinote; interface=org.gnome.Empathy.TubeHandler; member=HandleTube string ":1.4" object path "/org/freedesktop/Telepathy/Connection/gabble/jabber/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" object path "/org/freedesktop/Telepathy/Connection/gabble/jabber/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/StreamTubeChannel_2_459526684" uint32 1 uint32 2 method return sender=:1.10 -> dest=:1.0 reply_serial=124 uint32 1 ---------------------------------------------------------------------- This is the error message Empathy produces when it receives the method return message with the return value in it: ---------------------------------------------------------------------- Unable to start application for service x_rudel_infinote: Too many arguments in reply; expected 0, got 1 ---------------------------------------------------------------------- I have no idea how I could work around this problem without the ability to not return any values from a DBus-invoked function. If further explanations or tests are required, I would be happy to provide them. Thanks in advance. Kind regards, Jan