From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58015) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMzfs-0002tp-Ll for qemu-devel@nongnu.org; Wed, 05 Aug 2015 10:28:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZMzfj-0000bp-V6 for qemu-devel@nongnu.org; Wed, 05 Aug 2015 10:28:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZMzfj-0000bg-Mx for qemu-devel@nongnu.org; Wed, 05 Aug 2015 10:27:59 -0400 References: <1438703896-12553-1-git-send-email-armbru@redhat.com> <1438703896-12553-3-git-send-email-armbru@redhat.com> <55C1343F.5060003@redhat.com> <87io8uuuc7.fsf@blackfin.pond.sub.org> From: Eric Blake Message-ID: <55C21D6D.2080106@redhat.com> Date: Wed, 5 Aug 2015 08:27:57 -0600 MIME-Version: 1.0 In-Reply-To: <87io8uuuc7.fsf@blackfin.pond.sub.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RVTQHjI5rTwLfuO1KSGXpBQInxF1CbCo8" Subject: Re: [Qemu-devel] [PATCH RFC v3 02/32] qapi: New QAPISchema intermediate reperesentation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RVTQHjI5rTwLfuO1KSGXpBQInxF1CbCo8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 08/05/2015 12:23 AM, Markus Armbruster wrote: > Eric Blake writes: >=20 >> On 08/04/2015 09:57 AM, Markus Armbruster wrote: >>> The QAPI code generators work with a syntax tree (nested dictionaries= ) >>> plus a few symbol tables (also dictionaries) on the side. >>> >>> +class QAPISchemaArrayType(QAPISchemaType): >>> + def __init__(self, name, info, element_type): >>> + QAPISchemaType.__init__(self, name, info) >>> + assert isinstance(element_type, str) >>> + self.element_type_name =3D element_type >>> + self.element_type =3D None >>> + def check(self, schema): >>> + self.element_type =3D schema.lookup_type(self.element_type_n= ame) >>> + assert self.element_type >> >> Is it worth adding: >> >> assert not isinstance(self.element_type, QAPISchemaArrayType) >> >> since we don't allow 2D arrays? >=20 > If the generators actually rely on it, yes. Hmm. What happens if you do { 'command': 'Foo', 'returns': [ 'intList' ] } >=20 > If it's just an arbitrary schema language restriction, probably no. That's a tough judgment call. We don't currently allow [ [ 'int' ] ], and the [ 'intList' ] hack is gross. On the other hand, I'm having a tough time coming up with technical reasons why we can't do it (arrays as a parameter or return type should work, and 2D arrays just add another layer of '*' to the C code). >>> + def _make_array_type(self, element_type): >>> + name =3D element_type + 'List' >>> + if not self.lookup_type(name): >>> + self._def_entity(QAPISchemaArrayType(name, None, element= _type)) >>> + return name >> >> Hmm - we probably have collisions if a user tries to explicitly name a= >> 'struct' or other type with a 'List' suffix. Not made worse by this >> patch and not an actual problem with any of our existing .json files, = so >> we can save it for another day. >=20 > qapi-code-gen.txt reserves the 'Kind' suffix. >=20 > We should either adopt a sane, non-colliding scheme for generated names= , > or prevent collisions by rejecting reserved names with a sane error > message (documenting them is then optional), or document reserved names= =2E > The latter two require us to figure out what names we reserve. But as > you say, it's a task for another day. And that cleanup can worry about [ 'intList' ]. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --RVTQHjI5rTwLfuO1KSGXpBQInxF1CbCo8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVwh1tAAoJEKeha0olJ0Nqhm8H/2xur4eaVb4DeiLGiG53sMrK YF0vDw71vxdF3Igt+SLAzlzy/xvVOz/YthZXDpPBtVGVEVSL0J36a0wdhov9+dMO 4Ce/bORIK2twvTWKTIjwoAJQFaO6DJYZOp7LMQe41VaUiwlZyOvEb1ku2lMYC2fW wClUB9MtMS59DYQGEzKp+GC4naXm38bkNzA1fzrxGn4y+6h3jdWx22eiB2HYkMCI Yu+q+BW3071llkxBOUBOnJ0GwF8LuUXsrmpUZJo/sRwbCs1iBYZgFZhpTSO7VZy+ Di4n5dbIhTPbbsP3GFSaNl5Oc/QCfy1x916dLF/fBpwBqxyOTzKplkb/ObVHkxw= =sXG2 -----END PGP SIGNATURE----- --RVTQHjI5rTwLfuO1KSGXpBQInxF1CbCo8--