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 #71 received at 43252 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Hugh Daschbach <hugh <at> ccss.com>
Cc: 43252 <at> debbugs.gnu.org
Subject: Re: bug#43252: 27.1; DBus properties lack type hints or overrides
Date: Thu, 17 Sep 2020 14:58:08 +0200
Hugh Daschbach <hugh <at> ccss.com> writes:

Hi Hugh,

>> 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.

Implementation is more complex than expected. Due to its nature,
org.freedesktop.DBus.Monitoring.BecomeMonitor requires another
(parallel) connection to the bus. This is not foreseen yet in dbusbind.c;
will see how it could fly.

What I could provide just now is an implementation which runs in
*another* Emacs instance. This could be used for monitoring only,
because it is another connection to the bus per definition. Are you
interested to get such a partial implementation?

> 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?

No objection. But comments :-)

> Here's a candidate:
>
> (defmacro dbus-test05-test-property (name value expected)
>  `(let ((byte-array ,name))

I wouldn't call the variable "byte-array"; it could be anything during
test. Call it "property" or alike.

>    (should
>     (equal
>      (dbus-register-property
>       :session dbus--test-service dbus--test-path
>       dbus--test-interface ,name :read

I would use access type :readwrite. We want also to test dbus-set-property.

>       ,value)
>      `((:property :session ,,dbus--test-interface ,,name)
>        (,dbus--test-service ,,dbus--test-path))))

What are the double commas good for? Typos?

>    (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.

That's my typo - dbus-set-property is meant. And yes, it shall also be
here. So you might need macro arguments value1 expected1 value2 expected2.

>    (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?

See above.

> Thanks,
> Hugh

Best regards, Michael.




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.