Re: [cdt-dev] Parity features that don't work well (was: Signals view in CDT debugger)
>From my perspective the goal of the parity effort should be to insure that
people accustomed to using a CDI debugger don't find themselves missing
features when using a DSF debugger. If something isn't working well in CDI
then I doubt anyone will miss is very much.
It's interesting to track the other details but I think they should remain a
low priority for now. If they aren't working then they can't play much of a
part in workflow.
Although there are a few remaining things, overall I think the parity effort
is looking pretty good,
> From: ext Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>
> Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> Date: Wed, 14 Apr 2010 04:12:49 +0200
> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> Subject: [cdt-dev] Parity features that don't work well (was: Signals view in
> CDT debugger)
> Hi John,
> I've only looked briefly at the signals feature so I'll let more knowledgeable
> people answer your question.
> I had to answer this email because you bring up a point that has been
> bothering me (there's been a lot
> of that on the list lately... I guess we are feeling the Helios pressure :-))
> In more than one occasion, while investigating a CDI feature that we labeled
> as a parity issue for DSF-GDB,
> I have found that the feature had problems, even in CDI. I'm sure it used to
> work well, but over the years,
> things broke, and as you mention, maybe no one was using it, so no one noticed
> it was broken.
> For example (I won't give details in the email, but if someone is interested,
> just ask):
> - using full path names in debug view does not work well for CDI- that is
> parity Bug 248627
> - resume without signal did not work properly for CDI - that was parity Bug
> - Run to Line did not work well across method calls for CDI - that was parity
> Bug 233230
> - interrupting a windows target windows target (at least for MinGw 6.8) does
> not work all the time with CDI - that is parity Bug 304096
> But we are working hard to address those 'parity' bugs, when in fact, they
> don't always work right in CDI.
> So, when people look at the CDI vs DSF parity list, let's look at it with a
> grain of salt, as some of those features may
> not actually need to be on that list at all.
> Re-reading myself, I realize I'm paraphrasing what Doug was saying earlier
> maybe we are too focused on 'parity' when we should simply work towards
> improving the debugging
> quality in the CDT. One example that comes to mind is the nice Pretty-printer
> feature that Jens has written a difficult patch for. It is not a parity
> issue, so we are not giving it as much attention;
> but from a CDT user point-of-view, wouldn't that feature be better than
> 'resume without signal' for example?
> From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
> John Cortell [rat042@xxxxxxxxxxxxx]
> Sent: April 13, 2010 7:20 PM
> To: CDT General developers list.
> Subject: [cdt-dev] Signals view in CDT debugger
> 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.
> cdt-dev mailing list
> cdt-dev mailing list