[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Pretty printer bug number
|
"It's just the the DSF variables and expressions view give the user
a menu by which to choose the format of the Values column. The user
can choose Default, Hex, Binary, etc. How will we deal with
pretty-printing? Will it be the default display? Maybe that is good
enough?"
It's not the task of the pretty printer in the gbd to decide whether an integer value (or pointer) is to be displayed as hex, decimal, etc. The job of the pretty printer is only to return an integer value (or pointer), if the variable should be treated an an integer. I think this one should not be a problem, sounds like perfect separation of concern.
Jens.
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
Sent: Montag, 11. Januar 2010 16:21
To: CDT General developers list.
Subject: RE: [cdt-dev] Pretty printer bug number
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Elmenthaler, Jens
> Sent: January-11-10 8:59 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] Pretty printer bug number
>
> "If possible, once available, can you post the proposed design?"
>
> Well, I don't see actual design changes, my - possibly naïve
> - assumption is that the structure of the UI (= variables
> view) remains unchanged.
It's just the the DSF variables and expressions view give the user
a menu by which to choose the format of the Values column. The user
can choose Default, Hex, Binary, etc. How will we deal with
pretty-printing? Will it be the default display? Maybe that is good
enough?
Without me knowing the changes of the MI commands, I'm not sure if
my concerns are really valid or not. But you can see that
it is not 100% clear.
>
> On the implementation side, I have to figure out if the
> underlying gdb supports pretty printing.
> If so, we just sent the -enable-pretty-printing in the
> beginning of the MI session.
>
> Next is to figure out with the help of the gdb manual which
> MI commands now behave differently, after enabling pretty
> printers. I noticed that these are the ones having "dynamic
> value" in their documentation. The basic change here is that
> children of dynamic values must be obtained by explicitly
> specifying the range of children, instead of just all. With
> pretty printers available (= dynamic value), the old way of
> obtaining children returns no children at all (well, this is
> what I deduced from the CDI GDB, which I'm currently using).
>
> However, I haven't looked into the DSF GDB source by now.
> This is something I left to the outsourcing partner.
>
> Is there real problems you expect?
>
> "I'm wondering if the current patch of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=275238
> will be needed or not"
>
> I would expect not. I see it as a fallback if we cannot
> provide something meaningful for Helios. I'm currently
> pushing for it, but I have to "share" the partner and I just
> passed it over a couple of days ago. I can tell more in a
> month from now.
>
> Jens.
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
> Sent: Montag, 11. Januar 2010 14:35
> To: 'CDT General developers list.'
> Subject: RE: [cdt-dev] Pretty printer bug number
>
> Cool!
> Looking forward to the patches.
>
> If possible, once available, can you post the proposed design?
> I'm wondering if the current patch of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=275238
> will be needed or not.
>
> Thanks
>
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Elmenthaler, Jens
> > Sent: Monday, January 11, 2010 3:59 AM
> > To: CDT General developers list.
> > Subject: RE: [cdt-dev] Pretty printer bug number
> >
> > "Actually, MI does support pretty-printing but it requires some
> > special request from DSF-GDB to turn this on.
> > I don't think it would be very hard, but I've been so busy with so
> > many other things that I didn't have time to figure out
> what those MI
> > changes are. They are all documented in GDB... Someone
> just needs to
> > take the time to read it and digest it.
> > If someone from the community could try making some headway on it,
> > that would speeds things up."
> >
> > I have an outsourcing partner that can spent some time on
> enabling the
> > pretty printing stuff in DSF GDB.
> > >From my understanding the gdb MI API has everything that is needed.
> > This should be the -enable-pretty-printing when creating the MI
> > session, and then adapting a couple of MI commands around the MI
> > values for so called "dynamic values".
> > I also don't think it is a good idea to circumvent the MI commands
> > here, from what I saw on the gdb mailing lists they spent
> quite some
> > time to make it clean.
> > I don't know how educated the outsourcing partner is in providing
> > patches for DSF GDB, but they also write Eclipse plugins for us, so
> > the conditions shouldn't be to bad here.
> >
> > I will post updates to this mailing list on our progress.
> >
> > Jens.
> >
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Marc Khouzam
> > Sent: Samstag, 9. Januar 2010 02:11
> > To: CDT General developers list.
> > Subject: RE: [cdt-dev] Pretty printer bug number
> >
> > Hi Terry.
> >
> > > Marc, this is nice! I'm seeing the pretty printed display
> > of strings, maps, vectors, etc. This is going to make a
> lot of people
> > happy.
> > > Are the plans to commit this to only the 3.6 branch, or is
> > there any chance it will be in 3.5.2 as well?
> >
> > That is a good idea. It is a small enough patch. Could
> you make the
> > request on the bug so it does not slip between the cracks?
> >
> > > Have you given thought to what it would take to be able to
> > toggle the actual variables between a pretty-printed view and a raw
> > view?
> > > It means completely avoiding use of the -var-list-children
> > MI command, since that still reports the raw format.
> > > Would it be easy to inject an alternate handling of
> > variables that issued the cli print command and interpreted its
> > results?
> >
> > Actually, MI does support pretty-printing but it requires
> some special
> > request from DSF-GDB to turn this on.
> > I don't think it would be very hard, but I've been so busy with so
> > many other things that I didn't have time to figure out
> what those MI
> > changes are. They are all documented in GDB... Someone
> just needs to
> > take the time to read it and digest it.
> > If someone from the community could try making some headway on it,
> > that would speeds things up.
> >
> > > Or does DSF support anything like the
> > org.eclipse.debug.core.logicalStructureProviders extension point?
> >
> > I'm not familiar with that extension point, but in DSF and
> DSF-GDB, we
> > don't use any extension points.
> >
> > It's nice to see interest on this fix.
> >
> > Marc
> >
> > On Tue, Jan 5, 2010 at 8:27 AM, Marc Khouzam
> > <marc.khouzam@xxxxxxxxxxxx<mailto:marc.khouzam@xxxxxxxxxxxx>> wrote:
> > Hi,
> >
> > as discussed in the conference call, here is the bug that
> focuses on
> > support for GDB 7.0 pretty printers for DSF-GDB
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=275238
> >
> > There is a prototype patch attach that is small and easy to try.
> >
> > Marc
> >
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx<mailto:cdt-dev@xxxxxxxxxxx>
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
