From: Michael Albinus <michael.albinus@gmx.de>
To: Hugh Daschbach <hugh@ccss.com>
Cc: 43252@debbugs.gnu.org
Subject: bug#43252: 27.1; DBus properties lack type hints or overrides
Date: Fri, 11 Sep 2020 16:19:18 +0200 [thread overview]
Message-ID: <87y2lggzvd.fsf@gmx.de> (raw)
In-Reply-To: <87pn6t9rbq.fsf@ccss.com> (Hugh Daschbach's message of "Thu, 10 Sep 2020 15:53:29 -0700")
Hugh Daschbach <hugh@ccss.com> writes:
Hi Hugh,
>>> Reading the BlueZ D-Bus GATT API description, you seem to need only
>>> basic types and arrays of basic types as properties. So I will start
>>> adding arrays of basic types. Other, more complex compound types
>>> will follow later.
>
> That's mostly true. There is another BlueZ interface (advertising)
> that take a byte keyed dictionary. It isn't obvious from the
> documentation
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/advertising-api.txt.
> But the Manufacturer ID described mentioned in the ManufacturerData
> dictionary description is a byte value.
>
> The property table in the BlueZ source code looks like:
>
> { "ManufacturerData", "a{qv}", get_manufacturer_data, NULL,
> manufacturer_data_exists
> },
>
> (https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/client/advertising.c#n465)
>
> It isn't clear that there's a commitment to support such a data
> structure. The DBus info page says "Every dictionary entry has a
> string as a key".
Looks like this has been extended to "Every dictionary entry has a
basic type as a key".
Anyway, my today's commits shall support now all compound types for properties.
> I haven't been able to verify property signatures programatically. I
> have turned on dbus-debug and verified signatures reported by the
> message formatter. I assume introspection is in the queue. With
> introspection, we could extend the tests.
I'm no more convinced that introspection is the way to go. What if there
aren't introspection data?
Maybe one could run two processes in parallel to the tests:
--8<---------------cut here---------------start------------->8---
dbus-monitor --session "sender=org.gnu.Emacs.TestDBus"
dbus-monitor --session "destination=org.gnu.Emacs.TestDBus"
--8<---------------cut here---------------end--------------->8---
It shall be possible to analyze their structured output.
> I assume I shouldn't care about tests that fail with debug turned on.
Yes. However, dbus-debug on let's *all* dbus-error errors through, both
internal errors, and the ones arriving from incoming D-Bus error
messages. Sometimes, one wants to see the latter only. So I have added a
defcustom dbus-show-dbus-errors which allows to pass only the incoming
error messages. See the changed dbus-test05-register-property for examples.
> Thanks again,
> Hugh
Best regards, Michael.
next prev parent reply other threads:[~2020-09-11 14:19 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-07 0:54 bug#43252: 27.1; DBus properties lack type hints or overrides Hugh Daschbach
2020-09-07 7:48 ` Michael Albinus
2020-09-07 17:35 ` Hugh Daschbach
2020-09-07 18:00 ` Michael Albinus
2020-09-07 19:18 ` Hugh Daschbach
2020-09-08 14:36 ` Michael Albinus
2020-09-09 4:10 ` Hugh Daschbach
2020-09-09 4:25 ` Hugh Daschbach
2020-09-09 13:25 ` Michael Albinus
2020-09-09 16:12 ` Hugh Daschbach
2020-09-09 17:43 ` Michael Albinus
[not found] ` <874ko6979w.fsf@gmx.de>
[not found] ` <87v9gm9x9i.fsf@ccss.com>
2020-09-10 14:59 ` Michael Albinus
2020-09-10 16:57 ` Michael Albinus
2020-09-10 19:09 ` Hugh Daschbach
2020-09-11 8:46 ` Michael Albinus
2020-09-10 22:53 ` Hugh Daschbach
2020-09-11 9:57 ` Michael Albinus
2020-09-11 14:19 ` Michael Albinus [this message]
2020-09-15 4:05 ` Hugh Daschbach
2020-09-16 12:47 ` Michael Albinus
2020-09-16 22:23 ` Hugh Daschbach
2020-09-17 12:58 ` Michael Albinus
2020-09-17 18:42 ` Hugh Daschbach
2020-09-18 6:28 ` Hugh Daschbach
2020-09-18 9:55 ` Michael Albinus
2020-09-18 13:42 ` Michael Albinus
2020-09-18 15:50 ` Michael Albinus
2020-09-18 9:36 ` Michael Albinus
2020-09-19 3:32 ` Hugh Daschbach
2020-09-20 15:05 ` Michael Albinus
2020-09-21 11:50 ` Michael Albinus
2020-09-22 3:48 ` Hugh Daschbach
2020-09-22 16:09 ` Michael Albinus
2020-09-22 17:36 ` Michael Albinus
2020-09-23 3:30 ` Hugh Daschbach
2020-09-23 3:34 ` Hugh Daschbach
2020-09-23 7:44 ` Michael Albinus
2020-09-23 17:32 ` Michael Albinus
2020-09-24 3:02 ` Hugh Daschbach
2020-09-24 8:48 ` Michael Albinus
2020-09-25 4:16 ` Hugh Daschbach
2020-09-26 1:27 ` Hugh Daschbach
2020-09-26 9:51 ` Michael Albinus
2020-09-28 3:00 ` Hugh Daschbach
2020-09-28 12:55 ` Michael Albinus
2020-09-28 23:17 ` Hugh Daschbach
2020-09-29 12:22 ` Michael Albinus
2020-09-29 21:51 ` Hugh Daschbach
2020-09-30 9:34 ` Michael Albinus
2020-09-30 10:42 ` Michael Albinus
2020-09-30 16:39 ` Hugh Daschbach
2020-09-10 8:00 ` bug#43252: Fwd: " Michael Albinus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y2lggzvd.fsf@gmx.de \
--to=michael.albinus@gmx.de \
--cc=43252@debbugs.gnu.org \
--cc=hugh@ccss.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).