Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Signals view in CDT debugger

QNX's products have not migrated to DSF yet, right?
So, I guess they wouldn't need the Signals view in DSF
for Helios, but only when they are migrated to DSF? 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Alena Laskavaia
> Sent: Wednesday, April 14, 2010 9:54 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Signals view in CDT debugger
> 
> I think our customer do use it in some cases - it is easier than do it
> from command line
> if you don't know the command, but it is lower priority for sure.
> 
> On Wed, Apr 14, 2010 at 9:48 AM, Doug Schaefer 
> <cdtdoug@xxxxxxxxx> wrote:
> > +1 for it being low priority.
> >
> > On Tue, Apr 13, 2010 at 7:20 PM, John Cortell 
> <rat042@xxxxxxxxxxxxx> wrote:
> >>
> >> I've started looking at the DSF parity task for the Signals view. I
> >> figured the first thing I should do is see the feature in 
> action with a CDI
> >> session. Upon taking it for a spin, my first reaction was: 
> are people really
> >> using this feature? The reason I had that reaction is that 
> CDT makes no
> >> attempt to remember the settings from one debug session to 
> another. Finding
> >> the signal you want to disable in the sea of available 
> signals is cumbersome
> >> to begin with. Changing the values for the signal is also 
> nothing to sneeze
> >> at (requires too many clicks for my tastes). But the 
> kicker is that if after
> >> you've done all that, prepare to do it again the next time 
> you launch a
> >> debug session...for the same program or any other one. I 
> imagine cmdline gdb
> >> users would employ a script that they could quickly and 
> easily execute to
> >> tweak the signal properties, so the gdb feature itself may 
> be useful. I just
> >> question whether the corresponding CDT view feature is, 
> given its current
> >> design.
> >>
> >> If it isn't, we should put it in the low-priority parity 
> bucket and not
> >> consider it on the day we eventually decide whether or not 
> to keep DSF-GDB
> >> as the default for CDT 7.0.
> >>
> >> Thoughts?
> >>
> >> John
> >>
> >>
> >> _______________________________________________
> >> 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
> 

Back to the top