From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Fernando Nasser Cc: GDB Discussion Subject: Re: GDB 5.1/mi status and question on table output Date: Mon, 14 May 2001 17:48:00 -0000 Message-id: <3B007CE2.7080308@cygnus.com> References: <3B0010FC.3060908@cygnus.com> <3B002B28.23F0009B@cygnus.com> X-SW-Source: 2001-05/msg00256.html > There are a fixed number of columns to the table and each column has a >> name. Hence a tuple for each row and the heading. >> The number of rows, however, varies, but each one is identical, hence a >> list of rows. >> > > > I like the format but I have a couple of concerns: > > Currently there are "headings" and "field names" and they may not be the same. I think this was done so that a GUI could be implemented fast and cope with tables that have different columns depending on certain circumstances (the breakpoint table is such a beast). I am not saying that this is the right thing, just the way it is now. The UI code using the MI currently has the option of ignoring or using the headings. > > But we may change that and say that we only supply the field names and values. The problem is that we now have two ways of outputting fields: when inside a table they go without the name; when outside they go with the name. > > On one hand, a more compact output without the repetition of names is appealing. On the other hand, if you have an option to get a table of breakpoints or information about a specific breakpoint, now you'll get the information about one item (breakpoint) in two different ways, depending if it came on a table (w/o field names) or as a unit (with field names). Ah, yes, forgot about that nastyness. > P.S.: I am really affraid of last minute changes in the output syntax. Which brings up option (B). Should, for 5.1 the existing table->tuple functions be left as is? A new interface that directly maps table calls on to correct list/tuple functions could then be added instead. Andrew