This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pretty-printing update

On Friday 03 October 2008 22:25:43 Tom Tromey wrote:
> >>>>> "Vladimir" == Vladimir Prus <> writes:
> Vladimir> I think the most fundamental difference between your
> Vladimir> approach and MI one is that for MI, there's class with one
> Vladimir> method to return string rendition, and another method to
> Vladimir> return children values.
> Yeah.
> I'm wondering if there is some generically useful way to wrap the MI
> printers in a function suitable for use from the CLI.  I think it
> would be ok if this couldn't be done in every case -- it could be a
> convenience for the cases where it would work.
> That would let library authors implement an MI class and then define
> the CLI function simply, something like:
>     gdb.pretty_printers[regex] = gdb.functionify_mi_class (class)
> I haven't experimented in this area at all yet, this is just a random
> idea I had yesterday.

Probably; I think iterating over children reported by MI class and
rendering them should be fine.

> Vladimir> Returning children values, as
> Vladimir> opposed to some string names, is very desirable for
> Vladimir> MI. OTOH, there's no support to specify names for children,
> Vladimir> they are just numbered. Also, for std::map, you probably
> Vladimir> would want to return pairs of values and GUI should
> Vladimir> understand that mapping is been displayed, I don't know how
> Vladimir> to communicate this.
> Can't a std::map expose its children as std::pair objects?
> Then we'd recursively apply smart MI printing and expose the children
> of the std::pair.

Then, there will be no difference in display between:

	vector<std::pair<string, string> >


	map<string, string>

I am not sure sure how to nicely present those things in UI. Say, for maps
I would have liked display like:

       + some_map
         - foo -> bar
         - biz -> bar

but I don't know what to do if key and value types are composite. Should
UI allow to expand key, and value, independently? I'm not even sure GUI
frameworks would allow to expand the element in the second column.

- Volodya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]