GNU bug report logs - #43252
27.1; DBus properties lack type hints or overrides

Previous Next

Package: emacs;

Reported by: Hugh Daschbach <hugh <at> ccss.com>

Date: Mon, 7 Sep 2020 00:55:02 UTC

Severity: normal

Found in version 27.1

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

Bug is archived. No further changes may be made.

Full log


Message #68 received at 43252 <at> debbugs.gnu.org (full text, mbox):

From: Hugh Daschbach <hugh <at> ccss.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 43252 <at> debbugs.gnu.org
Subject: Re: bug#43252: 27.1; DBus properties lack type hints or overrides
Date: Wed, 16 Sep 2020 15:23:16 -0700
Michael Albinus writes:

> Hugh Daschbach <hugh <at> ccss.com> writes:
>
> Hi Hugh,
>
> I've just finished my work on dbus-set-property. It shall also 
> keep the
> type information of the registered property. Because of this, 
> I've
> changed the internal structure of dbus-event; for all arguments 
> the
> corresponding type information is propagated now.
>
> You might test this. Given you confirm this functionality, I 
> believe we
> can close this bug report now.

Good.  I'll test and report back.

>>
>> That idea has taken root.  It'll take me a few days to put 
>> together
>> reviewable code.  But I've got a good start.
>
> Now that we have type information in dbus-event, I'll start next 
> days to
> implement org.freedesktop.DBus.Monitoring.BecomeMonitor
> <https://dbus.freedesktop.org/doc/dbus-specification.html#bus-messages-become-monitor>. If
> this succeeds, we could implement a counterpart to the 
> dbus-monitor
> program in Elisp. And you would be able to access this 
> information
> programmatically, including all message and signal call / return
> arguments and their types. Let's see.

Excellent.  I can now parse the output of dbus-monitor.  But 
capturing
asynchronous output and feeding it through an ah-hoc parser seems
fragile.  Capturing type data directly as a monitor is much more 
robust.

There's quite a bit of boiler plate in the property tests.  Do you 
have
an issue with rolling that up in a macro?  Does it make test 
failure
analysis more difficult?

Here's a candidate:

(defmacro dbus-test05-test-property (name value expected)
 `(let ((byte-array ,name))
   (should
    (equal
     (dbus-register-property
      :session dbus--test-service dbus--test-path
      dbus--test-interface ,name :read
      ,value)
     `((:property :session ,,dbus--test-interface ,,name)
       (,dbus--test-service ,,dbus--test-path))))
   (should
    (equal
     (dbus-get-property
      :session dbus--test-service dbus--test-path
      dbus--test-interface ,name)
     ,expected))

   ;; a test for `dbus-get-property' shall be added.

   (let ((result
          (dbus-get-all-properties
           :session dbus--test-service dbus--test-path
           dbus--test-interface)))
    (should (equal (cdr (assoc ,name result)) ,expected)))

   (let ((result
          (dbus-get-all-managed-objects :session 
          dbus--test-service "/"))
         result1)
    (should (setq result1 (cadr (assoc dbus--test-path result))))
    (should (setq result1 (cadr (assoc dbus--test-interface 
    result1))))
    (should (equal (cdr (assoc ,name result1)) ,expected)))))

With the calling sequence something like:

(dbus-test05-test-property
"bytearray"
'(:array :byte 1 :byte 2 :byte 3)
'(1 2 3))

Opinion?

Thanks,
Hugh




This bug report was last modified 4 years and 229 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.