Inconsistency between results of pretty-printing children

Inconsistency between results of pretty-printing children

[Oliver Buchtala]

Hi,

I am facing a problem with the python API for implemenation of 
Printer.children().

In working examples the metod of a pretty printer looks like that:

    def children():
       return [("key", 1)]

Usually one returns an iterable here.

The point is, that it returns tuples with key and value.
This works fine with existing IDEs using the MI interface (kdevelop, 
eclipse cdt, nemiver).

In the API documentation it is described, that this method should return 
alternating keys and values.
And that is exactly what is expected by gdb's print command when 
printing pretty.
To work with gdb's print method, I would adapt my printer to flatten the 
whole list so that keys and values are iterated in an alternating manner.

This way it happens, that my pretty printer can not be used in IDEs and 
with gdb's print simultanously.
Am I doing something wrong?

Regards,
Oliver

Re: Inconsistency between results of pretty-printing children

[Oliver Buchtala]

On 20.07.2012 12:05, Oliver Buchtala wrote:
> Hi,
>
> I am facing a problem with the python API for implemenation of 
> Printer.children().
>
> In working examples the metod of a pretty printer looks like that:
>
>    def children():
>       return [("key", 1)]
>
> Usually one returns an iterable here.
>
> The point is, that it returns tuples with key and value.
> This works fine with existing IDEs using the MI interface (kdevelop, 
> eclipse cdt, nemiver).
>
> In the API documentation it is described, that this method should 
> return alternating keys and values.
> And that is exactly what is expected by gdb's print command when 
> printing pretty.
> To work with gdb's print method, I would adapt my printer to flatten 
> the whole list so that keys and values are iterated in an alternating 
> manner.
>
> This way it happens, that my pretty printer can not be used in IDEs 
> and with gdb's print simultanously.
> Am I doing something wrong?
>
> Regards,
> Oliver
>

I have created an iterator that would show the correct result in gdb's 
print for a children method return (key,value) tuples:

class AlternateKeyValueIterator():

   def __init__(self, iterable):
     self.it = iterable.__iter__()
     self._next = None

   def __iter__(self):
     return self

   def next(self):
     if self._next == None:
       key, value = self.it.next()
       self._next = value
       return ("", key)
     else:
       value = self._next
       self._next = None
       return ("", value)

It needs also to return tuples of (str, gdb.Value) but only the value is 
used for printing, where as this value must be set to key and value in 
an alternating manner.

Any hints?
Or is it a bug?

Regards,
Oliver

Re: Inconsistency between results of pretty-printing children

[Tom Tromey]

>>>>> "Oliver" == Oliver Buchtala <oliver.buchtala@googlemail.com> writes:

Oliver> In the API documentation it is described, that this method should
Oliver> return alternating keys and values.

I don't see this in the docs.  Where are you looking?
If it does say that somewhere then it is a bug in the docs...

Tom

Re: Inconsistency between results of pretty-printing children

[Tom Tromey]

>>>>> "Oliver" == Oliver Buchtala <oliver.buchtala@googlemail.com> writes:

Oliver> I have created an iterator that would show the correct result in gdb's
Oliver> print for a children method return (key,value) tuples:

Could you send a complete example?
That would help.

As far as I know, there aren't bugs in this area, and the existing
pretty-printers, say for libstdc++, work fine both from the CLI and from
MI.

Tom

Re: Inconsistency between results of pretty-printing children

[Oliver Buchtala]

On 20.07.2012 21:48, Tom Tromey wrote:
>>>>>> "Oliver" == Oliver Buchtala <oliver.buchtala@googlemail.com> writes:
> Oliver> I have created an iterator that would show the correct result in gdb's
> Oliver> print for a children method return (key,value) tuples:
>
> Could you send a complete example?
> That would help.
>
> As far as I know, there aren't bugs in this area, and the existing
> pretty-printers, say for libstdc++, work fine both from the CLI and from
> MI.
>
> Tom
Posting attachments on mailing-lists usually don't work...
shall I open a bug instead?

Regards,
Oliver

Re: Inconsistency between results of pretty-printing children

[Tom Tromey]

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

Re: Inconsistency between results of pretty-printing children

[Oliver Buchtala]

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

Re: Inconsistency between results of pretty-printing children

[Oliver Buchtala]

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

Re: Inconsistency between results of pretty-printing children

[Oliver Buchtala]

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

Re: Inconsistency between results of pretty-printing children

[Oliver Buchtala]

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

Re: Inconsistency between results of pretty-printing children

[Oliver Buchtala]

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