From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-83351-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 22112 invoked by alias); 30 Aug 2011 16:34:04 -0000
Received: (qmail 22081 invoked by uid 22791); 30 Aug 2011 16:34:00 -0000
X-SWARE-Spam-Status: No, hits=-2.6 required=5.0	tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from smtp.nokia.com (HELO mgw-da01.nokia.com) (147.243.128.24)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Aug 2011 16:33:46 +0000
Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47])	by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7UGXimH025958	for <gdb-patches@sourceware.org>; Tue, 30 Aug 2011 19:33:45 +0300
From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= <andre.poenitz@nokia.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA] 12843
Date: Tue, 30 Aug 2011 16:34:00 -0000
User-Agent: KMail/1.13.5 (Linux/2.6.35-30-generic; KDE/4.5.5; i686; ; )
References: <4E56C5A0.60802@redhat.com> <201108301021.15313.andre.poenitz@nokia.com> <m3pqjnc586.fsf@fleche.redhat.com>
In-Reply-To: <m3pqjnc586.fsf@fleche.redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain;  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201108301833.47083.andre.poenitz@nokia.com>
X-Nokia-AV: Clean
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2011-08/txt/msg00611.txt.bz2

On Tuesday 30 August 2011 17:02:33 ext Tom Tromey wrote:
> Jan> When you are already considering changes on the front end side has b=
een
> Jan> discussed some replacement by D-Bus, ORBit2 or similar RPC protocol?
>=20
> Andr=C3=A9> Please, pretty please, don't go down that road.
>=20
> I think this is easily done already without much help from us -- Python
> has a variety of RPC approaches out of the box, you could write up
> XMLRPC to our API pretty easily.
>=20
> Andr=C3=A9> I've been adding extra "MI style" output fields for all kind =
of data,
> Andr=C3=A9> including structured and image data, for two years now, and=
=20=20
> Andr=C3=A9> escaping is _really_ not a problem.
>=20
> Do you generate MI-compliant output from Python?  I'm curious.

Sort of. Originally it was fully compliant, then extra fields had been
added and additional commas became "legal" (to save a few cycles
for the check whether they are necessary). But it's still pretty MI-ish.

As short example:

  void test()
  {
    std::vector<int> l;
    l.push_back(1);
    l.push_back(2);
    l.push_back(3);
    dummyStatement(&l);  // <=3D=3D Break here
  }

produces in the "expanded" state where all children are visible

  "data=3D[{iname=3D\"local.l\",name=3D\"l\",addr=3D\"0xbfffeea8\",numchild=
=3D\"3\",
  childtype=3D\"int\",childnumchild=3D\"0\",addrbase=3D\"0x80a99f0\",addrst=
ep=3D\"0x4\",
  children=3D[{value=3D\"1\",},{value=3D\"2\",},{value=3D\"3\",},],
  type=3D\"std::vector<int, std::allocator<int> >\",value=3D\"<3 items>\",}=
,,]\n"

That will be displayed as something like

	Name	Value	Type=20
	l	<3 items>	vector<int>
	[0]	1	int
	[1]	2	int
	[2]	3	int

The childtype/childnumchild/addrbase/addrstep is mostly there to=20
reduce the overhead of repetitive date in the childitems, iname is
similar to the current -var-info-path-expression.

Andre'