Re: gdb-patches Digest 9 Dec 2001 19:14:34 -0000 Issue 896

Re: gdb-patches Digest 9 Dec 2001 19:14:34 -0000 Issue 896

[Jim Ingham]

Andrew,

This works fine for me.  Looks better too.

I always thought it was kind of odd that when you were emitting a table, you
still sent the tags for each item, rather than just emitting the table as a
list of rows, each row being just a simple list of entries.  Then the client
of the MI could use the header to identify the elements of each row.  We
could still pass in the column name into ui_out_field_x, and use it to
sanity check the table as we were building it, but just not emit the tag
when we are emitting the element.

This would be a lot more efficient for big tables.  We use a table for the
shared library info on X, and it can get very big - one developer had 600
shared libraries/plugins in his app!

However, PB uses the current form of the table, so I am not in a big hurry
to fix this.  Just something to think about.

Jim

> Hello,
> 
> Hopefully (?) the attached addresses the problem JimI found with the
> ui-out table code.  It keeps track of the table.entry_level and uses
> that to decide what to do.
> 
> That should restrict it to updating header fields for table row entries
> and not all fields.
> 
> It doesn't cause any regressions.  I need to think of a way of testing
> it.  Perhaphs I'll just hack my local breakpoint.c a bit.
> 
> Andrew
> 

-- 
++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=++=
Jim Ingham                              jingham@apple.com
Developer Tools - gdb

Re: gdb-patches Digest 9 Dec 2001 19:14:34 -0000 Issue 896

[Andrew Cagney]

> Andrew,
> 
> This works fine for me.  Looks better too.


Thanks for the feedback, it is in.


> I always thought it was kind of odd that when you were emitting a table, you
> still sent the tags for each item, rather than just emitting the table as a
> list of rows, each row being just a simple list of entries.  Then the client
> of the MI could use the header to identify the elements of each row.  We
> could still pass in the column name into ui_out_field_x, and use it to
> sanity check the table as we were building it, but just not emit the tag
> when we are emitting the element.


I would need to dig up notes.

I think one reason is that, as illustrated by the breakpoint, things are 
not as correctly laid out as you might expect.

The colums within a row are tuples since, for a given table, the number 
of colums and their names should be known and each column could have a 
type different to the next.  Hmm, and tuple fields get names :-)


> This would be a lot more efficient for big tables.  We use a table for the
> shared library info on X, and it can get very big - one developer had 600
> shared libraries/plugins in his app!
> 
> However, PB uses the current form of the table, so I am not in a big hurry
> to fix this.  Just something to think about.


BTW, I missed the varobj stuff when reviewing all the output.

	Andrew