* Re: Inconsistency between results of pretty-printing children
2012-07-20 20:14 ` Tom Tromey
@ 2012-07-20 20:20 ` Oliver Buchtala
2012-07-20 20:36 ` Oliver Buchtala
` (2 subsequent siblings)
3 siblings, 0 replies; 11+ messages in thread
From: Oliver Buchtala @ 2012-07-20 20:20 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb
On 20.07.2012 22:13, Tom Tromey wrote:
>>>>>> "Oliver" == Oliver Buchtala <oliver.buchtala@googlemail.com> writes:
> Oliver> here the doc:
> Oliver> http://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing-API.html
> Oliver> under display_hint "map"
>
> Ok, I see.
>
> In the 'map' case, each item returned by the 'children' iterator must
> still be a 2-tuple of the form (NAME VALUE).
>
> What 'map' means is that the first item fetched from the iterator is
> considered to be a key in the map, and the second item fetched from the
> iterator is considered to be the corresponding value. Then the 3rd item
> is a key again, the 4th is a value again, and so on.
>
> In the CLI the NAME parts are omitted when printing, in this case, just
> because it makes the output prettier.
>
> In MI, nothing changes -- the hint is emitted and the MI client is
> expected to take whatever action it thinks appropriate.
>
>
> Here's an abbreviated example from the libstdc++ test suite:
>
> std::map<std::string, int> mp;
> mp["zardoz"] = 23;
> // { dg-final { note-test mp {std::map with 1 elements = {["zardoz"] = 23}} } }
>
> That last line means that 'print mp' here should show:
>
> std::map with 1 elements = {["zardoz"] = 23}
>
> If you dig into the libstdc++ StdMapPrinter code you see:
>
> def next(self):
> if self.count % 2 == 0:
> n = self.rbiter.next()
> n = n.cast(self.type).dereference()['_M_value_field']
> self.pair = n
> item = n['first']
> else:
> item = self.pair['second']
> result = ('[%d]' % self.count, item)
> self.count = self.count + 1
> return result
>
> So in the example above it returns a list like
>
> [ ('[0]', '"zardoz"'), ('[1]', 23) ]
>
>
>
> My question for you is: how can we improve the documentation to make
> this more clear?
>
> Right now they read:
>
> @item map
> Indicate that the object being printed is ``map-like'', and that the
> children of this value can be assumed to alternate between keys and
> values.
>
>
> Tom
thanks...
Though, I have to state my problem using a python list:
I expect from pure intuition and ignoring a bit the comment in the map
hint docu:
Need to return something like that:
[("a", gdb.Value(1)), ("b", gdb.Value(2))]
Am I wrong in that?
To get my gdb (7.4.1) display this pretty I need to provide
[("", "a"), ("", gbd.Value(1)), ("", "b"), ("", gdb.Value(2))]
instead.
Thanks in advance...
Regards,
Oliver
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Inconsistency between results of pretty-printing children
2012-07-20 20:14 ` Tom Tromey
2012-07-20 20:20 ` Oliver Buchtala
@ 2012-07-20 20:36 ` Oliver Buchtala
2012-07-20 20:58 ` Oliver Buchtala
2012-07-20 21:20 ` Oliver Buchtala
2012-07-21 0:12 ` Oliver Buchtala
3 siblings, 1 reply; 11+ messages in thread
From: Oliver Buchtala @ 2012-07-20 20:36 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb
On 20.07.2012 22:13, Tom Tromey wrote:
>>>>>> "Oliver" == Oliver Buchtala <oliver.buchtala@googlemail.com> writes:
> Oliver> here the doc:
> Oliver> http://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing-API.html
> Oliver> under display_hint "map"
>
> Ok, I see.
>
> In the 'map' case, each item returned by the 'children' iterator must
> still be a 2-tuple of the form (NAME VALUE).
>
> What 'map' means is that the first item fetched from the iterator is
> considered to be a key in the map, and the second item fetched from the
> iterator is considered to be the corresponding value. Then the 3rd item
> is a key again, the 4th is a value again, and so on.
>
> In the CLI the NAME parts are omitted when printing, in this case, just
> because it makes the output prettier.
>
> In MI, nothing changes -- the hint is emitted and the MI client is
> expected to take whatever action it thinks appropriate.
>
>
> Here's an abbreviated example from the libstdc++ test suite:
>
> std::map<std::string, int> mp;
> mp["zardoz"] = 23;
> // { dg-final { note-test mp {std::map with 1 elements = {["zardoz"] = 23}} } }
>
> That last line means that 'print mp' here should show:
>
> std::map with 1 elements = {["zardoz"] = 23}
>
> If you dig into the libstdc++ StdMapPrinter code you see:
>
> def next(self):
> if self.count % 2 == 0:
> n = self.rbiter.next()
> n = n.cast(self.type).dereference()['_M_value_field']
> self.pair = n
> item = n['first']
> else:
> item = self.pair['second']
> result = ('[%d]' % self.count, item)
> self.count = self.count + 1
> return result
>
> So in the example above it returns a list like
>
> [ ('[0]', '"zardoz"'), ('[1]', 23) ]
>
>
>
> My question for you is: how can we improve the documentation to make
> this more clear?
>
> Right now they read:
>
> @item map
> Indicate that the object being printed is ``map-like'', and that the
> children of this value can be assumed to alternate between keys and
> values.
>
>
> Tom
I file an issue... with example...
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Inconsistency between results of pretty-printing children
2012-07-20 20:36 ` Oliver Buchtala
@ 2012-07-20 20:58 ` Oliver Buchtala
0 siblings, 0 replies; 11+ messages in thread
From: Oliver Buchtala @ 2012-07-20 20:58 UTC (permalink / raw)
To: gdb
On 20.07.2012 22:36, Oliver Buchtala wrote:
> On 20.07.2012 22:13, Tom Tromey wrote:
>>>>>>> "Oliver" == Oliver Buchtala <oliver.buchtala@googlemail.com>
>>>>>>> writes:
>> Oliver> here the doc:
>> Oliver>
>> http://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing-API.html
>> Oliver> under display_hint "map"
>>
>> Ok, I see.
>>
>> In the 'map' case, each item returned by the 'children' iterator must
>> still be a 2-tuple of the form (NAME VALUE).
>>
>> What 'map' means is that the first item fetched from the iterator is
>> considered to be a key in the map, and the second item fetched from the
>> iterator is considered to be the corresponding value. Then the 3rd item
>> is a key again, the 4th is a value again, and so on.
>>
>> In the CLI the NAME parts are omitted when printing, in this case, just
>> because it makes the output prettier.
>>
>> In MI, nothing changes -- the hint is emitted and the MI client is
>> expected to take whatever action it thinks appropriate.
>>
>>
>> Here's an abbreviated example from the libstdc++ test suite:
>>
>> std::map<std::string, int> mp;
>> mp["zardoz"] = 23;
>> // { dg-final { note-test mp {std::map with 1 elements = {["zardoz"]
>> = 23}} } }
>>
>> That last line means that 'print mp' here should show:
>>
>> std::map with 1 elements = {["zardoz"] = 23}
>>
>> If you dig into the libstdc++ StdMapPrinter code you see:
>>
>> def next(self):
>> if self.count % 2 == 0:
>> n = self.rbiter.next()
>> n = n.cast(self.type).dereference()['_M_value_field']
>> self.pair = n
>> item = n['first']
>> else:
>> item = self.pair['second']
>> result = ('[%d]' % self.count, item)
>> self.count = self.count + 1
>> return result
>>
>> So in the example above it returns a list like
>>
>> [ ('[0]', '"zardoz"'), ('[1]', 23) ]
>>
>>
>>
>> My question for you is: how can we improve the documentation to make
>> this more clear?
>>
>> Right now they read:
>>
>> @item map
>> Indicate that the object being printed is ``map-like'', and that the
>> children of this value can be assumed to alternate between keys and
>> values.
>>
>>
>> Tom
> I file an issue... with example...
>
>
which is here:
http://sourceware.org/bugzilla/show_bug.cgi?id=14380
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Inconsistency between results of pretty-printing children
2012-07-20 20:14 ` Tom Tromey
2012-07-20 20:20 ` Oliver Buchtala
2012-07-20 20:36 ` Oliver Buchtala
@ 2012-07-20 21:20 ` Oliver Buchtala
2012-07-21 0:12 ` Oliver Buchtala
3 siblings, 0 replies; 11+ messages in thread
From: Oliver Buchtala @ 2012-07-20 21:20 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb
On 20.07.2012 22:13, Tom Tromey wrote:
>>>>>> "Oliver" == Oliver Buchtala <oliver.buchtala@googlemail.com> writes:
> Oliver> here the doc:
> Oliver> http://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing-API.html
> Oliver> under display_hint "map"
>
> Ok, I see.
>
> In the 'map' case, each item returned by the 'children' iterator must
> still be a 2-tuple of the form (NAME VALUE).
>
> What 'map' means is that the first item fetched from the iterator is
> considered to be a key in the map, and the second item fetched from the
> iterator is considered to be the corresponding value. Then the 3rd item
> is a key again, the 4th is a value again, and so on.
>
> In the CLI the NAME parts are omitted when printing, in this case, just
> because it makes the output prettier.
>
> In MI, nothing changes -- the hint is emitted and the MI client is
> expected to take whatever action it thinks appropriate.
>
>
> Here's an abbreviated example from the libstdc++ test suite:
>
> std::map<std::string, int> mp;
> mp["zardoz"] = 23;
> // { dg-final { note-test mp {std::map with 1 elements = {["zardoz"] = 23}} } }
>
> That last line means that 'print mp' here should show:
>
> std::map with 1 elements = {["zardoz"] = 23}
>
> If you dig into the libstdc++ StdMapPrinter code you see:
>
> def next(self):
> if self.count % 2 == 0:
> n = self.rbiter.next()
> n = n.cast(self.type).dereference()['_M_value_field']
> self.pair = n
> item = n['first']
> else:
> item = self.pair['second']
> result = ('[%d]' % self.count, item)
> self.count = self.count + 1
> return result
>
> So in the example above it returns a list like
>
> [ ('[0]', '"zardoz"'), ('[1]', 23) ]
>
>
>
> My question for you is: how can we improve the documentation to make
> this more clear?
>
> Right now they read:
>
> @item map
> Indicate that the object being printed is ``map-like'', and that the
> children of this value can be assumed to alternate between keys and
> values.
>
>
> Tom
Ok... I think I understand now...
but it is definitely not intuitive to provide keys that are not used at all.
At least, we could enhance the documentation so that this is clear.
Just by example... that's enough.
You can close the issue I created... (with a bit of dislike of mine for
that "hack" ;) )
Thanks,
Oliver
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: Inconsistency between results of pretty-printing children
2012-07-20 20:14 ` Tom Tromey
` (2 preceding siblings ...)
2012-07-20 21:20 ` Oliver Buchtala
@ 2012-07-21 0:12 ` Oliver Buchtala
3 siblings, 0 replies; 11+ messages in thread
From: Oliver Buchtala @ 2012-07-21 0:12 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb
On 20.07.2012 22:13, Tom Tromey wrote:
>>>>>> "Oliver" == Oliver Buchtala <oliver.buchtala@googlemail.com> writes:
> Oliver> here the doc:
> Oliver> http://sourceware.org/gdb/onlinedocs/gdb/Pretty-Printing-API.html
> Oliver> under display_hint "map"
>
> Ok, I see.
>
> In the 'map' case, each item returned by the 'children' iterator must
> still be a 2-tuple of the form (NAME VALUE).
>
> What 'map' means is that the first item fetched from the iterator is
> considered to be a key in the map, and the second item fetched from the
> iterator is considered to be the corresponding value. Then the 3rd item
> is a key again, the 4th is a value again, and so on.
>
> In the CLI the NAME parts are omitted when printing, in this case, just
> because it makes the output prettier.
>
> In MI, nothing changes -- the hint is emitted and the MI client is
> expected to take whatever action it thinks appropriate.
>
>
> Here's an abbreviated example from the libstdc++ test suite:
>
> std::map<std::string, int> mp;
> mp["zardoz"] = 23;
> // { dg-final { note-test mp {std::map with 1 elements = {["zardoz"] = 23}} } }
>
> That last line means that 'print mp' here should show:
>
> std::map with 1 elements = {["zardoz"] = 23}
>
> If you dig into the libstdc++ StdMapPrinter code you see:
>
> def next(self):
> if self.count % 2 == 0:
> n = self.rbiter.next()
> n = n.cast(self.type).dereference()['_M_value_field']
> self.pair = n
> item = n['first']
> else:
> item = self.pair['second']
> result = ('[%d]' % self.count, item)
> self.count = self.count + 1
> return result
>
> So in the example above it returns a list like
>
> [ ('[0]', '"zardoz"'), ('[1]', 23) ]
>
>
>
> My question for you is: how can we improve the documentation to make
> this more clear?
>
> Right now they read:
>
> @item map
> Indicate that the object being printed is ``map-like'', and that the
> children of this value can be assumed to alternate between keys and
> values.
>
>
> Tom
Back again...
I tried this approach.
This does not look pretty in MI debuggers... (e.g. nemiver)
Instead of providing
[("a", 1), ("b", 2)]
I tried
[("[0], "a"), ("[1]", 1), ("[2]", "b"), ("[3]", 2)]
This looks pretty with gdb print... though not pretty with any of my IDEs.
So, I am sorry... problem remains.
Regards,
Oliver
^ permalink raw reply [flat|nested] 11+ messages in thread