RE: [cdt-dev] Parity features that don't work well (was: Signals view in

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of John Cortell
> Sent: April-14-10 9:26 AM
> To: CDT General developers list.; CDT General developers list.
> Subject: Re: [cdt-dev] Parity features that don't work well 
> (was: Signals view in CDT debugger)
> 
> I think it's simple, and don't imagine anyone would argue with what's 
> been said. If a feature doesn't work at all in CDI, or works very 
> poorly, or is poorly designed and non-critical, we absolutely should 
> not be working on it right now.
> 
> That said, I strongly believe 304096 is a critical issue. The fact 
> that you can NEVER suspend a Cygwin 6.8 gdb session with DSF-GDB 
> leaves it dead in the water, IMO. Sure, maybe it's a little flaky 
> with CDI, but it works most of the time. Cygwin only has 6.8, and 
> Cygwin is quite popular. We cannot with a serious face provide a 
> debugger that doesn't allow Cygwin users to suspend the target.

Yes, we should fix that.
It's just that when I fix a bug, I want to do it right (we all do).
Getting to CDI parity takes Y amount of work, but fixing it right
sometimes takes 2xY.  I guess we can fix this issue incrementally:
getting debugger to suspend (like CDI does) and then the flakiness
can be left for a less busy time.

> 
> John
> 
> At 09:12 PM 4/13/2010, Marc Khouzam wrote:
> >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 249223
> >- 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 today:
> >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?
> >
> >Marc
> >
> >________________________________________
> >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.
> >
> >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
>